Table of contents:

• Understanding certificate chains
• Exploring SSL certificates in action
• Building the Certificate Chain
  • Local certificate store method
  • PKCS#7 method
  • Authority Information Access method
  • Crypt32.dll and Microsoft Update
• Binding Certificates
  • Binding Certificates: Exact Match
  • Binding Certificates: Key match
  • Binding Certificates: Name match
• Signature validation
• And more...
• Conclusion
• Related links

---

Often the certificate path/revocation checking issues that certification authority (CA) admins encounter are caused by invalid CDP (CRL Distribution Point) or AIA (Authority Information Access) configuration. This article covers the Certificate Chaining Engine (CCE) and how it can be used for troubleshooting purposes.

Just like symmetric and asymmetric encryption, certificate chains, and certificate trusts, the CCE is a public key infrastructure (PKI) fundamental. Millions of people see results the CCE everyday when their certificates either work or do not work.

The following terms and abbreviations are used in this document:

• PKI (Public Key Infrastructure) — provides an organization with the ability to securely exchange data using public key cryptography. PKI consists of Certification Authorities (CAs) that issue digital X.509 version 3 certificates and directories that can store the certificates. PKI provides validation of certificate-based credentials and ensures that the credentials are not revoked, corrupted, or modified.
• CA (Certification Authority) — a third party that issues public key certificates. Certificates serve to bind public keys to a user identity. Each user and certificate authority may decide whether to trust another user or CA for a specific purpose, and whether this trust should be transitive.
• CryptoAPI — a cryptography subsystem that is responsible for all cryptography operations in Microsoft Windows operating system.
• CRL (Certificate Revocation List) — a digitally signed list issued by Certification Authority (CA) that contains a list of certificates issued by CA that have been revoked. For each individual revoked certificate, the listing includes the serial number of the certificate, the date of the revoked certificate, and the revocation reason. Applications can perform CRL checking to determine a presented certificate’s revocation status.
• Root CA (Root Certification Authority) — CA server that acts as a root CA server in the PKI hierarchy. It is always presented in a self-signed form where Subject and Issuer fields are identical.
• Issuing SubCA (Subordinate Certification Authority) — CA server that acts as an intermediate (subordinate) CA server in the PKI hierarchy. Normally, root CAs do not issue certificates to end entities, instead root CAs delegate this right to one or more subordinate CA.
• AIA (Authority Information Access) — a certificate extension that contains information useful for verifying the trust status of a certificate. This information potentially includes Uniform Resource Locations (URLs) where the issuing CA’s certificate can be retrieved, as well as location of an Online Certificate Status Protocol (OCSP) responder configured to provide status for the certificate in question. AIA extension can potentially contain HTTP, or LDAP URLs.

Understanding certificate chains

There is a limited number of CA vendors/providers who are globally trusted. The list includes (but not limited to) vendors like Symantec (formerly VeriSign), Thawte, DigiCert, Global Sign, StartCom, GoDaddy, Comodo and others. Each vendor uses at least one globally trusted root CA which provides trust services. Normally, they do not issue certificates to end clients (certificate subscribers), instead they delegate this task to subordinate CAs. The common PKI hierarchy is outlined in the Figure 1:

In the current example, we have one root CA, three subordinate CA and multiple client certificates issued directly by subordinate CAs. If necessary, additional levels of subordinate CAs may be added. This allows CA vendors to constraint their CAs by policies. For example, one subordinate issues SSL certificates, second CA issues code signing certificates, e-mail, client authentication certificates and so on. PKI hierarchy at lower levels may be very wide and include dozens of CAs and countless of end entity certificates. To simplify trust process the following behavior is used in internet PKI:

All certificates are chained through certification path building, when the path is constructed for each certificate up to root CA through a number of intermediate subordinate CA certificates. In the most simple form this chain would look as follows:

Each block consist of two entries: Issuer (top) and Subject (bottom). Figure 2 shows that Root CA is an issuer and the subject at the same time and is self-signed, the rest certificates are not self-signed. Such certification path is called certificate chain.

