Certificate Validation


The Public Key Infrastructure (PKI) describes a method of asserting the identity (Authentication) and validity of a Digital Subject that you have not previously met or interacted with through the use of Certificates containing identifying information and public keys (these certificates are more properly called X.509 certificates).

Public Key Infrastructure accomplishes this by defining a Certificate Authority who is mutually trusted by all users of the Public Key Infrastructure system.

Every time before using a key or Certificate the validity of a Certificate should be checked . In case of stolen or outdated certificates, these certificates will be revoked. Meaning, that before you trust the authentication of a message from anybody using his certificate, you should perform Certificate Validation.

The following logical diagram shows how this works where the "User" is presenting my credentials to a Relying Party to setup a trusted communication path.

Certificate Validation is described in RFC 5280 which is notoriously complex due to issues of backwards compatibility with older X.509 standards. We can still easy to describe the overall process used by end user software to perform Certificate Validation.

Certificate’s Integrity#

The first step of validating a certificate is to first verify the certificate’s integrity. This is done by first creating a one way hash of the certificate contents (using the hash algorithm indicated in the certificate). This hash is stored temporarily in memory. Next, the Digital Signature embedded in the certificate is decrypted using the Public Key included in the certificate (or, for Certificate Authority issued certificates using the Public Key from the Certificate Authority root certificate). The decrypted Digital Signature (which is again a hash of the certificate contents) is then compared to the hash that was computed locally. If the hashes match, then the user knows that the certificate has not been altered since it was created.

Certificate Validity Period#

Next, the certificate is checked to ensure that it has not expired. This is done by verifying that the current time falls within the Certificate Validity Period included in the Certificate.

Certificate KeyUsage#

Next, the certificate KeyUsage fields are checked to ensure that the certificate is being used for the purpose it was intended (via the KeyUsage field). For example, if the KeyUsage field of a certificate is set to cRLSign but the Certificate is presented by a bank website, the Certificate is not being used as intended and will (well Should) be rejected.

Validation of the Certificate Issuer#

Validation of the Certificate Issuer bears more discussion as it is the validation step that is most important in trusting a Certificate. An important field embedded in a X.509 certificate is the Certificate Issuer field. The Certificate Issuer field lists the name of a Certificate Authority which has vouched for the validity of the Certificate.

Recall the step where the integrity checks are performed. The user must decrypt the digital signature using a Public Key.

Instead of using the Public Key embedded in the Certificate, the user looks at the Certificate Issuer field to identify a Certificate Authority certificate, or Root Certificate that contains the Public Key that should be used to verify the Certificate. The Root Certificates are stored locally on the user-agent in a Trust Anchor Store, so the software searches through this list to fetch the correct Root Certificate.

Once the Root Certificate has been found, the Public Key from the Root Certificate is used to decrypt the Certificate Signature in the Certificate being validated. If the signature is validated, the user knows that the owner of the Root Certificate (the Certificate Authority), has signed the Certificate being presented and therefore vouches for the contents of the Certificate.

We show some more technical details about how this is performed in Verifying Certificate Signatures.

Certificate Revocation#

At this point, the only remaining step is to verify the Certificate Revocation Status.

hostname Verification[2]#

One final check that we need to do is to verify that name of the host name or IP address that was used to initiate the secure connection resides in the Certificate Subject or Subject Alternative Names of the certificate.

The "*" wildcard character is allowed. If present, it applies only to the left-most Certificate Subject or Subject Alternative Names component.

E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate the Certificate Subject or Subject Alternative Names, a match in any one of the set is considered acceptable.

This check helps prevent against a Man-In-The-Middle attack because we are implicitly trusting that the Registration Authority on the Certificate Chain would not do something bad, like sign a certificate claiming to be from Amazon.com unless it actually was Amazon.com. If an attacker is able to modify your DNS server by using a technique like DNS cache poisoning, you might be fooled into thinking you’re at a trusted site (like Amazon.com) because the address bar will look normal. This last check implicitly trusts certificate Authorities to stop these bad things from happening.

Nelson Bolyard’s comment in the SSL_AuthCertificate function explains why:

