Overview[1]#

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 Key Usage#

Next, the certificate usage fields are checked to ensure that the certificate is being used for the purpose it was intended (via the Certificate Key Usage field). For example, if the Certificate Key Usage 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! 
 */

Summary#

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:

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
jpg
pki-simple-diag.jpg 33.6 kB 1 10-Apr-2013 10:28 jim
« This page (revision-41) was last changed on 23-Jan-2017 11:31 by jim