AIA Fetching: Solving a Common SSL Misconfiguration
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

AIA Fetching: Solving a Common SSL Misconfiguration

Resolving errors related to missing intermediate certificates

Before you can make a secure HTTPS connection to a website, your browser (or whatever your client may be) has to validate the website’s SSL certificate and make sure it is valid. In fact, your browser did this in just a few hundred milliseconds when you connected to this blog.

A key part of that process is checking the certificate’s signature and issuer to determine if it has been issued by a trusted Certificate Authority (CA), like Symantec or Comodo.

Webservers are supposed to serve clients the end-entity certificate for their website, along with all the Intermediate certificates needed to connect to the root – this is known as the certificate chain. This allows the client to easily trace the signature back to the root certificate in its root store and verify the certificate.

However, many webservers are not properly configured and do not provide the right certificate chain. Recent figures from Google say that ~10% of certificate errors in Chrome are related to incorrect or missing intermediate certificates.

Normally, this should be a bigger issue, given that a lot of servers have improperly configured certificate chains. But clients have a way to account for this common problem: AIA fetching.

AIA, or Authority Information Access, is an extension in SSL certificates that provides information about the issuer. One of the purposes of this extension is to provide a link to the issuing intermediate certificate.

aiafetchingHere is our SSL certificate showing the AIA field. There are two different entries in this certificate’s AIA extension, indicated by the [1] and [2] seen in the screenshot. The first entry is information about the issuer’s OCSP server. OCSP is a revocation mechanism, and is not related to AIA fetching.

The second entry is what we are interested in. The last line in the screenshot is a URL where the issuing intermediate can be downloaded. If a server does not provide the intermediate certificate, clients that perform AIA fetching will download the certificate from that URL.

Now that the client has the intermediate certificate, it can continue chain building and verify the certificate. While the server is technically misconfigured, a user who’s client supports AIA fetching will never know it.

Google Chrome on all platforms (except Android), Internet Explorer, and Safari all perform AIA fetching.

AIA fetching has been criticized for encouraging server misconfiguration. An inexperienced server admin could forget to serve intermediate certificates, and when they check the site it works fine because the intermediates are fetched. It may not even be apparent there is a problem.

On the other hand, without AIA fetching, clients report certificate errors and we harm the user’s experience and teach users that ignoring certificate errors is okay, all for the purpose of enforcing a principle.

Not all client software performs AIA fetching. In fact, the entire Android operating system does not do AIA fetching. Nor does Firefox.

There are other methods for solving the problem of missing intermediate certificates. Clients can cache intermediate certificates they encounter and use them for future connections. Or they can come pre-shipped with common intermediates. Some clients use a combination of these.

The underlying operating system can also handle some of these tasks. For instance, on Windows, if you visit a site with a missing intermediate in Chrome, the browser will perform AIA fetching and then Windows will cache the intermediate. If you then view the site in Firefox, it will pull the intermediate from Window’s cache and everything will work. But if you had done this in reverse order, Firefox would have presented an error because it would have no way to get the intermediate.