1 Certificate Validation and Revocation

1.1 Background

One important concept to understand when troubleshooting certificates. This blog covers the basics of understanding certificate validation. Then towards the end, I cover troubleshooting steps.

1.2 Identity Validation

Certificates bind an identity to a public key. And one of the reasons that we use certificates is to ensure that we are accessing the resource that we intend to access. Therefore, we expect the identity in the certificate to match the identity we are trying to access. For example, if you enter the following URL in your web browser: https://www.microsoft.com, you would expect that the identity www.microsoft.com would be included in the certificate. There are two possible fields in the certificate where this identity information can be located: Subject and Subject Alternative Name. The Subject is a Version 1 field that will typically only contain one identity. The Subject Alternative Name field is an extension and is typically used when there is more than one identity in the certificate. For some applications such as SSL, the subject will be ignored if the SAN is populated. Below is an example of an error a user might receive if there is a mismatch between the identity that they are trying to contact and the identity in the certificate.

1.3 Chain Validation

In order to determine if a certificate is trusted, you need to build a chain to the root certificate. Once the chain is built to the root certificate you can determine whether or not the root certificate is trusted. To validate the chain, you must have possession all of the certificates in the chain and then you can build the chain from the end-entity certificate all the way up to the root certificate, which is a self-signed certificate where the chain terminates. I will discuss more about Chain Validation later on in this document.

1.4 Validity Period Validation

Certificates also have a period of time for which they are valid. In other words, a certificate is valid for a certain period of time. This built in expiration mechanism helps increase the security of certificates. This is due to the fact that if a certificate is compromised and that compromise is not detected it will eventually expire and become invalid.

The Valid From field is when the certificate begins its validity period and the Valid To field indicates when a certificate ends its validity period. In order for a certificate to be valid from a time perspective, the current date should fall in between the Valid From and Valid To dates specified in the certificate.

1.5 Certificate Revocation Validation

When a Windows client checks the revocation status of a certificate it checks revocation for that certificate and every certificate in the chain excluding the Root CA certificate.

The client will first check to see if it has any time valid OCSP Responses or CRLs cached locally.
If an OSCP URI has been deployed via Group Policy the client will send and OCSP response to the OCSP Responder. The OCSP responder then should send a response back to the client informing the client whether or not the certificate has been revoked.
If an OCSP URI is included in the AIA extension of the certificate the client will send and OCSP response to the OCSP Responder. The OCSP responder then should send a response back to the client informing the client whether or not the certificate has been revoked.
If there is no OCSP URI Specified the client will download the Base CRL. If the Base CRL has a Freshest CRL extension the client will then download the Delta CRL. The client will then parse the CRL(s) to determine if the certificate has been revoked.

1.6 Certificate Chaining

As mentioned earlier a certificate needs to be chained to a root certificate in order to determine if the certificate chains to a trusted root. There is information included in certificates to assist in this chain building process. The most common type of information I see used to help the system identify the chain or the Subject Key Identifier (SKI) field and the Authority Key Identifier (AKI) field. The Authority Key Identifier is a hash of the certificate issuers public key. The Subject Key Identifier is a hash of the public key in the current certificate. The Operating System can chain a certificate by matching the Authority Key Identifier field in a certificate to the Subject Key Identifier in the issuer’s certificate. Matching the Authority Key Identifier field in the certificate to the Subject Key Identifier of the issuer is commonly called a key match.

Keep in mind not only do the fields have to match but the signature needs to verify as well. A certificate is digitally signed by the issuer. This means the certificate data was passed through a hashing algorithm and then the resulting hash is encrypted with the private key of the issuer. The signature can be verified by hashing the same certificate data, decrypting the digital signature with the public key of the issuer, and comparing the hashes. If the resulting hashes match and the digital signature can be decrypted with the issuer’s public key then the signature is verified.

Below is an example of a key match:

1.6.1 Retrieving CA Certificates / AIA

Remember that the verifier of the certificate must have all certificates in the chain. The verifier will have access to the certificate it is verifying usually during a handshake during a protocol setup. Intermediate certificates may also be distributed the same way. However, if the intermediate certificates are not distributed during the protocol handshake they can be downloaded from the AIA repository. There is an extension named Authority Information Access that is commonly included with certificates. The AIA extension usually has a url which indicates from where the issuer’s certificate can be retrieved from. Windows supports two protocols for retrieval of CA certificates via the AIA Repository: LDAP and HTTP. Also, keep in mind that you have multiple AIA locations specified in the AIA extension of the certificate. Those AIA locations are processed in the order in which they are present the AIA extension.

