SSL Tools

SSL Chain Fixer

Build and verify SSL certificate chain bundles — 100% client-side

All certificate parsing is performed locally in your browser.

Input Method

Certificate(s) in PEM Format

What is an SSL Certificate Chain?

An SSL certificate chain (also called a chain of trust) is the sequence of certificates from your server's leaf certificate up through intermediate Certificate Authority (CA) certificates to the root CA. Web browsers need the complete chain to verify that your SSL certificate was issued by a trusted authority. When intermediate certificates are missing, browsers display security warnings like "NET::ERR_CERT_AUTHORITY_INVALID" even though your certificate itself is valid. This tool helps you build a correct chain bundle by analyzing issuer relationships between certificates, identifying missing intermediates, and assembling all certificates in the correct order. The resulting PEM bundle file can be used directly with web servers like Apache, Nginx, and HAProxy to eliminate chain-related SSL errors.

Why does my browser show a certificate error even though my SSL cert is valid?

The most common cause is an incomplete certificate chain. Your server must send not just the leaf certificate but also all intermediate CA certificates. Without them, the browser cannot trace the chain of trust back to a root CA it recognizes.

What order should certificates be in a chain bundle?

The leaf (server) certificate goes first, followed by intermediate certificates in order, with the root CA certificate last. Some servers do not require the root certificate since browsers already have it in their trust store.

Is it safe to analyze certificates in the browser?

Yes. This tool uses the node-forge library to perform all parsing entirely in your browser. No certificate data is transmitted to any server.

How do I get the intermediate certificates I need?

Your Certificate Authority usually provides the intermediate certificates along with your server certificate. You can also find them by checking the "Authority Information Access" extension in your certificate, which contains a URL to download the issuer certificate.

Expert guide · SSL Chain Fixer

What it does

The SSL Chain Fixer takes a pile of PEM certificates in any order, parses them with node-forge in your browser and rebuilds the path from the leaf to the issuing root by matching each certificate's issuer name to another certificate's subject. It labels every link as leaf, intermediate or root, flags expired or not-yet-valid certificates, lists certificates that do not belong to the path, and lets you paste a missing intermediate and download a correctly ordered fullchain.pem or the leaf alone. No certificate data is sent to our servers.

Why it matters

Works in Chrome, fails in apps: Desktop browsers often fill gaps by fetching or caching intermediates, so a broken chain hides until curl, a payment webhook or an Android app reports it.
API and webhook outages: Stripe-style callbacks, Python requests and Java HttpClient do not fetch missing intermediates and will refuse the connection outright.
CA hierarchy changes: When a CA rotates its intermediates, an old ca-bundle.crt copied years ago no longer matches the new leaf.
Wrong file order: Apache, Nginx and HAProxy send certificates in the order they appear in the file; a root-first or intermediate-first bundle can break strict clients.
Cleaner handshakes: Removing an unnecessary root or duplicate intermediate trims bytes from every TLS handshake.

How to read the results

Chain order list: Position 1 is the leaf (your server certificate); following entries are intermediates and, if you supplied it, the self-signed root at the end.
Subject and Issuer: Each certificate's Issuer should equal the Subject of the next one down the list; that name match is how the tool links certificates.
Status complete: The path reached a self-signed root, meaning every issuer relationship was found. For deployment, still drop the root from the file you install on the server.
Status incomplete or single certificate: At least one issuer is missing. Paste the intermediate named in the Issuer field of the last certificate into the add box to extend the chain.
Validity badges: Expired or not-yet-valid flags are evaluated against your computer clock for every link, not only the leaf; an expired intermediate breaks the chain too.
Certificates not in chain: Extra certificates you pasted that do not sit on the leaf's path, such as an old intermediate or an unrelated root, which should be removed from the bundle.

Technical background

