Certificate Authority Information Access (AIA)

6 min readMay 29, 2021

Going down an unexpected rabbit hole of bad certificate chains.

This is a slightly edited re-post from the original one on Substack.

At my day job, my team runs a client facing proxy service that also performs TLS termination. This means that our proxy gets configured with a server certificate chain issued off a trusted Certificate Authority (CA) so that clients can verify that they are connecting to the intended destination. Usual TLS stuff.

However recently in one of our environments we had an issue with these certificates. For some reason macOS clients were able to properly connect and verify these “bad certificates” while Linux clients could not (I don’t actively use or have access to a Windows machine to comment on that).

While I was a little excited at first that I might have stumbled upon a security vulnerability which was soon squashed when I learned that this was due to a little known feature (at least to me and my peers) in the X.509 standard that defines various aspects of certificates.

For the rest of this blog I am going to use milkyway.com as a hypothetical domain hosted on the proxy server with bad certificates and Milkyway CA as a hypothetical certificate authority to describe the problem.

Why the certs were bad

Once I figured that the certificate verification was failing, the next step was to inspect the certificate chain file and see if there was something obviously wrong with it. One can inspect a PEM file with a bunch of certificates using a command like

openssl crl2pkcs7 -nocrl -certfile <path-to-chain> | openssl pkcs7 -text -print_certs

In the chain file in question, there were 2 certificates and I saw something like

Certificate 1:
        Issuer: C=XZ, ST=Milkyway, L=Earth, O=Adityas Org, OU=Some Unit, CN=Milkyway Intermediate CA 1/emailAddress=ca@milkyway.com
        ...
        Subject: C=XZ, ST=Milkyway, L=Earth, O=Adityas Org, OU=Some Unit, CN=www.milkyway.com/emailAddress=webmaster@milkyway.com...        Issuer: C=XZ, ST=Milkyway, L=Earth, O=Adityas Org, OU=Some Unit, CN=Milkyway Root CA 1/emailAddress=ca@milkyway.com
        ...
        Subject: C=XZ, ST=Milkyway, L=Earth, O=Adityas Org, OU=Some Unit, CN=Milkyway Intermediate CA 2/emailAddress=ca@milkyway.com

Usually the Issuer of the first certificate and the Subject of the next certificate in the chain should match. However in this case they did not.

The way the certificate chain verification works is that starting from the first certificate the client traverses up the chain, verifying the cryptographic signature at each point until you end up with a certificate that is issued and signed by a trusted certificate in the client’s trust store.

So clearly the certificate chain file was bad or malformed. Thankfully the intermediate certificate that had issued the server certificate was available and manually patching the certificate chain file to have the correct intermediate certificate fixed the problem and Linux clients could successfully connect and verify the server certificate just fine.

Why macOS trusted the bad certificates

So the bad certificate chain wasn’t the most interesting part of this problem. Things happen and we got a bad chain and the learning was that before we load the certificate into a server, some validations need to happen to make sure this doesn’t happen again.

However even with the bad certificate, macOS, both browser and the command line did not complain one bit about the bad certificate chain. After discussing this with some other folks who were more familiar with TLS and the certificate standard, I came across a field in the certificate extensions called Authority Information Access (AIA).

I’ve worked with certificates in the past, but I had never noticed this extension before. Turns out it makes a big difference. The standard for the AIA field is part of the X509 standard in RFC 5280. The AIA extension is supposed to point the client towards an endpoint from which the signing certificate can be obtained even if the server does not provide the intermediate certificates as part of the TLS handshake.

A quick internet search shows that macOS, Windows and Chrome on any platform will honor and attempt to query the AIA when an intermediate certificate is not found in the TLS handshake.

Proving this theory

I wanted to confirm that AIA was indeed the reason macOS was trusting the certificate with the bad chain. I didn’t have the bad setup in the original environment anymore since it was fixed and I couldn’t break it again to verify. So I created the following setup:

Using openssl commands create a root CA certificate, 2 intermediate CA certificates and a server certificate for www.milkyway.com signed by one of the intermediate certificates. The intermediate CA certificates all had an AIA setup to query ca.milkyway.com
Setup a local nginx server that hosted both ca.milkyway.com and www.milkyway.com — this would be the web server I would run requests against and also the web server that would host the CA certs.
The server certificate for www.milkyway.com was intentionally setup with the wrong intermediate certificate to recreate the original situation.
Add entries in /etc/hosts on my machine to point both the above domains to localhost.

The source code for the above setup can be found in this repository ,it doesn’t have a good readme yet but if folks are interested in reproducing this setup, I would be happy to add one.

So running a quick curl to the local website returns the following

akamath:~ akamath$ curl -v --resolve www.milkyway.com:443:127.0.0.1 https://www.milkyway.com/index.html
* Added www.milkyway.com:443:127.0.0.1 to DNS cache
* Hostname www.milkyway.com was found in DNS cache
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to www.milkyway.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=XZ; ST=Milkyway; L=Earth; O=Adityas Org; OU=Some Unit; CN=www.milkyway.com; emailAddress=webmaster@milkyway.com
*  start date: Mar 17 05:12:56 2021 GMT
*  expire date: Mar 17 05:12:56 2022 GMT
*  subjectAltName: host "www.milkyway.com" matched cert's "www.milkyway.com"
*  issuer: C=XZ; ST=Milkyway; L=Earth; O=Adityas Org; OU=Some Unit; CN=Milkyway Intermediate CA 1; emailAddress=ca@milkyway.com
*  SSL certificate verify ok.
> GET /index.html HTTP/1.1
> Host: www.milkyway.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.19.8
< Date: Wed, 17 Mar 2021 05:16:33 GMT
< Content-Type: text/html
< Content-Length: 85
< Last-Modified: Wed, 17 Mar 2021 05:12:30 GMT
< Connection: keep-alive
< ETag: "60518fbe-55"
< Accept-Ranges: bytes
<
<html>
	<head>
	</head>
	<body>
		<h1>Welcome to the Milky Way</h1>
	</body>
</html>
* Connection #0 to host www.milkyway.com left intact
* Closing connection 0

So the certificate was trusted and I got back a valid response (if not curl would complain about a certificate error after the TLS handshake). Now looking at the the nginx server logs

172.17.0.1 - - [17/Mar/2021:05:16:33 +0000] "GET /int_ca.crt HTTP/1.1" 200 1091 "-" "com.apple.trustd/2.0"
172.17.0.1 - - [17/Mar/2021:05:16:33 +0000] "GET /index.html HTTP/1.1" 200 85 "-" "curl/7.64.1"

And sure enough the AIA was used to access the intermediate certificate.

Thoughts on AIA

Most opinions I have read on the internet say that AIA is bad and encourages sloppy web server configuration. From the client’s perspective however it is allowing the client and the user to access a web server with a valid certificate but with a slight misconfiguration of the certificate without the correct chain. The user experience seems to be what macOS, Windows and Chrome are trying to target.

AIA by itself isn’t posing any risk to the security aspects of TLS, but there might be privacy implications with the hosting service of the intermediate certificates getting requests from the client which it otherwise would not have.

I personally feel that in a controlled environment, such as an internal enterprise network, if there is a use case for applications to establish many short lived TLS sessions, AIA and client side intermediate certificate caching might prove useful since it reduces some byte exchanges on the wire for each handshake.

References

I followed this tutorial on how to create your own CA and server certificates and the OpenSSL X509 docs on setting up AIA and other fields that were needed to make the certificates and scripts in the repository linked above.