Paste your SSL certificate and build the complete chain. Fetches missing intermediates via AIA, orders leaf to root, and exports a server-ready PEM bundle.
This certificate chain builder takes the certificate your CA issued you and works out the rest of the chain for you. Paste the PEM, or upload the .crt/.pem file, and the tool parses it in your browser, reads the Authority Information Access extension to find the issuing CA, downloads the missing intermediate, and repeats until it reaches a self-signed root. The finished chain is displayed leaf-first with subject, issuer, serial number, validity dates and CA status for every link, and can be copied or downloaded as a single server-ready certificate-chain.pem bundle.
It exists because “incomplete certificate chain” is one of the most common and most confusing TLS misconfigurations. The site works perfectly in your browser, then a partner’s Java service, an Android app, a curl script in CI, or a monitoring agent refuses to connect. Parsing and chain construction happen client-side with pkijs; only the fetch of a publicly published intermediate CA certificate goes through the site, and no private key is ever involved.
A TLS chain is a sequence of certificates in which each one is signed by the next:
CA:FALSE.CA:TRUE, its subject matches the previous certificate’s issuer, and its own issuer is the next certificate up. Two intermediates in a chain is now common; three is not unheard of.The ordering rule for a server bundle is strict and worth memorising: leaf first, then each intermediate in ascending order towards the root, and the root omitted. RFC 5246 required exactly this ordering; RFC 8446 (TLS 1.3) relaxed the wording so a receiver may reorder, but plenty of deployed software still parses strictly and simply stops at the first certificate whose issuer it cannot match. Sending the root wastes a kilobyte or so on every handshake and buys nothing — a client that does not already trust the root will not start trusting it because your server sent a copy.
-----BEGIN CERTIFICATE----- block is extracted and duplicates are dropped by serial number.This is the question that sends people to this tool, and the answer is caching plus fetching.
When a browser successfully validates a chain, it keeps the intermediate CA certificates it learned. Chrome, Firefox, Edge and Safari all do some version of this, and Firefox additionally pre-loads a large set of known intermediates. So the first time anyone on that browser profile visits a site served by the same CA, the intermediate gets cached — and every later site using that CA validates fine even if the server forgets to send it. Windows goes further: the CryptoAPI stack will fetch a missing issuer over HTTP from the AIA extension at validation time, so Internet Explorer, Edge and most .NET clients silently repair the chain themselves.
Now consider the clients that do none of that. OpenSSL’s default verification does not chase AIA. Java’s default SunJSSE path builder does not fetch intermediates unless AIA fetching is explicitly enabled. Go’s crypto/tls does not on Linux. Python requests, curl, Node.js, most mobile SDKs, load balancer health checks, payment gateways and monitoring probes all validate strictly against what the server actually sent. Android has historically been the classic casualty.
So an incomplete chain produces a maddening bug report: it works on the developer’s laptop and in every browser they try, and fails in CI, in the partner’s integration, and on a fraction of mobile devices. The failure is real and it is on your server — the browsers were simply covering for you. Because browser caching is per-profile, a colleague’s fresh machine may also fail while yours passes, which is why the definitive test is a clean, non-caching client.
Rebuilding the bundle is half the job; confirming it is the other half. Three checks worth running:
openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout prints every certificate’s subject and issuer in file order. Read it top to bottom: certificate 1’s issuer must equal certificate 2’s subject, and so on. Any break in that sequence is your problem.openssl verify -untrusted intermediates.pem leaf.pem should print OK. The error unable to get local issuer certificate means the path to a trusted root cannot be built — almost always a missing intermediate.openssl s_client -connect example.com:443 -servername example.com -showcerts lists exactly what the server transmits. Count the certificates and check the ordering. This catches the very common case where the correct bundle exists on disk but the web server config points at the wrong file, or at the leaf only. Our SSL checker performs the same inspection from a remote vantage point without a shell.Configuration differs by server. Apache’s SSLCertificateFile since 2.4.8 accepts the concatenated leaf-plus-intermediates file directly. Nginx has always required the concatenated bundle in ssl_certificate. IIS wants each intermediate imported into the Intermediate Certification Authorities store rather than concatenated. HAProxy takes leaf, key and intermediates in a single PEM. Get the file right and it is usually the server config, not the certificate, that still needs fixing.
It builds and orders the chain by matching distinguished names and following AIA pointers. It does not cryptographically verify each signature, and it does not validate against your operating system’s trust store, check revocation via CRL or OCSP, confirm hostname matching, or judge whether the certificate is still valid for your domain. Use it to construct and repair the bundle, then verify with openssl verify or a live handshake test. If you are still at the request stage, the certificate and CSR generator handles the other end of the lifecycle, and certificate transparency lookup shows every certificate publicly logged for a domain.
Leaf certificate first, then each intermediate working upwards towards the root, with the root left out. Each certificate’s issuer must be the subject of the one that follows it. TLS 1.3 permits receivers to reorder, but many clients still parse strictly, so always write the file in the correct order.
No. The root already lives in the client’s trust store, so sending it adds bytes to every handshake and provides no security benefit. A client that does not trust the root will not be persuaded by receiving a copy of it.
Almost certainly an incomplete chain. Browsers cache intermediates they have seen before and Windows fetches missing ones over AIA automatically, so they paper over the gap. OpenSSL, curl, Java and Go validate strictly against what the server actually sent, so they fail. Rebuild the bundle with the intermediates included.
Authority Information Access (OID 1.3.6.1.5.5.7.1.1) is an extension that publishes URLs relating to the issuing CA. The caIssuers entry points at a downloadable copy of the issuer’s certificate, which is exactly what this tool follows to build the chain automatically. The same extension usually also carries an OCSP responder URL.
Your certificate is parsed in your browser with pkijs and never sent for analysis. Only the fetch of the issuing CA’s publicly published intermediate certificate leaves your machine. A private key is never needed and must never be pasted into this or any other online tool — a public certificate contains no secrets, a key does.
It will name the missing issuer by CN and organisation. Either the certificate has no AIA URL, or the URL did not return a usable certificate. Follow the CA repository link the tool offers, download the intermediate that matches that name in PEM form, and paste it into the manual-add box; building then resumes automatically.
Yes. Every BEGIN/END CERTIFICATE block in the input is extracted, so you can paste an entire bundle in any order. Duplicates are removed by serial number, and the tool works out the correct sequence from the subject and issuer names rather than trusting the order you supplied.
No — input must be PEM (base64 text between BEGIN and END CERTIFICATE lines). Convert first: openssl x509 -inform DER -in cert.der -out cert.pem for DER, or openssl pkcs7 -print_certs -in bundle.p7b -out bundle.pem for PKCS#7.
Usually one or two. Let’s Encrypt leaf certificates chain through R10/R11 to ISRG Root X1. Cross-signed setups can add a link. If your builder finds more than three, check whether you are including a legacy cross-signed path that modern clients no longer need.
The encryption itself is unaffected — the negotiated session is exactly as strong either way. What breaks is authentication: strict clients cannot build a path to a trusted root, so they refuse the connection or throw a validation error. It is an availability and compatibility failure rather than a confidentiality one, but it still needs fixing.
When you obtain an SSL/TLS certificate from a Certificate Authority (CA), you receive more than just your server's certificate. You also need intermediate CA certificates that form a chain of trust.
Incomplete Chain: Missing intermediate certificates cause "certificate not trusted" errors, especially on mobile devices.
Wrong Order: Some servers require certificates in a specific order. The standard is end-entity first, followed by intermediates, with root last.
Modern certificates include an AIA extension that contains a URL to the issuer's certificate. This tool uses AIA to automatically fetch and build the complete chain.
Nginx
Apache
A certificate chain (or chain of trust) is a sequence of certificates that links your server's certificate to a trusted root Certificate Authority (CA). It typically includes your end-entity certificate, one or more intermediate CA certificates, and optionally the root CA certificate.
Browsers need to verify your certificate by tracing it back to a trusted root CA. If intermediate certificates are missing, browsers may show security warnings or refuse to connect. A complete chain ensures all clients can verify your certificate.
Most certificates contain an Authority Information Access (AIA) extension with a URL pointing to the issuer's certificate. This tool reads the AIA extension and automatically fetches the intermediate certificates to build the complete chain.
If the tool cannot fetch certificates automatically (due to network issues or missing AIA URLs), it shows you the issuer information and where to find the certificate. You can then manually download it from your CA's website and upload it.
The standard order is: your server certificate first, followed by intermediate CA certificates in order, with the root CA last (optional). This tool automatically orders the chain correctly.
Generally no. Browsers and operating systems have root CA certificates built in. Including the root can slightly increase handshake size but usually doesn't cause problems. This tool includes it if available.
The downloaded PEM file contains all certificates in the correct order. For Apache/Nginx, use it as your certificate file or chain file. For other servers, consult their documentation on certificate chain configuration.
This tool accepts certificates in PEM format (Base64-encoded, with -----BEGIN CERTIFICATE----- headers). Most CAs provide certificates in this format. If you have DER format, use our Certificate Format Converter first.