Incomplete Certificate Chains: Browser Yes, App No

What the chain is and where it breaks

On its own, a TLS server certificate only states that some authority signed for a name. The claim becomes dependable through what sits above it: the server certificate was issued by an intermediate certificate, which in turn was issued by another intermediate or directly by a root certificate. Only the root certificate already sits in the client trust store, placed there by the operating system, the browser or the runtime, and it is therefore the one part of the chain the server does not have to deliver. How long the chain becomes depends on the hierarchy of the issuing authority: the default ECDSA chain of one widely used certificate authority comprises five links, of which only the first necessarily lives on your own server (Let’s Encrypt).

The standard spells out what to do in this situation. For the Certificate message, RFC 8446 states that the sender own certificate must come first in the list, that each following certificate should directly certify the one immediately preceding it, and that a certificate naming a trust anchor may be omitted because the peer is known to hold it anyway (IETF, RFC 8446). The whole of operational practice follows from that paragraph: leaf first, intermediates behind it, root optional. Leaving out the intermediates breaks no MUST requirement of the protocol. It shifts the sourcing onto the client and makes your own reachability depend on that client equipment.

• Leaf certificate: carries the domain name and the public key of the server; without this link no connection is established.
• Intermediate certificates: connect leaf and root, change regularly and are the part that goes missing in practice.
• Root certificate: sits in the client trust store and is explicitly not expected on the wire (IETF, RFC 8446).
• Cross-signatures: extra paths for older stores; dropping one saved over 40 percent of the certificate bytes sent in a TLS handshake (Let’s Encrypt).
• Trust store: the list of accepted roots, maintained by the operating system, the browser or the runtime.

The chain is therefore not an accessory to encryption but the part that carries the proof. Key agreement can be immaculate, the cipher suite current, the protocol version up to date: if a link is missing the connection still ends, and it ends for precisely those clients that cannot source a replacement. Why this check belongs on a fixed cadence rather than being run once is covered in the article on automated certificate oversight.

Why the browser forgives and the application does not

Browsers have adapted to servers delivering incomplete chains and compensate in two ways. The first is a supply: a browser vendor preloads the disclosed intermediates of the Web PKI into the client, and the publisher states the list holds over two thousand entries (Mozilla 2020). If a link is missing from the handshake it is filled in from that supply without anyone noticing. The publisher reports that the number of handshake failures caused by unknown issuers went down after the mechanism was introduced in Firefox 68 (Mozilla 2020). The second way is fetching over the address embedded in the certificate itself: the client retrieves the issuing intermediate from there and closes the gap on its own.

Other clients do neither. In the Java runtime, fetching over that address is disabled by default for compatibility reasons and has to be switched on through a system property (Oracle). Once it is switched on the next barrier applies: without a configured rule list, a deny-all ruleset is in force (Oracle). So the very connection that holds in the browser breaks in the ERP system, in the payment reconciliation or in the nightly import. The certificate authority itself names the faulty chain as the most common cause when modern platforms fail (Let’s Encrypt). On top of that, a trust store ages slowly: in July 2023 the publisher measured that 93.9 percent of Android devices trusted its root, up from 66 percent three years earlier (Let’s Encrypt).

What the protocol requires and what the rulebook leaves open

The protocol is deliberately lenient here. RFC 8446 advises all implementations to be prepared to handle extraneous certificates and arbitrary orderings from any TLS version; the only binding part is that the end-entity certificate comes first (IETF, RFC 8446). Lenient does not mean binding, though: a recommendation obliges no client, and a lean verification path in an embedded device or an old runtime may decline it. The same holds for the pointer to the issuing intermediate inside the certificate: the industry certificate profile lists it as a recommendation rather than a requirement (CA/Browser Forum). Planning the fetch as a safety net means planning around a field that is allowed to be absent.

Institutions of the German federal administration face an additional layer. The German BSI minimum standard for the use of Transport Layer Security requires them to deploy TLS 1.2 and/or TLS 1.3 (BSI); for federal states, municipalities, universities and private service providers without a corresponding directive it is guidance, not an obligation. The chain check is part of the diligence that requirement presumes. In practice that means the protocol version can be evidenced in a configuration line while chain completeness cannot. It only shows in the handshake itself. How protocol and algorithm selection can be observed separately is described in the article on hardening TLS cipher suites.

Five failure patterns and how to recognise them

An incomplete chain does not fail in one single way. In practice a small number of clearly distinguishable patterns occur, with different causes and different repairs. In the June 2025 monthly scan this applied to 1,256 sites (Qualys SSL Labs). Telling the patterns apart is worth the effort, because the first reflex of having a new certificate issued only helps with one of them.

The common picture is a server sending only the leaf certificate, because the configuration points at the file holding the single certificate rather than the file holding the full chain. Both sit in the same directory, both carry the same file suffix, and both produce the same green result in the browser. The second picture appears when the intermediate changes: the issuing authority now runs four of them in parallel, explicitly to prevent anyone pinning a single link (Web Almanac 2025). Anyone who hard-coded that link into their configuration delivers, after the switch, an intermediate that no longer matches the new leaf.

• Leaf certificate only: the configuration points at the single certificate instead of the full chain.
• Stale intermediate: a hard-coded link no longer matches the leaf after the issuing authority rotates.
• Wrong order: the leaf does not come first, which is the single point the protocol makes mandatory (IETF, RFC 8446).
• Extraneous certificates: expired cross-signatures stay in the file and inflate the handshake; dropping one cross-signature saved over 40 percent of the certificate bytes (Let’s Encrypt).
• Chain behind the load balancer: the application delivers in full while the layer in front terminates TLS with its own incomplete file.

