How to Install an Intermediate SSL Certificate
VigilDog Team · October 30, 2026 · 7 min read
Your certificate authority sent you a leaf certificate and one or two intermediate certificates, and now the site loads fine in Chrome but curl throws a verification error. That gap is almost always a broken chain. Getting the intermediate certificate installed in the right order is the whole job, here's how to do it and prove it works.
Why the intermediate certificate matters
Public certificates are trusted through a chain. Your browser and operating system ship with a small set of trusted root certificates. Roots almost never sign your certificate directly, instead a root signs an intermediate certificate, and that intermediate signs the leaf certificate for your domain. A client validates the leaf, then walks up: leaf signed by intermediate, intermediate signed by root, root already trusted. If any link is missing, the chain can't be built and the connection fails.
The intermediate exists so the CA can keep its root offline and safe. That design is good for security but it means your server has to present the intermediate itself. The root is already on the client, so you never send it, but the intermediate lives only in the bundle your CA gave you, and it is your job to serve it alongside the leaf.
The classic symptom: works in a browser, fails everywhere else
A missing intermediate produces one of the most confusing failure patterns in TLS: the site works in your browser but breaks in API clients, mobile apps, payment webhooks, and monitoring tools. The reason is that many browsers quietly repair a broken chain by fetching the missing intermediate over the network using the AIA (Authority Information Access) extension in the leaf certificate. So the browser looks fine while everything without AIA-fetching, curl, most programming-language HTTP clients, Java, older Android, returns 'unable to get local issuer certificate'.
Never judge a chain by your browser alone. If any non-browser client complains about an untrusted or incomplete chain, assume the intermediate is missing before you suspect anything else. You can confirm it in seconds with our SSL checker, which reports every certificate the server actually presents.
Build the chain in the right order
The server sends certificates as an ordered list. Order is not optional: the leaf must come first, then each intermediate in sequence from the one that signed your leaf up toward the root. You omit the root. Most CAs give you the pieces as separate files, your domain certificate and a bundle (sometimes called 'ca-bundle' or 'chain').
To build a full chain file, concatenate the leaf first, then the intermediate(s):
- cat your_domain.crt intermediate.crt > fullchain.crt
- If the CA sent multiple intermediates, add them after the first: cat leaf.crt intermediate1.crt intermediate2.crt > fullchain.crt
- Do not append the root certificate, it adds bytes to every handshake and buys you nothing.
- Keep your private key in a separate file; it never goes in the chain.
Install it on nginx and Apache
On nginx, there is only one certificate directive and it must point at the full chain, leaf plus intermediates in one file. A common mistake is pointing ssl_certificate at just the leaf.
On Apache 2.4.8 and newer, SSLCertificateFile accepts the full chain in a single file, so you can use the same fullchain.crt. On older Apache you must split them: the leaf goes in SSLCertificateFile and the intermediates go in the now-deprecated SSLCertificateChainFile.
- nginx: ssl_certificate /etc/ssl/fullchain.crt; ssl_certificate_key /etc/ssl/private.key; then nginx -t && systemctl reload nginx
- Apache 2.4.8+: SSLCertificateFile /etc/ssl/fullchain.crt and SSLCertificateKeyFile /etc/ssl/private.key
- Apache <2.4.8: SSLCertificateFile leaf.crt + SSLCertificateChainFile intermediate.crt
- Reload, don't just restart the process, so existing connections drain cleanly.
Verify the chain before you trust it
Reloading without an error is not proof. Verify what the server actually presents from a machine that is not your browser. The definitive local check is openssl:
Run: openssl s_client -connect example.com:443 -servername example.com. Read two things. First, the certificate chain block at the top should list your leaf, then the intermediate(s), if you only see one certificate, the intermediate is still missing. Second, look for 'Verify return code: 0 (ok)' near the bottom; anything else means the chain didn't validate. The -servername flag matters on shared hosts because it sends SNI, so you test the right virtual host.
For a second opinion that mimics real-world clients, run the hostname through our SSL checker or an external lab. If a certificate was recently reissued and something still looks wrong, our guide on an expired or broken SSL certificate walks through the adjacent failure modes.
Keep it fixed after you fix it
Chains break again at the worst times, a CA rotates an intermediate, a renewal script writes the leaf but forgets the bundle, or a config change quietly drops the chain file. Because browsers paper over the problem, you often find out from an angry customer whose integration stopped trusting you, not from your own testing.
That is exactly the gap continuous monitoring closes. VigilDog monitoring watches the full certificate chain your server presents, not just the leaf's expiry date, and alerts you the moment the intermediate goes missing or the chain stops validating, so a silent reissue never turns into a silent outage.