Authority Information Access: What the AIA Extension Must Actually Contain

What the AIA extension is

Authority Information Access is an X.509 v3 extension defined in RFC 5280. It answers one question on behalf of the certificate: where do I go to learn something about the authority that signed this? The extension holds a sequence of AccessDescriptions, and each AccessDescription is a pair — an access method saying what kind of thing is on the other end, and an access location saying where it is. It is never marked critical, so a client that does not understand it is free to ignore it and carry on.

The word people stumble over is authority. AIA is not about the certificate in front of you. Every URL in it points upward, at the issuer: the CA's certificate, the CA's revocation service. That is why a leaf certificate's AIA block is how a client climbs one rung of the chain, and why the same block is where it asks whether that leaf has been revoked.

The Baseline Requirements add one structural rule that RFC 5280 leaves open. When several AccessDescriptions share an access method, each location has to be unique, and they have to be listed in preference order, most-preferred first. Ordering between different access methods is unconstrained, so do not read anything into whether OCSP or CA Issuers appears first in an openssl dump.

The only two access methods allowed

A publicly trusted TLS certificate may use exactly two access methods, and nothing else. id-ad-caIssuers (OID 1.3.6.1.5.5.7.48.2) carries an HTTP URL where the issuing CA's certificate can be downloaded. id-ad-ocsp (OID 1.3.6.1.5.5.7.48.1) carries an HTTP URL for that CA's OCSP responder. Section 7.1.2.7.7 gives every other value a presence of MUST NOT, so anything else you find in there is a misissuance rather than a local convention.

Both locations have to be encoded as a uniformResourceIdentifier GeneralName, and both are HTTP rather than HTTPS. That trips people up during security reviews often enough to be worth stating plainly: fetching an intermediate over plain HTTP is not a weakness, because the object retrieved is a signed certificate that gets validated against the chain anyway. An HTTPS URL there would create a bootstrapping problem, since verifying it would need the very certificate you are trying to fetch.

What the Baseline Requirements require right now

As of version 2.3.0 of the TLS Baseline Requirements, dated September 7, 2026, a Subscriber Certificate MUST contain an authorityInformationAccess extension, and that extension MUST contain at least one AccessDescription. Within it, the CA Issuers URL is a SHOULD and the OCSP URL is a MAY. Those three presence levels are different from one another on purpose, and the difference is the whole story.

Read the table from the bottom up and the shape of the rule becomes clear. The Requirements are strict about what may not appear, firm about the container existing, and deliberately loose about what goes in it. A certificate containing an AIA extension with one OCSP URL and no CA Issuers URL satisfies every line above.

Ballot SC-104, and why nothing has changed yet

Ballot SC-104 proposes making the AIA extension itself optional for Subscriber Certificates. It is a two-line edit: in section 7.1.2.7.6 the presence of authorityInformationAccess moves from MUST to SHOULD, and in section 7.1.2.7.7 the sentence requiring at least one AccessDescription gains the prefix “If present,”. Nothing about the permitted access methods, the encoding, or the ordering rules changes.

The reasoning in the ballot is worth quoting in substance, because it is the same observation this article is built around. Since id-ad-caIssuers is only a SHOULD and id-ad-ocsp is only a MAY, relying parties cannot depend on any particular access method being present. If nobody can depend on the contents, mandating the container buys very little.

As of September 16, 2026 the ballot has cleared its vote, with results reported on September 3, 2026, and sits in the Forum's intellectual property review period. The redline itself lives in pull request #665 against the servercert repository, opened on May 6, 2026, and has not been merged. The practical test is the one you can run yourself: open the current Baseline Requirements and look at the presence column for authorityInformationAccess. In version 2.3.0, published four days after the vote, it still reads MUST.

So if you are writing a compliance check, a linter rule, or an internal policy this month, the rule to encode is still the old one. Certificates issued today are expected to carry the extension, and a CA omitting it today would be misissuing. When the redline does land, the effect will be permissive rather than prescriptive — it lets a CA leave the extension out, it does not ask any CA to change anything.

Why a mandatory extension never guaranteed a chain URL

Here is the part most coverage skips. The MUST in section 7.1.2.7.6 was never a promise that a client could find the intermediate. It only ever required the extension to exist and to hold at least one AccessDescription — and an OCSP URL satisfies that on its own. The CA Issuers URL, the one thing that actually helps a client repair a broken chain, has been a SHOULD the whole time.