The last pattern is the most awkward, because it passes the check on the origin server and still ships the fault. A site sits behind a load balancer, a cache or an upstream service; the visitor connection ends there, not at the application server. What belongs under test is therefore the address the visitor calls, measured from a network that is not your own. The same separation applies to API endpoints, which often run under a different hostname and therefore a different termination point.

Measuring the chain yourself

The proof costs one command. What matters is that it works without the aids of a browser: no preloaded supply, no fetching over the issuer address, only the system store and whatever the server actually sends. The usual command-line tool prints the delivered certificates one by one and names the verification failure in plain text.

Two readings are enough for a verdict. First, the number of delivered certificates: if exactly one comes back while the issuing authority works through an intermediate, the chain is incomplete. Second, the verification message: a note about a missing local issuer is exactly the finding a browser repairs in silence. Anyone without access to a command line reaches the same result with the SSL quick check.

The counter-test belongs with it. The same call against a site with a complete chain returns two or more certificates and no verification message. Once you have seen the difference, you recognise it in seconds. A clean result concerns the chain alone and says nothing about the rest of the configuration.

Causes that keep coming back

A handful of causes sit behind these failure patterns, and they repeat across industries and server systems. What they share is that they arise where nobody expects a certificate question: during a file change, during a migration, in a script that has been running unattended for years.

Short lifetimes turn a one-off into a cadence

The gap would be a one-off configuration error if certificates lasted a long time. That era is over. For certificates issued on or after 15 March 2026, the industry rulebook allows no more than 200 days of validity (CA/Browser Forum); from 15 March 2027 it is no more than 100 days (CA/Browser Forum) and from 15 March 2029 no more than 47 days (CA/Browser Forum). The calculation uses a day of exactly 86,400 seconds (CA/Browser Forum), so a renewal left to the last minute overruns the window. Platform vendors cap independently of that: server certificates issued on or after 1 September 2020 may be valid for no more than 398 days on the affected systems (Apple 2020).

That turns a one-off into a cadence. One certificate authority already offers certificates with six-day validity alongside the 90-day standard, and they cannot be operated without automation (Let’s Encrypt). Every renewal rewrites the chain, and every renewal is therefore an opportunity to lose a link. That chain changes also come with hard dates was shown when the long cross-signed chain was switched off on 6 June 2024 (Let’s Encrypt). What this means for monitoring cadence is set out in the articles on six-day certificates and on the 200-day limit.

The sender own certificate must come first in the list. Each following certificate should directly certify the one immediately preceding it.

— RFC 8446, section 4.4.2, paraphrased

Where the chain lives in the server configuration

In the server configuration the chain is a file reference, nothing more. Common web servers expect one file holding leaf and intermediates in that order; depending on the server software there are separate directives for leaf and chain as well. The most frequent fault is therefore not wrong syntax but a reference to the file that holds only the leaf.

After every change the same sequence applies: reload the configuration, test the handshake against the public address, count the certificates. Skipping the second step means relying on a file you have not seen delivered. With automated issuance the verification step belongs in the same workflow as the renewal itself; the article on certificate automation with ACME describes where that hook sensibly sits.

# fullchain.pem holds leaf AND intermediates - cert.pem holds only the leaf
ssl_certificate     /etc/letsencrypt/live/shop.example/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/shop.example/privkey.pem;

# Apache separates the directives; the chain belongs in SSLCertificateChainFile
# SSLCertificateFile      /etc/letsencrypt/live/shop.example/cert.pem
# SSLCertificateChainFile /etc/letsencrypt/live/shop.example/chain.pem

# Counter-check after the reload - at least 2 certificates are expected:
# openssl s_client -connect shop.example:443 -servername shop.example \
#   -showcerts </dev/null | grep -c "BEGIN CERTIFICATE"

Monitoring that sees the fault before the customer does

An incomplete chain is a state, not an event. It arises during a change and persists until someone notices – usually a customer whose application no longer connects. Monitoring that runs the handshake on a fixed cadence from an external network and evaluates the chain in full moves that moment forward.

• Record the number of delivered certificates per run, not just the status code of the page.
• Run the chain check without fetch assistance so the measurement does not repair what it is meant to measure (Oracle).
• Report remaining validity in stages, because the permitted lifetime drops to 200 days (CA/Browser Forum).
• Detect intermediate rotation, because the issuing authority runs four links in parallel (Web Almanac 2025).
• Test every termination point separately: origin server, load balancer, cache, secondary hostnames.
• Track revocation status over revocation lists, since the online responder was switched off on 6 August 2025 (Let’s Encrypt).

The effort is small because the request happens anyway. A run that measures reachability has already completed the handshake; the chain check is an evaluation step on the same result. In XICTRAQ this sits in uptime monitoring and in the security scan, with notification going out over the configured alert channels. Anyone who also wants to watch which certificates were issued for their names will find the route in the article on certificate transparency logs.

The chain belongs in continuous monitoring

The chain is the part of TLS that gets the least attention and breaks most quietly. Encryption is no longer a corner case: 98.8 percent of all mobile requests were sent over TLS in the 2025 survey year (Web Almanac 2025), and roughly 76 percent of the recorded pages speak TLS 1.3 (Web Almanac 2025). The broader the encryption, the broader the effect of a chain fault – and the more often it hits not the browser but the machine behind it.

On top of that comes a concentration that magnifies the lever: 52.6 percent of the recorded sites use a certificate from the same certificate authority (Web Almanac 2025). A rotation of its intermediates therefore touches a great many sites on the same day. The conclusion is unspectacular and carries far: chain completeness belongs in the same run as reachability and remaining validity, it belongs tested against the public address, and it belongs in a status report that somebody reads. How revocation checking is organised after the end of the online responder is covered in the article on certificate revocation over revocation lists.