Certificates without AIA: which browsers stop fixing chains?

Chrome, Edge and Safari stop fixing your chain. If a certificate ships without the Authority Information Access (AIA) extension and your server leaves out the intermediate, those browsers have no URL to fetch the missing certificate from, and the connection fails. Firefox on desktop keeps working, because it never used AIA to repair chains in the first place.

That combination became allowed on 4 October 2026, when version 2.3.1 of the CA/Browser Forum Baseline Requirements took effect with ballot SC104. No CA has announced that it will drop AIA, so nothing breaks today. The impact is latent: it only lands once a CA actually changes its certificate profile, and only on servers that already send an incomplete chain.

What SC104 changed: the AIA extension is now optional

The redline is two lines in the subscriber certificate profile:

-| `authorityInformationAccess`      | MUST            | N            | See [Section 7.1.2.7.7](...) |
+| `authorityInformationAccess`      | SHOULD          | N            | See [Section 7.1.2.7.7](...) |

-The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. ...
+If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. ...

The two access methods inside the extension did not change. id-ad-caIssuers (the URL of the issuing CA certificate) was already SHOULD and id-ad-ocsp was already MAY. The ballot summary says it moves the extension from MUST to SHOULD, "aligning it with the permissible access methods": since both possible contents were optional, the wrapper became optional too. The ballot text gives no size or privacy motivation.

The practical difference is for CAs that no longer put OCSP URLs in their certificates. Before SC104, such a certificate still had to carry the AIA extension, which in practice meant carrying a caIssuers URL. Now it can carry neither. Both certificates below already have no OCSP URL and exactly one AIA entry. We captured this on 5 October 2026 with OpenSSL 3.6.3:

$ echo | openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org 2>/dev/null \
    | openssl x509 -noout -issuer -ext authorityInfoAccess
issuer=C=US, O=Let's Encrypt, CN=YE2
Authority Information Access: 
    CA Issuers - URI:http://ye2.i.lencr.org/

$ echo | openssl s_client -connect google.com:443 -servername google.com 2>/dev/null \
    | openssl x509 -noout -issuer -ext authorityInfoAccess
issuer=C=US, O=Google Trust Services, CN=WE2
Authority Information Access: 
    CA Issuers - URI:http://i.pki.goog/we2.crt

Let's Encrypt removed OCSP URLs in May 2025 (covered in our OCSP stapling post), and its newer ACME profiles already drop optional fields such as the Subject Key Identifier, in a profile it recommends to subscribers "who want smaller certificates". That is a pattern, not an announcement: nothing on Let's Encrypt's upcoming features page mentions AIA. For comparison, the DigiCert and Sectigo leaf certificates we checked the same day still carry both an OCSP and a caIssuers URL.

Which clients repair a missing intermediate, and how

The general mechanism, a browser quietly completing a chain your server sent incomplete, is covered in our post on whether your SSL monitor checks the certificate chain. What matters for SC104 is how each client repairs it, because only one of those mechanisms depends on the AIA extension.

Sources for each row, read on 5 October 2026:

• Chrome: the path builder in cert_verify_proc_builtin.cc adds an AIA issuer source unless network fetches are disabled. Windows and macOS intermediates come from trust_store_win.cc (the "CA" system stores) and trust_store_mac.cc (keychain certificates). On Android, Chromium's platform-verifier path (cert_verify_proc_android.cc) runs its own AIA fetch loop too, so either way Chrome on Android relies on AIA.
• Edge: Microsoft's Edge certificate verification docs: since Edge 112 the verifier ships with the browser on Windows and macOS, while Edge on iOS uses Apple's verifier.
• Apple: SecTrustSetNetworkFetchAllowed: "By default, network fetch of missing certificates is enabled if the trust evaluation includes the SSL policy."
• Firefox: Bugzilla 399324 ("Fetch missing intermediate certs (use AIA extension for incomplete cert chains)") was resolved WONTFIX in 2015. Intermediate CA Preloading shipped on desktop in Firefox 75, and the same page notes the root program requires CAs to disclose intermediates before using them.
• Android apps: Android's SSL guide lists a missing intermediate CA as a cause of SSLHandshakeException.
• OpenSSL: the verification options man page says the lookup searches the trust store, then "the list of untrusted ('intermediate' CA) certificates, if provided". curl's OpenSSL backend has no caIssuers handling of its own.
• Python: cpython #62817, "AIA chasing for missing intermediate certificates on TLS connections", has been open since 2013.
• Node.js: nodejs/node #58082 is an open feature request; the failure it quotes is Error: unable to verify the first certificate.
• Go: golang/go #31773 was declined in 2020.
• Java: the Java PKI Programmer's Guide: com.sun.security.enableAIAcaIssuers is disabled by default, and com.sun.security.allowedAIALocations is blank by default, "which enacts a deny-all ruleset".

Firefox for Android: what the source says

