Wednesday, March 11, 2015

AIA-Enabled Certificate Chains

UPDATE: Cisco has written a very similar, more spelled out version of this blog entry, check it out!
http://blogs.cisco.com/security/where-is-my-intermediate-tls-certificate

Have you ever wondered why your nice publicly-signed certificate displays just fine on your workstation but your mobile device shows a certificate error?

First, in review, all of your browsers trust an authority such as Verisign, so they have the Verisign Root in their trusted store. In the case of www.cisco.com's certificate, its authority chain looks like so:



In order to fully trust the www.cisco.com certificate, your browser must not only trust its built-in root (Baltimore CyberTrust Root), but the Intermediate certificate in-between. Your server should be configured to send all certificates in the chain to every HTTPS client.

If not presented by the server, most desktop browsers use AIA to dynamically download the Intermediate certificate, using the www.cisco.com certificate's AIA field seen here:




If AIA works, no certificate error appears, because your desktop browser was able to complete the chain dynamically.

Mobile browsers, however, do not use the AIA extension. This is due to bandwidth/overhead of querying other websites to find the upstream Intermediate CAs. Desktops can handle this query process seamlessly, mobile browsers simply do not.

My recommendation is to send the full chain to everyone. This ensures no errors for mobile devices, and theoretically quicker load times because this AIA parsing does not need to be processed by any browsers. Inserting the Intermediate certificate in your webserver's CA configuration is the way to include this. Review your apache/IIS/other documentation on how to do this.

You can test your certificate chain with OpenSSL using the following command:
openssl s_client -showcerts -connect host.domain.tld:443

Everything is 100% right if you see the following at the bottom:
Verify return code: 0 (ok)