The purpose of certification path (or certificate chain) is to determine whether the certificate was issued by a trusted authority and certificate holder’s identity was validated by CA. Certificate trust is determined whether the client trusts particular root CA or not. The trust to root CA is always explicit. Each operating system, 3rd party web browsers and custom applications ship a bundle of trusted root CA certificates. Non-root certificates are trusted implicitly and are not required to be shipped with OS, web browser or certificate-aware application. That is, if we are presented with a certificate and we can build the certification path up to locally trusted root CA, the certificate is considered valid. If the chain ends with root CA which is not trusted by local system/application or root CA certificate is unavailable, the certificate is considered invalid.

It is important to understand that explicit trust is available only for root (self-signed) certificates. Explicit trust for intermediate certificates is not possible. They are always trusted implicitly through the trust to root CA.

The following sections will describe the certification path construction process and methods based on a Microsoft Windows operating system example. Other operating systems (*nix, MacOS) shares most of these methods, though, not all options may be available and may add their own chain building methods.

Exploring SSL certificates in action

In order for any specific certificate to be trusted, the certificate chain up to the root CA must be trusted explicitly by your operating system system or application (for example, Mozilla FireFox web browser which uses its own list of trusted CAs). Certificate trust is determined by the CCE by building certificate chain (also known as Certification Path). Let's see certificate chains on common examples — SSL web sites. When entering the https://letsencrypt.org web site (Figure 3) you see a padlock icon indicating that the site's SSL certificate is trusted by your system . However, entering the https://www.cacert.org web site, you see an error message and red 'X' (Figure 4). Both messages are the result of the certificate chaining engine validation process.

How certificates in the certificate chain are obtained? Certificates can be (1) added into the operating system, (2) integrated into an application when it is released or (3) installed by a systems or application administrator.

↑ Back to the top

Building the Certificate Chain

Windows operating system uses the following methods for retrieving certificates for certificate chains:

1. Via the local certificate store;
2. Using a PKCS#7 container with a full or a partial chain;
3. Using the Authority Information Access (AIA) extension;
4. Crypt32.dll and Microsoft Update web site.

↑ Back to the top

Local certificate store method

This is the first method used by CryptoAPI to obtain possible certificates for the certificate chain. The following local certificate containers are used: Trusted Root CAs, Intermediate CAs and Third Party Root CAs. As example, you can examine Symantec Class 3 EV SSL CA - G3 CA certificate. Symantec's Extended Validation CA certificate does not contain any information about the issuer. This is because Symantec (formerly VeriSign) is globally trusted issuer and its certificates are installed on each Windows operating system and in all major web browsers. The CryptoAPI uses local certificate store search to obtain required certificate that reduces certificate chain building time. However this is applicable only to CA certificates that were already installed by an application supplier (OS or browser vendor, for example). If the local certificate store does not contain the required certificates, other certificate retrieval methods are attempted.

↑ Back to the top

PKCS#7 method

The PKCS#7 certificate retrieval method is very common on the web. A PKCS#7 message can store multiple certificates and as such acts as a certificate container. This method allows server applications to simplify certificate chain building by delivering the client (leaf) certificate with the complete or partial certificate chain and it is defined in the RFC 5246 §7.4.2. Major web servers, Apache and Microsoft IIS send to client all certificates (except root) by default and no extra configuration is needed to support PKCS#7.

The client application use these certificates, if presented, for certificate chain building purposes. To demonstrate PKCS#7 method in action, visit the the https://trust.beeline.ru/ web site. If warning message appear, temporarily bypass it and check certificate statuses as shown in Figures 5 and 6:

We can see that web browser show us VimpleCom ExternalCA certificate. Now, let’s do the trick, save SSL certificate to a file and open it from desktop:

Now, we don’t see Vimpelcom ExternalCA certificate in the chain. This is because, Beeline’s web server send us issuer certificate during SSL/TLS session and web browser used it to build the chain. When we open SSL certificate from desktop, we don’t see issuer certificate, because it is not available outside of SSL context.

Similar behavior can be explored when exploring authenticode signatures. When signing the binary file, certificate chain can be included in the signature and these certificates will be used by CCE to construct the chain to validate the signature.

Although, this method is very useful, it is not always available in the applications. For example, when connecting to SSTP VPN, VPN server do not send intermediate certificates to client.

↑ Back to the top

Authority Information Access method