Mozilla's 2020 wiki page says preloading was "only enabled for desktop users". Current Firefox source no longer matches that note: security.remote_settings.intermediates.enabled defaults to true in the shared all.js, and GeckoView, the engine Firefox for Android runs on, calls RemoteSecuritySettings.init(), which creates the intermediate preloading client. We have not tested an Android device, so treat the Android row as what the code path implies, not a measured result.

Chrome on a cold machine versus a warm one

Chrome on Windows and macOS consults intermediates already sitting in the operating system's certificate stores before it gives up. For an AIA-less certificate with a missing intermediate, that turns a clean failure into an inconsistent one: a machine that happens to hold the intermediate connects, a freshly provisioned one gets NET::ERR_CERT_AUTHORITY_INVALID. If two people on the same team see different results in the same browser, check the chain before you check the browser.

"Works in Firefox, fails in Chrome" is the new symptom

The old folklore for a missing intermediate is "works in browsers, fails in curl". With an AIA-less certificate the split moves. Chrome, Edge and Safari now behave like curl for that certificate, because the one thing that let them recover is gone. Firefox desktop keeps connecting, because preloading never needed the extension.

That inversion will send people down the wrong path. "Firefox works, Chrome doesn't" usually reads as a Chrome-specific policy issue, such as a distrusted root or an enterprise policy. For an AIA-less certificate, the first thing to check is whether your server sends the intermediate at all.

For every non-browser client in the table, nothing changes. They never chased AIA, so an incomplete chain already fails for them today. This is the letsencrypt.org leaf verified on its own, the way a client without AIA sees it:

$ openssl verify -CAfile /opt/homebrew/etc/openssl@3/cert.pem leaf.pem
CN=letsencrypt.org
error 20 at 0 depth lookup: unable to get local issuer certificate
error leaf.pem: verification failed

AIA chasing was always a workaround

Our position: SC104 does not create a new problem. It removes a crutch that should never have been load-bearing. Sending the full chain was already best practice; for any CA that drops AIA, it becomes the only configuration that works in Chrome and Safari.

The repair path had limits long before this ballot:

• Chromium caps it in cert_issuer_source_aia.cc: kTimeoutMilliseconds = 10000, kMaxResponseBytes = 65536, kMaxFetchesPerCert = 5. A slow CA endpoint adds latency to the handshake; a dead one fails it.
• The fetch is plain HTTP, and it can be a walk rather than a single request. Following the caIssuers URLs from the letsencrypt.org leaf gave us ye2.i.lencr.org (YE2, 656 bytes, application/pkix-cert, Cache-Control: max-age=3600), whose own AIA points to ye.i.lencr.org (Root YE, cross-signed by ISRG Root X2), which points to x2.i.lencr.org. The server itself sends that whole four-certificate chain, so no client has to walk it.
• The URLs are not always up. Open servercert PR #650 cites "non-functioning URI included in certificates ranging from CRLDP to Repository URLs to caIssuers AIA" from recent incident reports.
• Library maintainers have refused it on purpose. In the Go discussion, Filippo Valsorda called AIA "arguably a misfeature of X.509" because it puts network requests and intermittent failures inside a process that should be deterministic. A Node.js maintainer reopened #58082 in July 2026 with "I don't think Node should implement AIA".

What this ballot doesn't change: if your server already sends the leaf plus every intermediate, an AIA-less certificate makes no difference to any client in the table. And if your CA never drops AIA, the browser repair path stays exactly as it was. The risk sits entirely with servers that send an incomplete chain and with CAs that later decide the extension is dead weight.

How to check your setup now

First, see what your current certificate carries:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -ext authorityInfoAccess

Use a current OpenSSL (we used 3.6.3). The LibreSSL build that ships as /usr/bin/openssl on macOS rejects -ext with unknown option -ext. If you see a caIssuers line today, browsers are still masking any chain problem for you. That can change at a routine renewal, with no action on your side, if your CA changes its profile.

Second, check what your server sends, without any repair:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -E '^ *[0-9] s:| i:|Verify return code'

For webpixie.io this printed four certificates (the leaf, YE1, Root YE, and ISRG Root X2 cross-signed by ISRG Root X1) and Verify return code: 0 (ok). If you see only certificate 0 and unable to get local issuer certificate, fix the server to serve the full chain file from your ACME client or CA bundle, not the leaf alone. Run it against every IP behind the hostname (-connect 203.0.113.10:443 -servername example.com), since a partial rollout can leave one node serving the leaf only.

Don't use a Firefox spot check as your test. It was always the one browser that couldn't tell you about AIA-dependent chains, and after SC104 it is the one most likely to say everything is fine when Chrome users can't connect.

For continuous coverage, WebPixie's SSL monitoring runs a daily handshake with a fully verifying client that validates the served chain against the trusted root CA store, from leaf to intermediate to root. A chain that fails that validation fails the check and opens an SSL Check incident.