Certificate Chain Builder

An incomplete chain is the most common SSL misconfiguration there is, and the hardest to notice — your own browser hides it. Name a live domain or paste the certificate, and this assembles the bundle your server should serve.

What this tool does

Takes the certificate your CA issued and works out the full chain your server should be presenting. Where an intermediate is missing it follows the Authority Information Access extension to fetch it from the CA, verifies that each certificate really was signed by the one above it, and hands back a bundle you can paste straight into your server configuration.

Why an incomplete chain is so easy to miss

A server is supposed to send its own certificate and every intermediate above it, stopping short of the root. When an intermediate is missing, most desktop browsers repair the chain silently: they either cached that intermediate while visiting another site, or they quietly fetch it over AIA themselves. Your browser says the padlock is fine.

Almost nothing else does. Java clients, Python's requests, Go's HTTP client, curl on a fresh container, older Android, payment gateways and webhook senders will all reject the connection outright. The classic symptom is a site that works perfectly in a browser while an API integration fails with an unhelpful verification error.

How to use it

Fetch from a domain is the quickest route when the server is already live: name it — example.com, or example.com:8443 for another port — and this server opens a TLS connection, keeps whatever certificates the endpoint presents, and downloads only the links it left out. It works on an endpoint that is currently failing, which is usually the reason you are here.

Paste a certificate covers the case where there is no server to point at yet — a certificate that has just been issued, or a file from the CA. If you already have some of the chain, paste the whole bundle: order does not matter, and any certificate you supply is preferred over one downloaded from the CA.

Either way the result lists each link with where it came from, and the bundle below is ready to install.

Reading the result

Complete — the walk reached a certificate a public trust store already vouches for. That is what you want, and it is where the walk stops: everything above that point is the client's to supply, so roots are deliberately left out of the bundle rather than wasting handshake bytes.
Incomplete — the walk never reached a trusted root. Either a certificate carries no AIA extension, the CA's endpoint could not be reached, or the chain tops out at a private root that no public store carries — which no bundle can fix. The notes say which.
Source — whether each link was supplied (served by the endpoint, or pasted by you) or downloaded from the CA. A chain where everything above the leaf had to be downloaded is precisely the chain your server is not sending.

Installing the bundle

nginx expects the leaf and intermediates concatenated into one file, in that order — which is what the bundle below is:

ssl_certificate /etc/ssl/fullchain.pem;

Apache since 2.4.8 takes the same file in SSLCertificateFile. HAProxy wants it together with the key. IIS and Tomcat want the intermediates imported separately into their own stores rather than concatenated — see the install guides.

Common problems

No AIA extension. Some private and older CAs omit it. Nothing can be followed automatically; ask your CA for the intermediate bundle directly.
The CA served a .p7c file. A PKCS#7 bundle is not handled here. Convert it first with openssl pkcs7 -inform DER -print_certs -in ca.p7c and paste the result.
It says complete, but the server still fails. You built the right bundle but have not installed it, or the service was not reloaded. Confirm what is actually on the wire with the SSL checker — it reads the live handshake, not the file.
An intermediate expired. Intermediates expire too, and a chain can break without the leaf changing at all. Each link shows its expiry date.

What is sent where

In domain mode this server makes an outbound TLS connection to the host you name; in paste mode the certificate is posted here. Either way it may then fetch intermediates from the CA URLs named inside the certificate. Certificates are public documents — this one is already being handed to every visitor of the site it belongs to — and nothing is stored. No private key is involved at any point.