Below is an example of the AIA extension in a certificate:

1.6.1.1 LDAP Repository

When we talk about using an LDAP repository to host CA certificates we typically mean using the LDAP functionality of Active Directory. Although, other ldap providers can be used for hosting CA certificates it is less common and does not provide the same level of integration as Active Directory.

There are some significant advantages and disadvantages to using LDAP as an AIA repository:

1.6.1.1.1 Advantages

High Availability: When using Active Directory as the LDAP provider, there is built-in fault tolerance. This is due to the fact that the AIA location is stored in the Configuration container that is replicated to all Doman Controllers in the forest.

Site Awareness: Active Directory has built-in site awareness. Clients use DCLocator to find the nearest DC, so clients will be able to pull certificates from a local Domain Controller.

1.6.1.1.2 Disadvantages

3^rd Party Support: PKI can be leveraged by 3^rd party Operating Systems and applications. Many of these are not integrated into Active Directory and hence cannot access the Active Directory LDAP provider.

Insecure Networks: Providing access to Active Directory LDAP over insecure networks such as a DMZ or Public Network would be a security nightmare so it would not be a good practice to use LDAP if clients on an insecure network need to retrieve the CA Certificates from AIA.

1.6.1.2 HTTP Repository

Using an HTTP or Web Repository is a more common practice. This is especially true for Public or 3^rd Party CAs. If using an HTTP repository, it is important that the repository can be located by a DNS name and that the DNS name is not tied to a specific machine. In other words, you would likely use a CNAME or an A record that is not the computer name of the Web Server.

1.6.1.2.1 Advantages

Insecure Networks: Just about every organization is familiar on how to make the http protocol accessible in DMZ’s or over the Internet.

3^rd Party Support: The virtual directory where the CA certificates are made accessible is normally configured to allow anyone to read and hence download the CA certificates.

1.6.1.2.2 Disadvantages

High Availability: A web server by itself is not highly available. Additional work and resources must be brought to bear to make a website highly available including having multiple web servers typically behind a load balancer.

Site Awareness: If you wish to make the HTTP AIA repository available locally to every site it requires additional web servers and a load balancer that will re-direct clients to the closest web server.

1.6.1.3 AIA Design Considerations

When you are in the process of building a PKI you have to decide where the AIA locations are going to be located and how the names used to access those locations are going to be formed. A common practice for 3^rd Party Certification Authorities is just to use a single http URL inside of the AIA extension. Then that web location is made available from a highly available provider such as a Content Delivery Network (CDN). For your own internal PKI you have a number of possible ways to make the HTTP AIA location highly available. You could use for instance Azure CDN to provide a highly available solution. Alternatively, you could stand up several web servers behind a load balancer to provide this functionality. Regardless, when you design the name for the AIA location you will want to choose a name that is not tied to a specific machine name. Even if you do decide to go against best practices and host the HTTP AIA location on the CA itself, you would still want to use some sort of alias instead of the machine name. This configuration would allow you flexibility in the future if you ever decide to move that location to another machine. This is due to the fact that aside from reconfiguring where the certificate was published you would simply just need to update where that DNS alias is pointed instead of having to re-configure the AIA location which would require renewing the CA certificate to update the extension in that certificate. Additionally, if you plan on using the PKI to secure internet facing resources you would want to ensure that the DNS name used for the AIA location is not just resolvable internally, but also externally. Aside from the HTTP location some organizations decide to leverage LDAP as a secondary AIA location that would be available if the HTTP location is inaccessible.

1.7 Root Certification Authority Certificates

The Root CA’s primary function is to be the trust anchor for the PKI. When a system trusts a Root CA, then that trust extends to subordinate CAs that chain to that same root and the certificates that they issue.

In order for a Root CA to be trusted on a Windows system the Root CA certificate must be present in the Trusted Root Certification Authorities store. Keep in mind there Trusted Certification Authorities container in both the Computer certificate store and the User certificate store. Trusted Root CA Certificates present in the Computer store are inherited by the user. There are a number of ways that a Root CA certificate can be populated in that store.

