Guides · Fix a certificate error

SSL certificate chain order: fix an incomplete or wrongly ordered chain

Last reviewed by a person on October 4, 2026

The site opens fine in your browser, but curl, a Java or Python client, an API partner or a mobile app says unable to verify the first certificate, unable to get local issuer certificate or PKIX path building failed. The cause is often the certificate chain the server sends: it is missing a certificate, or the certificates are in the wrong order.

What a chain is

Your certificate is not signed by a root authority directly. It is signed by an intermediate, which is signed by a root that every device already trusts. The server has to hand over everything between your certificate and the root, so the client can follow the signatures:

1. example.com                  (your server certificate, issued by the intermediate)
2. Example Intermediate CA       (issued by the root)
3. Example Root CA               (optional: clients already have it)

The right order

• Your server certificate first.
• Then the certificate that issued it, then the one that issued that, and so on up the chain. Each certificate's issuer must be the subject of the next one.
• The root is optional. Clients already have it, so leaving it out is normal and sending it only makes the handshake a little bigger.
• Do not send certificates that are not part of the chain (for example an old intermediate left in the file).

Two or more intermediates: how to decide which goes first

Many certificate authorities use more than one intermediate, so a chain can have four certificates or more. You do not need to know the "right" order from memory. Follow the issuer: every certificate says who signed it, and the next one in the chain must be that signer.

1. Start with your server certificate. Note its issuer.
2. The certificate whose subject is that issuer comes next. Note its issuer.
3. Repeat until you reach a certificate that is its own issuer (subject and issuer are the same). That is the root: optional, and last.

For example, with these four certificates in a bundle:

subject: AAA Root                        issuer: AAA Root                         (its own issuer: the root)
subject: Example Intermediate 2          issuer: AAA Root
subject: Example Intermediate 1          issuer: Example Intermediate 2
subject: example.com                     issuer: Example Intermediate 1

start with example.com. Its issuer is Intermediate 1, so Intermediate 1 is second. Intermediate 1 was issued by Intermediate 2, so that is third. Intermediate 2 was issued by the root, so the root, if you include it, is last:

1. example.com
2. Example Intermediate 1
3. Example Intermediate 2
4. AAA Root   (optional)

To see the subject and issuer of every certificate in a file, run:

openssl crl2pkcs7 -nocrl -certfile bundle.crt | openssl pkcs7 -print_certs -noout

Or one certificate at a time: openssl x509 -in file.crt -noout -subject -issuer. A common cause of a wrong order is a CA bundle that lists the certificates root first (the reverse of what a server needs). Reversing the intermediates, or building the file by hand in the order above, fixes it. The certificate chain checker does this for you: when the order is wrong it lists the certificates in the order to send.

What goes wrong

• Incomplete chain (missing intermediate). The server sends only its own certificate. Browsers often repair this by remembering intermediates they saw elsewhere or fetching them, so you may not notice. curl, Java, Python, Go, Android apps and most API clients do not, and fail.
• Wrong order. The certificates are all there, but not in sequence (intermediate first, or root before the intermediate). Browsers usually sort them out. Some libraries and older OpenSSL versions reject the connection.
• The wrong intermediate. After a renewal the certificate authority may use a new intermediate. Keeping the old one in your file gives a chain that does not connect.

See what your server sends

Run this and look at the "Certificate chain" part of the output:

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

Each entry shows s: (subject, who the certificate is for) and i: (issuer, who signed it). The chain is right when entry 0 is your domain, and the i: of every entry equals the s: of the next one. Or use the certificate chain checker, which lists the chain, says what is wrong and shows the order to use.

How to fix it

1. Build one file with your certificate first, then the intermediate(s). Your certificate authority usually provides this as a "fullchain" or "bundle" download. Let's Encrypt and certbot write it as fullchain.pem. By hand, adding the intermediates in the order described above (each one issued the one before it):

   cat example.com.crt intermediate1.crt intermediate2.crt > fullchain.pem

2. Point the server at that file:
   • nginx: ssl_certificate /path/fullchain.pem; (not just the single certificate)
   • Apache 2.4.8+: SSLCertificateFile /path/fullchain.pem. Older versions: your certificate in SSLCertificateFile and the intermediates in SSLCertificateChainFile.
   • HAProxy: one .pem with the certificate, then the intermediates, then the private key.
   • Load balancers and CDNs: upload the certificate and the chain in their separate fields, in the same order.
3. Reload the server (nginx -s reload, systemctl reload apache2). Check every server or load balancer that answers for the name: one stale node is enough to fail some requests.
4. Test again with the command above or the checker, and from a client that was failing.

After every renewal

Chain problems often appear right after a renewal, when the new certificate was installed without the matching intermediate. CertAvert checks your certificates every day and warns you about expiry and trust problems. Sign up free to try it.