Certificate Chain Checker

Server assisted New Website & HTTP Diagnostics

Reads the chain a server presents in its TLS handshake (the Mutqan server connects from Cloudflare's network) or a PEM bundle you paste, follows it from the leaf by issuer name and key identifier, and verifies with WebCrypto that each certificate's signature checks out under the key of the certificate after it. It reports a missing intermediate, a wrong order, extra or expired certificates and CA constraints; no root store is consulted, so it describes the chain rather than declaring it trusted.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

Why does a server have to send intermediate certificates?

Clients hold only root certificates, while a site certificate is signed by an intermediate CA, so the server must send its own certificate followed by every intermediate up to that root (RFC 8446 §4.4.2). The client then checks each link — issuer name, key identifier and signature (RFC 5280) — until it reaches a root it already trusts; when an intermediate is missing, many clients cannot build that path and refuse the connection.

How to use Certificate Chain Checker

  1. Enter the host name (or an IP address with the site name in Server name (SNI)), or paste a bundle that starts with the site certificate.
  2. Press Check chain.
  3. Read the Summary: Chain complete and Signatures verify should both be ✓. Then read the Issues list, if any.
  4. Fix the server configuration — usually by installing the full chain file instead of the certificate alone — and check again.

Certificate Chain Checker features

  • Reads the exact list of certificates a server sends in its TLS handshake, in the order it sends them, including TLS 1.3 servers whose Certificate message is encrypted
  • Checks a pasted PEM bundle (a fullchain.pem, a CA bundle, a load balancer export) entirely in your browser before you deploy it
  • Follows the chain from the leaf by issuer name and key identifier and says whether it reaches a CA whose issuer the client is expected to hold
  • Verifies every link with WebCrypto: each certificate's signature is checked under the public key of the certificate presented as its issuer (RSA, RSA-PSS, ECDSA P-256/384/521, Ed25519)
  • Flags a missing intermediate, certificates out of order, duplicates, unrelated extras, expired or not-yet-valid members, issuers not marked as CA or without keyCertSign, and pathLen violations
  • A table with each certificate's role, subject, issuer, expiry, days left, key and the certificate that signed it
  • The chain as sent, in PEM, ready to copy or download as chain.pem

Inputs and outputs

Inputs

  • Host name or URL, Port and Server name (SNI): where to read the chain from, as in the SSL Certificate Checker.
  • Or a pasted bundle: PEM certificates in the order a server would send them, site certificate first. Nothing is fetched when a bundle is present; a host name, if given, is only matched against the first certificate.

Outputs

  • Summary: number of certificates, chain complete, leaf-to-root order, whether every link's signature verifies, whether a root was included, and whether the leaf names the host.
  • Chain: one row per certificate with its role (leaf, intermediate, root, or not on the chain), subject, issuer, expiry, days left, key and the certificate whose key verified its signature.
  • Issues: each problem in a sentence that names the certificate by number and subject.
  • Chain as sent (live check only): the certificates in PEM, in the server's order.

Certificate Chain Checker example

The example bundle: site certificate plus its intermediate, pasted (checked on 14 October 2026)

Input:

Pasted bundle: the www.example.com certificate followed by "Example Issuing CA R1" (the page's example)
Host name: www.example.com

Output:

Certificates 2 · Chain complete ✓ · Leaf-to-root order ✓ · Signatures verify ✓ (every link checked) · Root included ✗ (optional) · Leaf names this host ✓
#1 www.example.com · issuer Example Issuing CA R1 · leaf · valid until 2046-10-01 · 7291 days · EC P-256 (256 bits) · signed by ✓ (#2)
#2 Example Issuing CA R1 · issuer Example Root CA X1 · intermediate · valid until 2051-10-01 · EC P-256 (256 bits) · signed by — (root not sent)

How to read the Certificate Chain Checker results

Chain complete ✓ means the chain climbs from the leaf to an included root, or to a CA certificate whose own issuer was not sent and is expected to be in the client's store (that is not checked). ✗ usually means the intermediate is missing: browsers may repair that, most other clients will not.

Signatures verify ✓ means every link that could be checked verified. ✗ means a certificate is not signed by the one presented as its issuer — typically an intermediate from another CA or an old one after a CA changed intermediates. ? means a link uses an algorithm WebCrypto cannot verify. — means there was no link to check: only the leaf was sent.

Root included ✗ is normal and not an error. A row marked "not on the chain" is a certificate the server sends for nothing: remove it to save bytes and avoid confusing clients.

A clean result describes the chain the server sends; whether a given browser or device trusts its root is decided by that client's root store, which this page does not have.

When to use Certificate Chain Checker

  • Find out why an API client, a mobile app or curl rejects a site that opens fine in a desktop browser.
  • Check a fullchain.pem or CA bundle before installing it on a load balancer, a mail server or an appliance.
  • Confirm that a server picked up a CA's new intermediate after a renewal and no longer sends an old one.
  • Show which certificate in a long chain has expired or lacks the CA flag.

Troubleshooting

  • "The server sent only the leaf certificate": configure the full chain — in nginx ssl_certificate must point to the fullchain file, in Apache use a certificate file that includes the intermediates, on a load balancer upload the CA bundle.
  • "is not signed by": the intermediate does not belong to this leaf. Download the intermediate your CA currently issues from and replace the old one.
  • "is not part of the chain from the leaf": an extra certificate (often an old intermediate or a cross-sign no longer needed) is sent. Remove it from the bundle.
  • "The certificates are not in leaf-to-root order": reorder the bundle so the site certificate comes first and each certificate is followed by its issuer.
  • Served through Cloudflare: paste the chain instead. In most browsers the certificate viewer can export the chain as PEM; on your server, use the fullchain file your CA client wrote.

Frequently asked questions about Certificate Chain Checker

Why do some browsers accept my site while others report an incomplete chain?

When a server sends only its own certificate, some browsers repair the chain themselves — they download the missing intermediate from the address in the certificate, or use a copy they preloaded or saw before — so the site "works on my machine". Many other clients do not: curl, Java and Python programs, most API and mobile-app clients fail. The fix is on the server: send the leaf followed by every intermediate (often a file called fullchain.pem).

Should the root certificate be included?

It is not needed: clients use the root from their own store, never the copy a server sends, so including it only adds bytes to every handshake. It does no harm either, and the checker reports it as information, not as an error.

What does "signed by the next certificate" prove?

That the signature on each certificate verifies under the public key of the certificate the server presents as its issuer — the chain is cryptographically consistent. It does not prove trust: a chain whose every link verifies can still end in a root that no browser ships. That last step needs a root store, which this checker does not have.

In what order must the certificates be sent?

Leaf first, then the certificate that issued it, then the one that issued that, and so on. RFC 8446 requires the leaf to come first and says each following certificate should certify the one before it; some clients tolerate another order and some do not, so the checker flags it.

Can I check the chain of a site served through Cloudflare?

Not by host name: the Mutqan server runs on Cloudflare Workers, which may not open raw connections to Cloudflare addresses. Export the chain from your browser's certificate viewer (or take your server's fullchain file) and paste it, or test your origin server by IP address with the site name in the Server name (SNI) field.

Why is a link shown with "?" instead of ✓ or ✗?

Its signature uses an algorithm the WebCrypto API cannot verify — DSA, Ed448, MD5 or SHA-224 based signatures, or an unusual curve. The link is reported as unverified, not as broken; check it with OpenSSL if it matters.

Technical notes

A TLS server sends its certificate_list with the leaf first; RFC 8446 §4.4.2 (and RFC 5246 for TLS 1.2) says each following certificate should certify the one before it. The root may be omitted because clients take it from their own store.

Linking follows RFC 5280: a certificate's issuer name must equal the next certificate's subject name, and when both carry them the Authority Key Identifier must equal the issuer's Subject Key Identifier. Every issuing certificate must be a CA (basicConstraints) allowed to sign certificates (keyCertSign), within its pathLenConstraint and its validity dates.

Each link is verified by checking the signature over the certificate's TBSCertificate bytes with the issuer's public key through WebCrypto: RSASSA-PKCS1-v1_5 and RSA-PSS with SHA-1 or SHA-2, ECDSA (the DER signature converted to the raw r||s form) on P-256, P-384 and P-521, and Ed25519. Algorithms WebCrypto lacks are reported as not checkable, never as valid.

Pasted text (at most 256 KB) is read as RFC 7468 PEM: every -----BEGIN CERTIFICATE----- block, up to 16, in the order given. A block whose base64 or DER cannot be decoded is named by its position in the text and left out of the analysis.

Limitations and methodology

No root store: the checker can say a chain is complete and its signatures verify, not that a browser trusts it. Revocation (OCSP, CRL) and Certificate Transparency are not checked.

The live check connects from the Cloudflare data centre that serves your request; hosts that resolve to Cloudflare cannot be reached by its raw connection at all, and a server that answers differently by region may send another chain to your visitors.

Cross-signed paths are not explored: the chain is followed through the certificates actually sent, choosing a key-identifier match first; alternative paths a client could build with certificates it holds are not considered.

Security and privacy

A pasted bundle is decoded and verified in your browser and never leaves it. For a live check the host, port and server name go to the Mutqan server, which opens one TLS connection and stores nothing about the target or the result. Never paste a private key; the page refuses text that contains one.

References