1.7.1 Microsoft Root Certificate Program

Microsoft has a program where 3^rd Party CAs can submit their certificate to be installed in the Trusted Root Certification Authorities store. These are the Root CA certificates that ship with Windows. The advantage to this approach is that a user or organization does not need to go out download and install the Trusted Roots for popular 3^rd Party CAs.

1.7.2 Group Policy

Root CA Certificates can be deployed via Group Policy. This is a common way organizations deploy Root CA Certificates for the PKI of a trusted organization. Root CA certificates may also be deployed this way during a Merger or Acquisition.

1.7.3 Autoenrollment

Autoenrollment performs a variety of functions. One of those functions is to download Enterprise Certificates from Active Directory. Enterprise Certificates includes the Root CA certificates that are published to the Certification Authorities container as well as downloading Subordinate CA certificates from the Authority Information Access container in Active Directory. All of these containers are located in the Configuration Partition of Active Directory.

1.7.4 Manual

Unless otherwise prevented by Group Policy users can add Root CA certificates in the Trusted Root Certification Authority container in the user store. A user that has administrator privileges can also add Root CA certificates to the Trusted Root Certification Authorities container in the Computer certificate store.

1.8 Chain Building Summary

In order to determine whether or not a certificate should be trusted, the certificate chain must be built. Starting with the certificate that is being validated, the validator locates the next certificate in the chain. If that certificate is an intermediate CA that cert can be retrieved locally from the Intermediate Certification Authorities container, passed to the validator during the protocol handshake for whatever protocol is using the certificate, or retrieved from the AIA extension in the certificate. This process continues until it reaches a self-signed certificate or in other words a Root CA certificate. If that Root CA certificate exists in the Trusted Root Certification Authority store that the certificate being validated is considered trusted.

1.9 Revocation

Certificates do have a limited time for which they are valid. This built-in expiration mechanism enhances the security of certificates. However, there are times where you may no longer trust a certificate before it expires. There are several possible reasons why you may no longer trust a certificate. Some of those reasons include: the certificate was compromised, the computer was compromised, or the user left the company. When you no longer trust a certificate you can revoke. Once the certificate is revoked, applications that perform revocation checking will no longer trust the certificate. More specifically the CA Manager and Certificate Manager can revoke the certificate. When an administrator revokes a certificate they must specify a reason for the revocation. These reason include: Unspecified, Key Compromise, CA Compromise, Change of Affiliation, Superseded, Cease of Operation, and Certificate Hold. If the Certificate Hold reason is selected, the certificate can later be unrevoked.

1.9.1 Revoking a Certificate

The following steps can be taken to revoke a certificate

Step 1: To revoke a certificate the Certificate Manager open the Certification Authority MMC (certsrv.msc)

Step 2: Click on Issued Certificates

Step 3: Right-click on the certificate that needs to be revoked

Step 4: From the context menu click All Tasks and the Revoke Certificate

Step 5: Select a reason for the revocation

Step 6: Click OK

The Revoked Certificate will show up under Revoked Certificates. The certificate will not be known to be revoked until the CRL is published to the CDP and subsequently downloaded and parsed by clients checking revocation.

1.9.2 Certificate Revocation List (CRL)

A Certificate Revocation List contains a list of certificates that have been revoked. Specifically, CRLs contain the Serial Number of each certificate that has been revoked, along with the reason for revocation, and the date and time that the certificate was revoked. There are two types of CRLs: Base CRLs and Delta CRLs. Base CRLs contain a list of all non-expired certificates that have been revoked. Delta CRLs contain a list of non-expired certificates that have been revoked since the last Base CRL was published. The lists from the latest Base CRL and Delta CRL can be combined to get a list of all non-expired certificates that have been revoked. Delta CRLs were implemented so that clients would not have repeatedly download a base CRL which would be larger in size. So, instead of publishing a Base CRL more frequently, delta CRL can be published instead. Delta CRLs are optional you can just use a Base CRL if that better fits the requirements for your organization.

1.9.3 CRL Fields

In this section I will discuss the various fields that are included in a CRL.

1.9.3.1 Version

This is the Version of the CRL Profile that is being used. The current version of the CRL Profiles is Version2.