In practice the public CAs do include it, which is why this rarely bites anyone and why the shorthand “AIA is required, so browsers can always find the intermediate” has survived so long. But a convention that every CA happens to follow is a different kind of thing from a requirement, and it is not something to design a system around. If your certificate validation logic assumes a CA Issuers URL is present, it is assuming something the Baseline Requirements have never said.

Client behaviour pulls in the same direction. Desktop Chrome and Edge will fetch a missing intermediate from the CA Issuers URL, and Safari does the same on macOS and iOS. Firefox does not do AIA chasing at all — Mozilla treats the extra round trip as a latency cost and a privacy leak, since it tells the CA which site you are visiting, and preloads intermediates disclosed to its root program instead. Chrome on Android does not do it either. We have taken that divergence apart in the guide to fixing a broken certificate chain, including the server-side fix for each platform.

What happens to revocation when AIA thins out

A thinner AIA extension does not leave a certificate with nowhere to check revocation, because a separate rule catches it. Section 7.1.2.11.2 makes the CRL Distribution Points extension mandatory in any Subscriber Certificate that both fails to qualify as short-lived and does not carry an AIA extension with an id-ad-ocsp access method. Remove the OCSP pointer and you have not removed revocation information — you have moved the obligation to crlDistributionPoints.

The short-lived carve-out is the exception, and its threshold has moved recently. For certificates issued on or after March 15, 2024 and before March 15, 2026, short-lived meant a validity period of 10 days or less. For certificates issued on or after March 15, 2026 it means 7 days or less. In that band, CRL Distribution Points is optional no matter what the AIA extension contains, on the reasoning that a certificate expiring inside a week is its own revocation mechanism.

The same section sets the boundaries elsewhere in the hierarchy: CRL Distribution Points MUST be present in Subordinate CA Certificates, SHOULD NOT be present in Root CA Certificates, and MUST NOT appear in OCSP Responder Certificates. When it is present it has to hold at least one DistributionPoint, and holding more than one is explicitly not recommended.

How to read the AIA extension yourself

The fastest check is openssl against a file. Run openssl x509 -in cert.pem -noout -text and look for the block headed “Authority Information Access”, which prints each URI on its own line, prefixed by the access method it belongs to. If you only want that extension, ask for it directly:

openssl x509 -in cert.pem -noout -ext authorityInfoAccess

To read it off a live server rather than a file, pull the certificate from the handshake first. The </dev/null keeps s_client from waiting on input:

openssl s_client -connect example.com:443 -servername example.com </dev/null \
  | openssl x509 -noout -ext authorityInfoAccess

On Windows, certutil -dump cert.cer prints the same extension with the access methods spelled out in full. All of these read the public certificate only, so none of them needs the private key — useful when the key is sitting in an HSM or a token and cannot be exported. If you would rather not run anything locally, the certificate inspection tools will show the same fields for a hostname you point them at.

One reading tip that saves confusion later. If the CA Issuers URL returns a file that openssl refuses to parse as PEM, it is almost certainly DER, which is the normal encoding for that endpoint. Convert it with openssl x509 -inform DER -in ca.cer -out ca.pem before feeding it to anything expecting text.

What this changes about your server config

Nothing, and that is the useful conclusion rather than an anticlimax. The correct configuration was already to send the full chain — leaf plus every intermediate up to but not including the root — from the server itself. That works on every client regardless of whether it does AIA chasing, regardless of whether the CA Issuers URL is present, and regardless of what SC-104 does to the presence column.

What the ballot does change is how much weight the AIA extension can carry in your mental model. If you have been treating “the browser will fetch it” as a safety net under a misconfigured server, that net was thinner than it looked before SC-104 and will be thinner still afterwards. Treat AIA as a convenience the issuer offers, not as infrastructure you are entitled to.

Practically, that means three habits. Test with a client that does not do AIA chasing, because a chain that satisfies Firefox and openssl s_client satisfies everything else. Keep the intermediate bundle your CA ships rather than reconstructing it from AIA downloads. And when you renew, check the chain again — reissues sometimes move to a new intermediate, and that is the moment a stale bundle starts failing. Every certificate we issue arrives with its intermediate bundle attached, so if you are choosing between SSL certificate options you are not left assembling one by hand.