Making a safe certifcates system for an actions API

I have been working on a certificate system for use (as a means of authentication) with my accounts system APIs. I am still thinking out the details, I have only watched a few videos on asymmetric encryption and SSL protocols as a base.

I have come up with the following draft that describes how certificate formatting works, and how each certificate type is used:

https://github.com/Ender-ing/Docs/blob/main/Accounts-System/Certificates/intro.md#standard-ender-certificate-data

I'd like an outside opinion about my approach to the certificate structure and certificate verification.

Edit:

Ok, so what I'm most interested in is hearing others' opinions about how easy would it be to forge a certificate in this certificates system, and how can I make forgery more difficult, even impossible:

Data structure

Each Ender Certificate, regardless of type, includes all the following fields:

(+S): Includes an ID signed field! hash(Unique ID + data)

(KEY+S): Includes a key signed field! hash(Public Key + data)

I am trying to add a salt of some sort to the signature to prevent others from making a fake certificate with correctly signed data (similar to how password hash salts works)

• Version: The version of the certificate data format
• Serial Number (KEY+S): The unique ID of the certificate within the CA's database (64bytes long, except for the root certificate)
• Algorithm (+S): The specific algorithm used to sign and encrypt data
• Validity
• Not Before (+S): The timestamp of the date the certificate becomes effective
• Not After (+S): The timestamp of the date the certificate's validity expires (can be NULL, then it expires when the issuer's certificate expires)
• Issuer
• Issuer ID (+S): The unique ID of the (parent) certificate used to generate this certificate
• Issuer Type (+S): The type of the (parent) certificate used to generate this certificate
• Public Key (+S): The public key used by the certificate
• Type (+S): The type of the certificate (numerical value)

Certificate Validation

All certificates must go through the following verification steps before the data provided by them is used:

Note that the checking process is recursive, meaning that the issuers's validity must be check until you reach the root CA certificate

1. The certificate's revoked state is checked within the CA database using their unique ID.
2. The certificate issuer's validity is checked using their unique ID. (should the issuer be invalid, or revoked, all certificates generated by them will be automatically considered invalid)
3. The certificate issuer's type is checked, and, should it not adhere to the certificate issuer restrictions, it will be invalidated.
4. The certificate's validity (date) is checked (should the current timestamp not be within the range of the Not Before or Not After range, no actions will be allowed, and the certificate will be considered invalid)
5. All other fields are checked to see if they match their signature

Note that starting from step number 2, there is no need to make any more calls to the Database, since the data used in the steps that follow is signed with an Enhanced Signature!