1.9.3.2 Issuer

The Issuer field indicates which CA issued the CRL.

1.9.3.3 Effective date

This is the date and time at which a CRL becomes effective.

1.9.3.4 Next update

Next update indicates the date and time at which the CRL will be expired.

1.9.3.5 Signature Algorithm

The Signature Algorithm field indicates what Asymmetric Cryptographic Algorithm and Hashing Algorithm were used to sign the CRL.

1.9.3.6 Signature Hash Algorithm

The Signature Hash Algorithm field indicates the Hashing Algorithm used when signing the CRL

1.9.3.7 Authority Key Identifier

The Authority Key Identifier is another way of identifying the issuer of the CRL. Specifically, the Authority Key Identifier field contains a hash of the issuer’s public key

1.9.3.8 CA Version

The CA Version Field list the version number for the CA Certificate that was used to sign the CRL.

1.9.3.9 CRL Number

The CRL Number indicates the version of the CRL. The CRL Number increments each time a new CRL is published.

1.9.3.10 Next CRL Publish

The Next CRL Publish field indicates the date and time at which the next CRL will be published.

1.9.3.11 Published CRL Location

Published CRL Location is the location at which the CRL will be published in Active Directory. This is typically

1.9.3.12 Freshest CRL

If a CA publishes Delta CRLs then the Freshest CRL extension will show the location(s) where Delta CRLs can be retrieved.

1.9.3.13 Revocation List

The Revocation List will list every non-expired certificate that has been revoked. This list will include the Serial Number and revocation date. Depending on the reason code selected it may also list the reason for the revocation.

1.9.4 Delta CRL

A Delta CRL contains a list of all non-expired certificates that have been revoked after the publication of the Base CRL. To determine the location of the Delta CRL the Freshest CRL extension of the Base CRL must be read or known. To determine revocation, the current Base CRL and latest Delta CRL must be available.

1.9.4.1 Delta CRL Indicator

A Delta CRL has the same extension and formatting as a base CRL. A Delta CRL also has a field called Delta CRL Indicator. This field indicates which base CRL the client must have to have complete knowledge of revocations.

1.9.5 CRL Distribution Points (CDP)

The CRL Distribution Points extension is an extension in a certificate that indicates where the CRL can be retrieved from for the purposes of checking revocation. That location where the CRLs can be retrieved is often referred to as a CDP repository. Some of the same concepts that apply to the Authority Information Access extension apply here, but I have listed them below for completeness.

1.9.5.1 LDAP Repository

There are some significant advantages and disadvantages to using LDAP as an AIA repository:

1.9.5.1.1 Advantages

Site Awareness: Active Directory has built-in site awareness. Clients use DCLocator to find the nearest DC, so clients will be able to pull certificates from a local Domain Controller.

1.9.5.1.2 Disadvantages

1.9.5.2 HTTP Repository

1.9.5.2.1 Advantages

Insecure Networks: Just about every organization is familiar on how to make the http protocol accessible in DMZ’s or over the Internet.

3^rd Party Support: The virtual directory where the CA certificates are made accessible is normally configured to allow anyone to read and hence download the CA certificates.

1.9.5.2.2 Disadvantages

1.9.5.3 CDP Design Considerations

When you are in the process of building a PKI you have to decide where the CDP locations are going to be located and how the names used to access those locations are going to be formed. A common practice for 3rd Party Certification Authorities is just to use a single http URL inside of the CDP extension. Then that web location is made available from a highly available provider such as a Content Delivery Network (CDN). For your own internal PKI you have a number of possible ways to make the HTTP CDP location highly available. You could use for instance Azure CDN to provide a highly available solution. Alternatively, you could stand up several web servers behind a load balancer to provide this functionality. Regardless, when you design the name for the CDP location you will want to choose a name that is not tied to a specific machine name. Even if you do decide to go against best practices and host the CDP AIA location on the CA itself, you would still want to use some sort of alias instead of the machine name. This configuration would allow you flexibility in the future if you ever decide to move that location to another machine. This is due to the fact that aside from reconfiguring where the CRL was published you would simply just need to update where that DNS alias is pointed instead of having to re-configure the CDP location which would require renewing the CA certificate to update the extension in that certificate. Additionally, if you plan on using the PKI to secure internet facing resources you would want to ensure that the DNS name used for the CDP location is not just resolvable internally, but also externally. Aside from the HTTP location some organizations decide to leverage LDAP as a secondary CDP location that would be available if the HTTP location is inaccessible.

