Understanding Digital Certificate Validation

Policy Validation

X509 certificates can include optional policy validation fields. If a policy validation field is present, policy validation is performed for the entire certificate chain including the end entity (EE) certificate and intermediate certificate authority (CA) certificates. Policy validation is not applicable to the root certificate. Policy validation ensures that the EE and intermediate CA certificates have a common policy. If no common policy exists for the certificate chain being validated, certificate validation fails.

Prior to policy validation, a certificate chain containing the self-signed root certificate, intermediate CA certificates, and EE certificate must be built. The policy validation starts with the intermediate CA certificate issued by the self-signed root certificate and continues through the EE certificate.

The following optional certificate fields are used for policy validation:

• policy-oids

• requireExplicitPolicy

• skipCerts

These fields are described in the following sections.

• Policy OIDs Configured on MX Series Devices
• No Policy OIDs Configured on MX Series Devices

Figure 1: Policy Validation with requireExplicitPolicy Field

Figure 2: Policy Validation with skipCerts Field

Path Length Validation

Certificate validation can involve a certificate chain that includes a root CA, one or more optional intermediate CAs, and an EE certificate. The number of intermediate CAs can grow depending upon the deployment scenario. Path length validation provides a mechanism to limit the number of intermediate certificates involved in certificate validation. path-length is an optional field in an X509 certificate. The value of path-length indicates the number of non-self-signed intermediate CA certificates allowed for certificate validation. The last certificate, which is generally the EE certificate, is not included in the path limit. If the root certificate contains a path-length value of 0, no intermediate CA certificates are allowed. If the path-length value is 1, there can be 0 or 1 intermediate CA certificates.

path-length can be present in multiple CA certificates in the certificate chain. The path length validation always begins with the self-signed root certificate. The path limit is decremented by 1 at each intermediate certificate in the chain. If an intermediate certificate contains a path-length value less than the current path limit, the new limit is enforced. On the other hand, if the path-length value is larger than the current path limit, it is ignored.

Figure 3 shows a certificate chain that consists of a root CA, four intermediate CAs, and an EE. The path-length value in Root-CA is 10, therefore the initial path limit of non-self-signed intermediate CA certificates allowed for certificate validation is 10. At Int-CA-1, the path limit is 10-1 or 9. The path-length value in Int-CA-1 is 4, which is less than the path limit of 9, so the new path limit becomes 4. At Int-CA-2, the path limit is 4-1 or 3. The path-length value in Int-CA-2 is 5, which is larger than the path limit of 3, so it is ignored. At Int-CA-3, the path limit is 3-1 or 2. The path-length value in Int-CA-3 is 20, which is larger than the path limit of 2, so it is also ignored.

Figure 3: Path Length Validation

Key Usage

The key usage field in an EE or CA certificate defines the purpose of the key contained in the certificate.

• EE Certificates
• CA Certificates

Issuer and Subject Distinguished Name Validation

Signature validation is performed for certificates received from a peer as well as for the CRL file downloaded from a CA server. Signature validation involves looking up the CA certificate in a CA database based on the issuer’s distinguished name (DN) in the certificate or the CRL being verified.

Figure 4 shows the lookup for CA certificates based on the issuer DN. In the EE certificate, the issuer DN is CA-1, which is the subject DN of the intermediate CA certificate in the chain. In the intermediate CA certificate, the issuer DN is CA-Root, which is the subject DN of the self-signed Root-CA certificate in the chain. In the CRL, the issuer DN is CA-Root, which is the subject DN of the self-signed Root-CA certificate.

Figure 4: Issuer and Subject DN Validation

The lookup for the issuer or subject DN must follow these rules for attribute values:

• Attribute values encoded in different ASN.1 types (for example, PrintableString and BMPString) are assumed to represent different strings.

• Attribute values encoded in PrintableString types are not case-sensitive. These attribute values are compared after removing leading and trailing white spaces and converting internal substrings of one or more consecutive white spaces to a single space.

• Attribute values encoded in types other than PrintableString are case-sensitive.