Understanding Digital Certificate Validation
Staring in Junos OS Release 16.1R3, MX Series devices support digital certificate validation. During IKE negotiation, the PKI daemon on an MX Series device validates X509 certificates received from VPN peers. The certificate validation performed is specified in RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Basic certificate and certificate chain validations include signature and date validation as well as revocation checks. This topic describes additional digital certificate validations performed by the PKI daemon.
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:
These fields are described in the following sections.
Policy OIDs Configured on MX Series Devices
In some situations, it might be desirable to only accept certificates with known policy object identifiers (OIDs) from peers. This optional configuration allows certificate validation to succeed only if the certificate chain received from the peer contains at least one policy OID that is configured on the MX Series device.
On the MX Series device, policy OIDs are configured in an IKE
policy with the policy-oids configuration statement at
the [edit security ike policy policy-name certificate] hierarchy level. You can configure up to five
policy OIDs. For a peer’s certificate to be validated successfully,
the peer’s certificate chain must contain at least one of the
policy OIDs configured on the MX Series device. Note that the
policy-oids field in a certificate is optional.
If you configure policy OIDs on the MX Series device but the peer’s
certificate chain does not contain any policy OIDs, certificate validation
No Policy OIDs Configured on MX Series Devices
If no policy OID is configured on the MX Series device, policy
validation starts whenever the
requireExplicitPolicy field is encountered in the certificate chain. A certificate may
contain one or more certificate policy OIDs. For policy validation
to succeed, there must be a common policy OID in the certificate chain.
Figure 1 shows a certificate chain that consists of certificates for
a root CA, three intermediate CAs, and an EE. The CA certificate for
Int-CA-2 contains the
requireExplicitPolicy field; therefore, policy validation starts with Int-CA-2 and continues
through EE-1. The certificate for Int-CA-2 contains policy OIDs P1,
P2, and P3. The certificate for Int-CA-3 contains policy OIDs P2,
P3, and P4. The certificate for EE-1 contains policy OIDs P2 and P5.
Because the policy OID P2 is common to the certificates being validated,
policy validation succeeds.
in an intermediate CA certificate indicates the number of certificates,
including the current CA certificate, that are to be excluded from
policy validation. If
0, policy validation starts from the current certificate. If
skipCerts is 1, the current certificate is excluded
from policy validation. The value of the
skipCerts field is checked in every intermediate CA certificate. If a
skipCerts value is encountered that is lower than
the current number of certificates being excluded, the lower
skipCerts value is used.
Figure 2 shows
a certificate chain consisting of a root CA, four intermediate CAs,
and an EE. The
skipCerts value in
Int-CA-1 is 12, which skips 12 certificates including the certificate
for Int-CA-1. However, the
skipCerts value is checked in every intermediate CA certificate in the chain.
skipCerts value in Int-CA-2 is
2, which is lower than 12, so now 2 certificates are skipped. The
skipCerts value in Int-CA-4 is 5, which is greater
than 2, so the Int-CA-4
skipCerts value is ignored.
When policy OIDs are configured on the MX Series device, the
skipCerts are ignored.
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
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
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.
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.
The key usage field in an EE or CA certificate defines the purpose of the key contained in the certificate.
For EE certificates, if the key usage field is present but the
certificate does not contain
nonrepudiation flags, the certificate
is rejected. If the key usage field is not present, then key usage
is not checked.
The key can be used for certificate or CRL signature validation. Because the PKI daemon is responsible for both X509 certificate validation and CRL downloads, key usage must be checked before validating the certificate or CRL.
Certificate Signature Validation
keyCertSign flag indicates
that a CA certificate can be used for certificate signature validation.
If this flag is not set, certificate validation is terminated.
CRL Signature Validation
In Phase 1 negotiations, participants check the certificate
revocation list (CRL) to see if certificates received during an IKE
exchange are still valid. The CRL is periodically downloaded for CA
profiles configured with CRL as the certificate revocation check.
Downloaded CRL files must be verified before they are downloaded into
the device. One of the verification steps is to validate the CRL signature
using a CA certificate. The downloaded CRL is signed with the CA certificate’s
private key and it must be verified with the CA certificate’s
public key stored in the device. The key usage field in the CA certificate
must contain the
CRLSign flag to
verify the downloaded CRL. If this flag is not present, the CRL is
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.
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.