/* cert is OK. This is the client side of an SSL connection.
 * Now check the name field in the cert against the desired hostname.
 * NB: This is our only defense against Man-In-The-Middle (MITM) attacks! 

Browsers and some other applicaitons often will NOT check the Certificate Subject field against the Hostname requested but rather only check the Subject Alternative Names and only if there is a DNS type present.

OpenSSL versions prior to 1.0.2 did not perform hostname validation. OpenSSL added hostname validation in January 2015 but it is only utilized when requested.

From RFC 6125 Section 2.3 says:
However, it is perfectly acceptable for the Certificate Validation field to be empty, as long as the certificate contains a Subject Alternative Name (subjectAltName) extension that includes at least one subjectAltName entry, because the subjectAltName extension allows various identities to be bound to the Certificate Validation (see Section of PKIX). The subjectAltName extension itself is a sequence of typed entries, where each type is a distinct kind of identifier.

For our purposes, an application service can be identified by a name or names carried in the subject field (i.e., a CN-ID) and/or in one of the following identifier types within subjectAltName entries:

Existing certificates often use a CN-ID in the subject field to represent a fully qualified DNS Domain name; for example, consider the following three subject names, where the attribute of type CommonName contains a string whose form matches that of a fully qualified DNS Domain name ("im.example.org", "mail.example.net", and "www.example.com", respectively):
  • CN=im.example.org,O=Example Org,C=GB
  • C=CA,O=Example Internetworking,CN=mail.example.net
  • O=Examples-R-Us,CN=www.example.com,C=US
However, the Common Name is not strongly typed because a Common Name might contain a human-friendly string for the service, rather than a string whose form matches that of a Fully Qualified Domain Name (a certificate with such a single Common Name will typically have at least one subjectAltName entry containing the Fully Qualified Domain Name):
  • CN=A Free Chat Service,O=Example Org,C=GB
Or, a certificate's subject might contain both a CN-ID as well as another common name attribute containing a human-friendly string:
  • CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
In general, this specification recommends and prefers use of subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the subject field (CN-ID) where possible, as more completely described in the following sections. However, specifications that reuse this one can legitimately encourage continued support for the CN-ID identifier type if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, EV-CERTS).

Real World [3]#

The DNS Domain of the URL MUST match the Certificate Subject of the certificate. In former times this could be either by setting the domain as cn of the certificate or by having the domain set as a Subject Alternative Name. Support for cn was deprecated for a long time (since 2000 in RFC 2818) and Chrome browser will not even look at the cn anymore so today you need to have the DNS Domain of the URL as a Subject Alternative Name.

There can be multiple Subject Alternative Name and thus the certificate can be used for multiple DNS Domains.

RFC 6125 which forbids checking the cn if SAN for DNS Domain is present, but not if SAN for IP Address is present. RFC 6125 also repeats that cn is deprecated which was already said in RFC 2818. And the Certification Authority Browser Forum to be present which in combination with RFC 6125 essentially means that cn will never be checked for DNS Domain name.

However, RFCs and/or the CA-Browser Forum can forbid anything, but REAL LIFE implementations do NOT yet follow in this case even by widespread products. Being familiar with theory and RFC, but having to deal with reality, where different rules are working. Reality says, that apart from Chrome, most implementations DO NOT deprecate Certificate Subject field.

Microsoft Windows (and their tools), there are a lot of use cases where SAN is not mandatory. Moreover, I know only one use case (within Windows platform) when SAN is required.

Firefox a non-empty Subject Alternative Names list overrides and replaces the Common Name (cn]) field. So you MUST to list all relevant Hostnames in the Subject Alternative Names field in your certificate.(2016)


In summary, the Certificate Validation process is complex and resource intensive. The PKIX community has recognized this as becoming more of a problem with the prevalence of mobile devices that have limited processing resources. A solution that is being proposed is a mechanism to offload the responsibility of performing all of the Certificate Validation steps to a centralized server that is trusted by users. This mechanism is called Server-Based Certificate Validation Protocol defined in RFC 5055.

Certificate Level Of Assurance#

Certificate Validation Tools#

We have spotted some Certificate Validation Tools you may find helpful.

More Information#

There might be more information for this subject on one of the following: