While most documentation I've read states that there is no requirement to have the AIA extension in a self-signed Root certificate (logical enough), I can't find anything that tells me not to do so in the certificates issued by the Root. In fact, most examples I've found has the Root CA issuing certificates with an AIA extension pointing back to the Root CA.

RFC 5280 gives two possible options for AIA:

  • the URL of the issuing CA's certificate.
  • the URL of the OCSP responder.

For now, I'm ignoring OCSP, and assuming we have at least one subordinate CA.

What would be the point of having a id-ad-caIssuers entry in the AIA extension within a certificate issued by the Root CA? If a subordinate needs to check this to find the path to the Root CA then it implies that the subordinate doesn't know about the Root CA's certificate and therefore doesn't have it in it's collection of Trust Anchors. A URL to the Root CA isn't going to change matters - it still won't trust it!

Am I correct or have I missed some point? If the latter, is there a situation where this AIA extension would be needed in a certificate issued by the Root CA?


Well, theoretically, you would never need to need the AIA.

RFC 5280 mandates, that you send along each necessary certificate. And optionally, you may send along the Root CA cert as well.

And that's the only certificate that is optional.

Now not everybody configures their servers correctly. And this is where AIA comes in.

If only the end entity certificate is sent along, then the client software will have more work to do. And some client software can do a thing called AIA chasing.

It will look inside the certificates it has and use AIA to download additional certificates. And if this doesn't lead to a usable path within 10 tries or something, then path building fails.

And building a path means: finding the certificates that lead to a trusted root CA.

If it leads to an untrusted root CA, then you can't trust the leaf certificate either. Either way, you will arrive at a decision about that leaf certificate. And that's what you want.

Related: InfoSec-SE: Steps to find out whether a SSL certificate is trustworthy

Edit 2015-04-28: AIA presents a root. You decide on trust.
What AIA chasing can help you with is to find one (or many) root CA. What it does not do is help you decide whether this CA is worth your trust.

But it will get you a root CA.

And even if it gets you a root CA that you don't trust, then it's still helpful, because then you know that the answer is "I'm not going to trust that". And then you don't have to keep on looking for an answer.

Further reading

  • Thanks for the answer. However, I'm happy with the way AIA is useful in building a long chain from the end-entity towards the Trusted Anchor. My question only queries the logic of adding AIA to the certificate issued by Root (assuming it's to another CA). When the client arrives at this penultimate CA during it's path building, it should find that it was signed by a Trusted Anchor. It should find the certificate of that Trusted Anchor installed on the device. If not, it isn't trusted. Having an AIA with an URL pointing to the Root certificate won't install it (I hope!!) or help at all. Apr 26 '15 at 17:47
  • Yep. It's a dead end. But then you know that it's a dead end. And you don't have to keep searching. Anyway it's only the fallback mechanism, in case you misconfigure your server to not deliver enough cert chain members. But here's another application I've seen in the wild: You buy a cert. It's mailed to you as a bundle: Root/Intermediate/Leaf. All fine. But if you do AIA, then you get a different chain: Different-Root/Cross-signed-Root/Intermediate/Leaf. So this means: A just-below-root type cert may not be just below the root in each chain. And there may be more than one chain. Apr 26 '15 at 17:52
  • I like the "know that it's a dead end." logic, which will cause that particular path to fail instead of continuing the search. - does it for me :-) Thank you. If you add it to your answer, I'll gladly accept it as the answer. Apr 26 '15 at 20:30

As you point out, an AIA is useful for OCSP.

For raw certificate validation, adding an URL pointing at the root self-signed certificate is indeed useless. A root self-signed certificate is usable only if you already have it, because its integrity and authenticity cannot be inferred from its signature. If you already have the certificate, then downloading it is not needed.

However, there are some cases where the URL is useful, e.g. as documentation. Basically, if a Windows user double-clicks on the end-entity certificate but did not install the self-signed root, then Windows will automatically download it, and display it with a red "X", which at least shows the exact problem. If there is no AIA URL pointing to it, Windows will stop at the intermediate CA.

On a similar vein, the URL may help a SSL client build a complete path. When a SSL server requests a certificate from the client, it sends the list of root CA names that it will use to validate the client certificate. The client needs not trust its own certificate (remember that your certificate is for other people, not for you) but the URL may help the client realize that its certificate really lives under one of the root CA that the server trusts.

The URL can support future evolutions. Right now, you have your root, but maybe at some point in the future you might make a deal with an existing, bigger root CA that will agree to issue an intermediate CA certificate to your root. At that point, certificates issued by your root should have a URL pointing at that new "intermediate CA" certificate, to help in path building (clients who trust your root won't need it, but it will help for clients that trust only the other, bigger root). Pushing a meaningful URL right now ensures that you keep that card in your game.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.