When a browser connects to your site and validates your certificate, it is not just checking your certificate in isolation. It is walking a chain of trust from your certificate up to a certificate authority that the browser already knows about. Each link in the chain is a certificate signed by the one above it. The chain terminates at a root certificate that is pre-installed in the browser's or operating system's trust store.
The structure of a certificate chain
A typical certificate chain has three levels:
- Your end-entity certificate — the certificate issued for your domain. It is signed by an intermediate CA.
- The intermediate CA certificate — signed by the root CA. CAs use intermediates rather than signing end-entity certificates directly from the root, so that the root private key can be kept offline and protected. If an intermediate is compromised, it can be revoked without affecting the root.
- The root CA certificate — self-signed and pre-installed in trust stores. The browser trusts root certificates by virtue of their inclusion in the operating system or browser trust store, not because of a signature.
When your server sends its certificate during the TLS handshake, it should also send the intermediate certificate(s) — the full chain down to (but not including) the root. The root is already in the browser's trust store; it does not need to be sent.
What an incomplete chain causes
The most common chain problem is a missing intermediate — the server sends only the end-entity certificate without including the intermediate CA certificate. The browser receives the end-entity certificate and needs to find the intermediate to validate the chain, but it is not in the handshake.
Different clients handle this differently, which is why incomplete chain problems are notoriously inconsistent:
- Desktop browsers — Chrome, Firefox, and Safari all implement a mechanism called AIA fetching (Authority Information Access). If the intermediate is missing from the handshake, the browser will try to download it from a URL embedded in the end-entity certificate. This often works — which is why developers testing in desktop browsers may not notice an incomplete chain at all.
- Mobile operating systems — Android and iOS cache intermediates encountered in previous connections. An Android device that has never seen a particular intermediate may reject the connection; a device that has cached it from a previous visit will accept it. This produces the maddening situation where the connection works for most users but fails for some.
- API clients and server-to-server connections — most do not implement AIA fetching and do not have intermediate caches. Java's TLS stack, Python's requests library, and many other common clients will reject connections with incomplete chains outright. Server-to-server connections often fail while browser connections to the same endpoint succeed.
- IoT devices and embedded systems — typically have minimal TLS implementations with no AIA fetching and limited trust store management. These are most likely to fail on incomplete or unusual chains.
The expired intermediate problem
Intermediates have their own validity periods — typically several years. When an intermediate expires, every certificate signed by that intermediate becomes unvalidatable, even if the end-entity certificate itself is still within its validity period.
This is a particularly disruptive failure mode because it affects all certificates issued by the expired intermediate simultaneously. A CA that retires an intermediate will typically stop issuing new certificates from it well before expiry — but certificates already issued and still within their own validity periods continue to reference the expired intermediate. Those certificates need to be replaced with new ones issued from a current intermediate.
The Let's Encrypt ISRG Root X1 cross-signature expiry in September 2021 is the most well-known example of this class of problem. The DST Root CA X3 cross-signature expired, and clients that validated chains to that root (primarily older Android devices) began rejecting Let's Encrypt certificates. Newer clients that validated to ISRG Root X1 were unaffected. The result was selective failures across user populations — exactly the kind of intermittent, client-dependent failure that is hardest to diagnose.
Cross-signed certificates and trust store complexity
Modern PKI involves cross-signed certificates — where the same key is certified by multiple CAs, creating multiple valid chain paths to different roots. This is useful for compatibility: clients that trust root A can validate via one chain, clients that only trust root B can validate via another.
The complexity this introduces is significant. Monitoring a certificate's validity requires considering which chain paths exist, which trust stores are relevant for the client population that accesses the service, and whether all viable chain paths remain valid. A certificate that chains correctly to one root may be rejected by clients that rely on a different chain path.
CAA records and chain integrity
Certificate Authority Authorisation (CAA) DNS records allow domain owners to specify which CAs are permitted to issue certificates for their domain. This is relevant to chain integrity because it prevents unauthorised issuances — certificates from unexpected CAs that might have different chain structures than your standard configuration.
CAA records are a lightweight but effective control. If your CAA records specify that only Let's Encrypt and DigiCert may issue certificates for your domain, a certificate appearing in CT logs from a different CA is immediately identifiable as either a misconfiguration or an unauthorised issuance.
How CertControl monitors chain health
CertControl validates the full certificate chain for every monitored endpoint — checking that the chain is complete, that all certificates in the chain are within their validity periods, that the chain validates to a trusted root, and that the algorithms and key lengths used throughout the chain meet current standards.
Chain issues surface as findings with specific diagnostics: missing intermediate, expired intermediate, deprecated algorithm in chain, chain validation failure for specific trust store. The level of detail makes diagnosis faster — instead of "TLS error," the finding tells you exactly what is wrong and what needs to change.
The platform also tracks intermediate CA status — monitoring for intermediates that are approaching expiry or that have been revoked, so that the impact on all affected certificates can be assessed before the intermediate expires and the failures begin.