A TLS client trusts a server certificate only if it can build a path (RFC 5280, section 6) from that leaf through one or more intermediate CA certificates to a root that already sits in its trust store. Roots are deliberately kept offline, so leaves are signed by intermediates, and the server is responsible for sending those intermediates during the handshake. TLS 1.3 (RFC 8446, section 4.4.2) requires the end-entity certificate first and says each following certificate should certify the one before it; TLS 1.2 (RFC 5246) states the order as strictly required. The correct bundle is therefore leaf, then the intermediate that signed it, then any higher intermediate. The root should be left out: the client must already have it, and sending it only wastes bytes.

When the server omits an intermediate, behavior diverges. Windows CryptoAPI, macOS and Chrome on several platforms can follow the Authority Information Access extension (RFC 5280, section 4.2.2.1), whose CA Issuers URL points to a downloadable copy of the issuer certificate, and Firefox ships a preloaded set of known intermediates. OpenSSL-based clients such as curl, wget, Python, PHP and Go do not perform AIA fetching, and neither do Android apps using the platform validator. The result is the classic incomplete chain: curl reports error 60 unable to get local issuer certificate, OpenSSL verify prints error 20, and Android throws Trust anchor for certification path not found, while the site looks fine in a desktop browser.

This tool reconstructs the path offline in your browser. It identifies the leaf as the non-self-signed certificate that issued nothing else, then repeatedly looks for a certificate whose subject distinguished name equals the current issuer. It links certificates by name only and does not verify signatures or check revocation, so treat the result as an ordering and completeness aid, then confirm with openssl verify. To find a missing intermediate, read the CA Issuers URL from your leaf's AIA extension, download it (often DER, so convert to PEM), and paste it into the add box.

Chain hygiene matters more as lifetimes shrink. CA/B Forum ballot SC-081 approved maximum validity of 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029, and CAs rotate issuing intermediates frequently. Use the fullchain file your ACME client produces rather than a hand-maintained bundle, and recheck the chain whenever your CA announces a hierarchy change.

Common errors and how to fix them

Problem Site works in Chrome but curl fails with unable to get local issuer certificate.: Fix The server sends only the leaf. Point ssl_certificate (Nginx) or SSLCertificateFile (Apache 2.4.8+) at a file containing leaf then intermediates, reload, and retest with openssl s_client -showcerts.
Problem Android app throws Trust anchor for certification path not found.: Fix Android's validator does not download missing intermediates. Serve the complete chain from the server; do not try to fix it by bundling the intermediate into the app.
Problem Bundle has the intermediate before the leaf.: Fix Reorder so the server certificate comes first. Download fullchain.pem from this tool, which writes the leaf first followed by its issuers.
Problem Root certificate included in the served chain.: Fix Remove the self-signed root from the end of the file. Clients ignore it at best, and at worst a cross-signed or outdated root can steer older clients onto an expired path.
Problem Chain shows an intermediate that is not on the path.: Fix An outdated ca-bundle from a previous certificate is mixed in. Delete the entries listed under certificates not in chain and fetch the current intermediate named in the leaf's Issuer field.
Problem Chain still incomplete after adding the intermediate from the CA website.: Fix The CA offers several intermediates (RSA and ECDSA, or different generations). Match the Issuer of your leaf exactly, or download the one referenced by the leaf's AIA CA Issuers URL.

Do it from the command line

macOS

# See exactly which certificates the server sends
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
# Verify a leaf against a candidate intermediate bundle
openssl verify -untrusted intermediates.pem leaf.pem

Windows

# Build the chain using AIA fetching and show each URL retrieved
certutil -verify -urlfetch leaf.cer
# Test what a non-browser client sees
curl.exe -sv https://example.com -o NUL

Linux

# Read the CA Issuers URL from the AIA extension
openssl x509 -in leaf.pem -noout -ext authorityInfoAccess
# Download that issuer (usually DER) and convert to PEM
curl -s http://ca.example/issuer.cer | openssl x509 -inform der -out intermediate.pem
# Assemble leaf + intermediate (no root) for Nginx
cat leaf.pem intermediate.pem > fullchain.pem