Fix “certificate chain incomplete” and “unable to get local issuer certificate” errors

The site shows a padlock in Chrome on your laptop. Then it fails on an Android phone, the uptime monitor reports the certificate chain as incomplete, a Java client dies with PKIX path building failed, and curl on a fresh server says unable to get local issuer certificate. Same certificate, five verdicts. Almost always the cause is one thing: the server is not sending every certificate a client needs to walk from your certificate to a root it already trusts. This guide shows how to confirm that with one openssl command, tell which of four causes you have, build a correct fullchain.pem, install it on nginx, Apache, HAProxy, IIS or Java, and prove the fix from outside.

Why desktop browsers hide the problem

A public certificate is never trusted alone. Your leaf (the certificate for www.example.com) is signed by an intermediate CA certificate, which is signed by a root that is self-signed and shipped inside the operating system or browser. The client holds only the root; RFC 8446§4.4.2 makes the server supply the rest: the sender’s certificate comes first, each following certificate should directly certify the one before it, and the trust anchor may be omitted. A correct server therefore sends leaf, then intermediate(s), root omitted— two certificates under Let’s Encrypt, three under CAs with two intermediate tiers.

A missing intermediate goes unnoticed because of a leaf extension called Authority Information Access (OID 1.3.6.1.5.5.7.1.1), whose CA Issuersfield is an HTTP URL for the intermediate. Chrome, Edge and Safari on desktop perform “AIA fetching”: handed a lone leaf, they download the intermediate, verify and cache it. Browsers also keep intermediates seen on other sites, so a Chrome that visited any Let’s Encrypt site last week already holds that CA’s intermediate. Firefox does not fetch but preloads the public intermediates, with the same effect. The clients that fail do none of this:

• Android’s platform verifier, used by every app on HttpsURLConnection, OkHttp or WebView — the error is Trust anchor for certification path not found.
• OpenSSL and everything built on it: curl, wget, PHP, Ruby, Python’s ssl module.
• Java, unless com.sun.security.enableAIAcaIssuers=true is set — the default is false.
• Go, Node.js, .NET on Linux, and practically every monitoring probe and embedded device.

“Works in Chrome” proves nothing about the chain; the clients that complain are the honest ones.

The error messages, and what each one is telling you

Four causes sit behind those wordings. Missing intermediate: the leaf is sent alone. Wrong order: the intermediate precedes the leaf — OpenSSL and modern browsers search the whole set, but older Android releases and many embedded stacks take the list literally. Untrusted root: the chain is complete but ends at a private CA, or at a root the client’s store predates. Expired intermediate or root: the leaf was renewed but the chain file beside it was not.

Diagnose it: read the depth lines from openssl s_client

Run this from anything that is not your desktop browser. -servernamematters: without it the server may hand you the default virtual host’s chain rather than the one for your hostname.

openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null

# healthy — verification climbs from your leaf (depth=0) to a trusted root (depth=2):
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R10
verify return:1
depth=0 CN = www.example.com
verify return:1
---
Certificate chain
 0 s:CN = www.example.com
   i:C = US, O = Let's Encrypt, CN = R10
 1 s:C = US, O = Let's Encrypt, CN = R10
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
...
Verify return code: 0 (ok)

# missing intermediate — it never gets past depth=0, and only one certificate is listed:
depth=0 CN = www.example.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = www.example.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = www.example.com
   i:C = US, O = Let's Encrypt, CN = R10
...
Verify return code: 21 (unable to verify the first certificate)

Read it in three places. The Certificate chain block lists what the server actually sent, numbered from 0; s: is a subject and i: its issuer, so a good chain reads like a ladder in which every i: equals the next s:. The depth= lines show how far verification climbed: an error at depth=0 means the leaf’s issuer was not found (missing intermediate); num=20 at depth=1 means the intermediate arrived but its issuer is not in the local store (untrusted or dropped root); num=19 means an untrusted self-signed root was sent; num=10 names the certificate that has expired. The last line must read Verify return code: 0 (ok), and entry 0 must be your hostname, or the order is wrong.

To inspect the served certificates, save them and drop the file on the SSL certificate checker:

openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null \
  | sed -n '/BEGIN CERT/,/END CERT/p' > served-chain.pem

The checker takes that PEM (or any .crt/.der/.p7b/.pfx file) and reports the chain as supplied: a verdict such as Chain of 2 certificates links and verifies correctly. or Chain is broken — a signature or issuer link does not match., one line per link (is signed by; does not name as issuer for wrong order; is NOT validly signed bywhen the names match but the signature fails), and a card per certificate with role, days remaining, covered hostnames, algorithms and fingerprint. Two limits: it cannot connect to a live domain — a web page may not inspect another server’s handshake, hence the s_client capture — and a lone leaf is reported as a valid single certificate, because there is no link to test. One certificate in served-chain.pem where you expected two is itself the diagnosis.

The 2021 Let’s Encrypt root expiry: a valid chain that old clients rejected

The best-known chain incident involved no missing file. Let’s Encrypt originally chained to DST Root CA X3, an IdenTrust root every trust store already held, while its own ISRG Root X1spread through OS updates. DST Root CA X3 expired on 30 September 2021. To keep old Android phones working, Let’s Encrypt had ISRG Root X1 cross-signed by DST Root CA X3 with validity to 30 September 2024 — three years past the signer’s own expiry, which X.509 allows because each certificate’s dates are checked independently. The default chain became leaf → R3 → ISRG Root X1 (cross-signed by DST Root CA X3).

