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.

Some time ago one guy asked me for a script that will do the following:

1. Extracts all archived keys from CA database;
2. decrypts these keys (by using key recovery agent certificate)
3. saves decrypted keys in a PFX (PKCS#12) format;
4. creates simple log files: one with serial numbers that were decrypted successfully and another were decryption process was unsuccessful.

This scenario is common when an organization decided to move to a new PKI with new CA database. However it is highly recommended to move archived private keys from old to a new CA server. This is because even if new PKI is used, there might be a lot of encrypted stuff (encrypted files or outlook mails). And if user looses his/her encryption private keys he/she still should have an access to encrypted content. As the result you should move archived keys to a new CA for key recovery purposes only.

Update 28.05.2012: it appears that the same issue occurs with Remote Desktop Protocol too. Here is a fix for RDP: An RDP connection that uses SSL authentication and CredSSP protocol fails in Windows 7, in Windows Server 2008 R2, in Windows Vista and in Windows Server 2008

This is very interesting story of one customer (not my) and Thawte. It is common that you purchase SSL certificate from some of trusted commercial certification authority (CA) for public access. This reduces administrative effort on custom root CA (for example, your company own internal CA) installation on unmanaged computers (your company user's home computers). Or in partner organization. Also your company may not have own CA services and the only way to provide secure access to your web sites is to use certificates from commercial CAs.

Time by time this happens. Even highly trusted commercial certification authorities issue fraudulent certificates to malicious users. In 31 January 2001 (more than 10 years ago) VeriSign issued two fraudulent certificates to Microsoft on behalf of unknown men. This is very strange for a company who sell digital certificates starting with $100+ and cannot perform requestor identification as documented in their CPSs.

Ok this was ten years ago. But about 2 weeks ago Comodo CAs was compromised ( http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/ ). If VeriSign issued only two fraudulent certificates, Comodo — 9!!!!1111oneone. And to what names: login.live.com, login.yahoo.com, www.google.com, mail.google.com, login.skype.com and so on. All of them are SSL certificates. And not usual SSL certificates, but Extended Validation (EV) certificates!

Time by time I read questions about CDP and AIA extensions on Root CA and in Root CA certificate.

• CDP — CRL Distribution Point is an extension that contains links to the CRL of the issuer of the certificate which is being verified.
• AIA — Authority Information Access is an extension that contains links to the certificate of the issuer of the certificate which is being verified.

Check these articles for better understanding of certificate chaining engine:

• Certificate Chaining Engine — how it works
• Designing CRL Distribution Points and Authority Information Access locations

Let's see how these are used by certificate chaining engine (CCE). At first application must build a certificate chain. When CCE is processing a certificate it uses AIA extension to retrieve certificate issuer's certificate. Once it is retrieved, CCE set issuer's certificate as current and checks for *current* certificate issuer's certificate. This is normal and expected behavior for non-self-signed certificates. Once a certificate is presented in the self-signed form, there is no issuer. Certificate is issued to itself. As the result if AIA extension exist in the self-signed certificate it will point to itself and will cause loops. To address this issue, it is recommended to *NOT INCLUDE* AIA extension in the self-signed certificate (also referred to Root certificate).