In the case when previous two method failed, CCE will use end certificate information to locate issuer certificate. Certificate issuer (CA server) may include its own certificate location in the Authority Information Access certificate extension. Let’s look at the Google SSL certificate’s Authority Information Access (AIA) extension. You should see the following entry:

[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://pki.google.com/GIAG2.crt

This URL is used by a certificate chaining engine to retrieve issuer certificate.

Authority Information Access certificate extension may store two kind of URLs distinguished by the Access Method. Certificate Authority Issuer method contains URLs to download issuer certificates. On-line Certificate Status Protocol method contains URLs to OCSP servers which are used to determine certificate’s revocation status.

Although, very effective, most CA vendors do not include Certificate Authority Issuer access method in the CA certificates below the root.

↑ Back to the top

Crypt32.dll and Microsoft Update

When you open Trusted Root CAs container on Windows XP/Windows Server 2003 you will see a lot of certificates. When you open this container on Windows Vista and newer operating system — only few common trusted root CA certificates are shown. However this doesn't mean that only displayed certificates are trusted. Trusted root CA list is approximately the same (comparing with Windows XP/Windows Server 2003), but rarely usable certificates are stored in the crypt32.dll file and on Microsoft Update web site.

To see how this works, open the Trusted Root CAs container on your Windows Vista or newer box. You should not see a certificate issued to/by: E-ME SSI (RCA). Now open a certificate from this URL: http://www.eme.lv/aia/E-ME%20SSI%20%28RCA%29.crt . You'll see that this root certificate is trusted. Now refresh local Trusted Root CAs container content and you will see this certificate in the list. There is no magic. If your computer is connected to the internet, certificate chaining engine will check Microsoft Update web site for this certificate. And if found (as in a given example) it is downloaded and installed to the certificate store. If your computer is not connected to the internet, CCE will extract certificate content from crypt32.dll library and install the certificate to the Trusted Root CAs container.

In other words, starting with Windows Vista, root CA certificates are typically installed on demand. For more details see the following KB article: Windows root certificate program members.

↑ Back to the top

Binding Certificates

Once chain certificates are retrieved by using one of the mentioned above method CCE binds (arranges) them to the corresponding position in the chain. CCE uses one of the several methods for certificate binding:

• Exact match
• Key match;
• Name match.

↑ Back to the top

Binding Certificates: Exact Match

In order to bind the issuer certificate with another certificate the following values must match:

• Key identifier;
• Issuer name;
• Certificate serial number.

For example, take a certificate from Intermediate CAs container with the Serial Number=17. This is the StartCom Extended Validation Server CA certificate. This certificate contains Authority Key Identifier (AKI) extension with the following content:

KeyID=4e 0b ef 1a a4 40 5b a5 17 69 87 30 ca 34 68 43 d0 41 ae f2
Certificate Issuer:
    Directory Address:
        CN=StartCom Certification Authority
        OU=Secure Digital Certificate Signing
        O=StartCom Ltd.
        C=IL
Certificate SerialNumber=01

Issuer certificate must match all these values in the Subject Key Identifier (SKI) extension, Subject and Serial Number fields respectively. In other words: KeyID value in the particular certificate AKI extension must match the value in the Subject Key Identifier (SKI) extension of the issuer certificate. Certificate Issuer value in the particular certificate must match the value in the Subject field of the issuer certificate. And Serial Number in the particular certificate must match the value in the Serial Number of the issuer certificate. If one of them doesn't match, certificate binding will fail and CCE will attempt to find another certificate that can be considered as a particular certificate issuer.

You can switch to the Certification Path tab and ensure that these values are identical. As the result CCE can safely bind issuer certificate to the particular certificate as issuer.

Exact match method can correctly bind certificates even if there are several CA certificates with the same Subject values (for example, expired and renewed CA certificate). If a CA certificate was renewed with a new key pair Subject Key Identifier in the CA certificate and Serial Number will be different since new public key is generated and resulting hash will be different. If CA certificate was renewed by using existing key pair only serial number is changed and CCE will be able to bind a correct certificate as a particular certificate issuer.

Although, Exact Match provides the most accurate certificate binding, it is not widely used (nowadays it is hard to find CA which uses full AKI information) because it is nearly impossible to perform CA cross-certification (to add additional certification paths) and these CAs cannot be members of Cross-CA bridge.

Conforming CAs (RFC5280 §4.1.2.2) must issue certificates with unique serial number during its operation lifetime. This means that serial number will be unique each time the certificate is renewed.

What is Subject Key Identifier or SKI? This is a hash (commonly MD5 or SHA1) that is calculated over subject's public key. The value of this extension in the CA certificate should appear in the Authority Key Identifier (AKI) extension of the issued certificates.

↑ Back to the top

Binding Certificates: Key match

Since exact match is not widely used, a key match is used instead. Again, you can examine SSL certificate at the https://letsencrypt.org web site (Fig.3).

Authority Key Identifier (AKI) extension in the leaf (web server) certificate contains the following information:

KeyID=a2 56 24 3c d0 d4 15 b9 e8 bf 78 a3 13 10 58 48 2e 16 54 e1

Subject Key Identifier in the the issuer's certificate contains the following information:

a2 56 24 3c d0 d4 15 b9 e8 bf 78 a3 13 10 58 48 2e 16 54 e1

In this match form, Authority Key Identifier value in the particular certificate must match the value in the Subject Key Identifier of the issuer certificate. You can ensure that in a given example they are identical. If they are identical, the certificates can be bounded as a part of the certificate chain, otherwise certificate binding will fail. This is the most common certificate binding method in internet PKI. Key match still offers strong binding accuracy, handles CA key renewals and can be used in cross-certification scenarios and can participate in Cross-CA bridges.

Key match method can correctly bind certificates even if there are several certificates with the same Subject values (for example, expired and renewed CA certificate). If CA certificate was renewed with new key pair Subject Key Identifier in the CA certificate will be different because new public key is generated. However Key match cannot track whether CA certificate was renewed by using existing key pair and can randomly bind two or more certificates as a potential certificate issuer. Since CA key pair remains the same both previous and renewed CA certificate can be used to validate current certificate signature and can be used for chain building. Modern best practices discourage administrators to reuse CA keys, it is recommended to generate new key pair each time CA certificate is renewed.

↑ Back to the top

Binding Certificates: Name match

Since X.509 Version 1 certificates does not contain extensions (as well as Authority Information Access, Authority Key Identifier, Subject Key Identifier and so on) there is only one way to bind certificates to the chain — Name Match. In this case Issuer field in the particular certificate must match Subject field of the issuer certificate.

↑ Back to the top

Signature validation

It looks that you can exploit V1 certificates and Name match for fraudulent certificates. For example, create a certificate with the Issuer field matching to any trusted issuer's Subject field. Mentioned binding methods are used only to bind certificates in the certificate chain. Certificate chaining engine checks each certificate signature against issuer's public key (is extracted from the Public Key field of the issuer certificate) later. If the signature is valid, certificate is valid too. Otherwise, the chain is complete, but considered as invalid. Figure 9 illustrates an example of this situation:

Although, CCE successfully bound my fraudulent certificate to the certificate chain, my certificate failed subsequent signature validation.

↑ Back to the top

And more...

Certificate chaining engine may apply additional restrictions and processing rules to the certificate chain. For example, each CA certificate must be proven to be CA certificate. It is achieved by setting and validating isCA=true entry in the Basic Constraints certificate extension.

such name, policy constraints and so on. Also, once certificate chain is built application may perform certificate revocation checking (unlike chain building, certificate revocation checking is an application choice). These are fully described in the RFC 5280 and are out of the scope of this article.

↑ Back to the top

Conclusion

As it was demonstrated, certificate chaining engine is one of the most important PKI fundamentals that is responsible for certificate chain building and certificate trust checking. In order to chain building succeed each certificate should be properly formed and follow at least basic requirements as discussed above. Also we have learned the purposes of the less-known certificate extensions, like Authority Information Access (AIA), Authority Key Identifier (AKI) and Subject Key Identifier (SKI) and extension-specific processing rules.

↑ Back to the top

Related links

• RFC 5280
• Certificate Revocation and Status Checking
• Certificate Revocation Checking in Windows Vista and Windows Server 2008
• Windows root certificate program members

↑ Back to the top

---