1.9.5.4 CRL Publishing

So, how do we maximize the amount of time we have for recovery, and at the same time increase the “freshness” of the CRL? We can do this with the use of Overlap Periods.

So, let’s say we want to implement this solution that maximizes recovery time and increases CRL freshness. The first consideration is Delta CRLs. Since Delta CRLs in my view are not necessary in most instances, we will first get rid of Delta CRLs. So, now that gives us just Base CRLs to work with. Let us take our Base CRL and make it valid for a period of 3 days. So, at first you would think great, now I have 3 days to recover the CA if the CA fails since the CRL is valid for 3 days. Well this is not true. If the validity period of the CRL and the publishing interval coincide, then you could have as little time as 1 second depending on when the CA failed. The illustration below exemplifies this scenario. The problem is without changing the default configuration the Next Update and Next Publish fields will be very close together, providing very little time for recovery.

1.9.5.5 Introducing CRL Overlap Period

As mentioned there is some additional configuration that can be performed that can optimize your CRL publishing intervals so that you have adequate time to perform Emergency CRL Signing or to recover your CA. What will need to be configured is the CRL Overlap Period. In order to configure the CRL Overlap Period both the CRLOverlapUnits and CRLOverlapPeriod registry settings need to be configured.
So, in my previous example my CRL had a validity period of 3 days. What I can do now is add a CRL Overlap Period of 3 days. With this configuration, my CRL will be valid for a period of 6 Days. However, at 3 days a new CRL will be published as well. This is illustrated in the graphic below:

In the example illustrated in the graphic above, CRL 1 will be valid for a period of 6 days. CRL 2 will be published at Day 3. So, if my CA fails between Day 1 and Day 3, I would still have 3 Days (Day 3 through Day 6) to perform Emergency CRL signing or to recover my CA in event of failure. If my CA fails between Day 3 and Day 6, there is a new CRL (CRL 2) that is valid through Day 9. So, in short if my CA fails between Day 3 and Day 6, I still have at least 3 days to perform Emergency CRL Signing or to recovery my CA, before revocation checking starts to fail. And the reason that I have the 3 days is the CRL Overlap Period extended out my CRL for 3 days and staggered the Next Publish and Next Update times by 3 days.

1.10 Troubleshooting Certificate Validation

There are several tools that you can use to troubleshooting Chain Building and Revocation.

1.10.1 Windows UI

You can use the errors visible in the Windows UI to troubleshoot Certificate Validation. Below are a sample of some errors you may encounter in the Windows UI.

This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store.

This error simply indicates that the Root CA Certificate is not trusted.

Windows does not have enough information to verify this certificate.

This error indicates that the client verify the certificate does not have access to all of the certificates in the chain.

The issuer of this certificate could not be found.

This error indicates that the client verify the certificate does not have access to all of the certificates in the chain.

This certificate has expired or is not yet valid.

This error typically indicates that the certificate is expired.

1.10.2 Certutil -verify -urlfetch

Certutil -verify -urlfetch is perhaps the best tool to check the validation of a certificate. You will want to run this tool on a machine which appears to have validation issues. For example, if a client is visiting a website that is secured with TLS you would want to copy the certificate to the client and run this tool from the client. This command does all of the validation checks including checking of the AIA, CDP, and OCSP locations are accessible and contain valid configuration. The normal syntax for running the command is: certutil -verify -urlfetch [File Name of Certificate] > [Name of Output Text File].

Below are screenshots or a sample output of certutil – verify -urlfetch to help you better understand how to read this file.

Here are some of the information or error messages you can receive at the end of the output from the command:

Leaf certificate revocation check passed

Indicates that the certificate passed the verification check.

A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. 0x800b0101 (-2146762495 CERT_E_EXPIRED)

Typically means the certificate is expired.

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

This means that the verifier was unable download a CRL.

The certificate is revoked. 0x80092010 (-2146885616 CRYPT_E_REVOKED)

Indicates that the certificate has been revoked.

Conclusion

That covers certificate validation. For additional information see the following video.

-Chris