Clients split three ways. Those holding ISRG Root X1 stopped at R3’s issuer and ignored the cross-sign. Android before 7.1.1 lacked ISRG Root X1 but does not check a trust anchor’s expiry, so it accepted the path through the dead root. OpenSSL 1.0.2 and older built the longest path it could, hit the expired DST Root CA X3 in its own bundle and failed with certificate has expired; the client-side fix was deleting that root from the bundle or passing -trusted_first. Anything with no ISRG Root X1 at all (macOS before 10.12.1, iOS before 10, Java before 8u141) saw an unknown issuer. Server-side, certbot --preferred-chain "ISRG Root X1" requested the short chain, trading old-Android for old-OpenSSL support. The cross-sign expired on 30 September 2024, so a chain file still carrying the DST-signed certificate is now the expired root row above. The expired certificate guide covers the leaf-side story.

Build the fix: a correct fullchain.pem

You need the leaf and the intermediate(s) that issued it. Certbot writes cert.pem, chain.pem and, already concatenated, fullchain.pem under /etc/letsencrypt/live/<domain>/; commercial CAs attach an intermediate or a .ca-bundle to the issuance email. With nothing but the leaf, fetch it from the CA Issuers URL that openssl x509 -in cert.pem -noout -ext authorityInfoAccess prints (curl -o intermediate.der http://r10.i.lencr.org/for a current Let’s Encrypt RSA certificate — the download is DER, not PEM). Then concatenate:

cat cert.pem intermediate.pem > fullchain.pem
# leaf first, then each intermediate, root omitted; every block starting on its own line
grep -c 'BEGIN CERTIFICATE' fullchain.pem     # expect 2 (3 for a two-tier CA)
openssl verify -untrusted intermediate.pem cert.pem   # cert.pem: OK

If the CA sent a pile of certificates in no obvious order, paste them all into the SSL chain builderor drop the files on it — PEM or binary DER, so the AIA download works as-is. It finds the leaf (the one certificate that issued nothing else in the set), follows each issuer name to the next certificate and verifies every link’s signature against the next public key, labelling the result Leaf → Intermediate → Root. A name that matches but a signature that fails is flagged signature mismatch!, and certificates that do not belong are listed under Not part of this chain (left out). The download is fullchain.pem with the self-signed root removed; chain-with-root.pem is offered only when a root was present. Expired certificates trigger a warning, not a refusal, and nothing leaves the page — no private key is involved anyway. What the builder cannot do is invent a missing intermediate: feed it only the leaf and there is nothing to link.

Where each server expects the chain

For the Windows and Java rows the chain must travel inside the PKCS#12 file. The PEM to PFX tool takes the whole fullchain.pem in its certificate box, the private key in the second and a password for the archive, and packs certificate, intermediates and key into certificate.pfx or .p12. Before packing it checks that the key’s public half matches the first certificate; a mismatch stops with The private key does not match the first certificate — make sure the leaf (domain) certificate comes first and the key belongs to it., which also catches a chain pasted intermediate-first. RSA and P-256/P-384/P-521 keys are accepted, and the success line counts what went in: certificate.pfx created with 2 certificates + private key. — if it says 1, the PFX will reproduce the missing intermediate on IIS. The PFX guide and Java keystore guide take it from there.

Common mistakes

• Including the root. It adds about a kilobyte per handshake, and once that root expires while your file still carries it, OpenSSL clients return code 10 or 19.
• Renewing the leaf but keeping last year’s intermediate.Let’s Encrypt moved from R3 to R10/R11 in 2024, and R3 expired in September 2025. Copying only cert.pem into a static chain file leaves a leaf signed by R10 on top of R3; the checker says does not name as issuer and every non-fetching client fails.
• Mixing RSA and ECDSA chains. nginx and Apache serve both from two ssl_certificatelines; each needs its own intermediates. Let’s Encrypt’s ECDSA leaves chain through E5/E6 to ISRG Root X2, not through R10/R11.
• Key in the chain file, or chain in the key file. nginx refuses to start with key values mismatch or PEM_read_bio_X509_AUX() failed. Keep one PRIVATE KEY block in privkey.pem, only CERTIFICATE blocks in fullchain.pem, and run the pair through the certificate ↔ key matcher before reloading: it derives the public key from each and answers Everything matches or names the pair that disagrees.
• Fixing the wrong virtual host. Certificates are chosen by SNI; if s_client without -servername shows a different chain from the run with it, the default server block has its own, older files.
• Fixing the wrong machine.When a CDN, load balancer or proxy terminates TLS, the world sees the chain uploaded there; if certificate 0’s issuer names the CDN’s CA, the fix lives in that dashboard.
• Editing without reloading. nginx, Apache and HAProxy read certificates at start-up and on reload, never per connection: nginx -t, then systemctl reload nginx.

Verify from outside, and why caches can lie to you

After the reload, re-run s_client and confirm three things: Certificate chain lists two (or three) entries, entry 0 is your hostname, and the last line is Verify return code: 0 (ok). Then curl -v https://www.example.com/ -o /dev/null, which prints SSL certificate verify ok.when the chain is good. Do it from a network that never saw the broken setup — mobile data, a CI runner, a colleague’s machine. If Java complained, keytool -printcert -sslserver www.example.com:443 shows exactly what Java receives.

Do not trust a desktop browser for the after-check: Chrome and Safari cached the intermediate when they fetched it and show a padlock either way. Two more caches mislead: a tab opened before the reload may reuse its TLS connection for minutes, and a client resuming a TLS session is not sent the chain again, so its old verdict stands until the ticket expires. Fresh connections from openssl and curl avoid both. Finally, run the new served-chain.pem through the checkerand note the intermediate’s expiry beside the leaf’s — the next break will come from a rotation, not a typo.