Inspect Your Certificate Chain Above

Inspect Your Certificate Chain: How TLS Clients Verify Trust

Paste your certificate chain into the inspector above and it renders the same path TLS clients build when they verify that a server's certificate can be trusted through an unbroken sequence of cryptographic signatures from the leaf up to a trusted root. The validation algorithm is defined in RFC 5280 Section 6 and requires every certificate in the chain to satisfy six conditions simultaneously: valid signature, valid validity window, name constraints consistent with the chain, Basic Constraints allowing CA usage where required, Key Usage permitting certificate signing for each CA in the chain, and no revocation by the issuing CA¹. A failure at any link in the chain causes the entire chain to fail, even when the leaf certificate is perfectly valid, so checking your own chain above is the fastest way to catch a broken link before it reaches production.

How path-building works in practice

When a browser or TLS client receives a certificate chain from a server, it attempts to build a trusted path from the leaf certificate to a root in its trust store. Starting with the leaf, the client looks for a certificate in the chain whose subject distinguished name and Subject Key Identifier match the leaf's issuer name and Authority Key Identifier¹. It then repeats this process for each successive certificate until it reaches a certificate whose issuer is in the trust store.

How path-building selects the next certificate in the chain

The matching rules rely on two fields: the Authority Key Identifier of the certificate being validated must equal the Subject Key Identifier of the issuing certificate, and the issuer distinguished name must match. When multiple candidates exist, the client picks the one whose fields satisfy both constraints. A chain that provides certificates out of order forces the client to search the entire bundle for a match, and some clients give up after the first candidate rather than retry. The CapyToolkit Certificate Inspector renders the chain in leaf-first order with connector lines showing issuer relationships, making ordering errors and missing certificates immediately visible.

Name constraints and path length limits

RFC 5280 allows CA certificates to carry Name Constraints extensions that limit which subjects the CA may sign certificates for. A Name Constraints extension with a permittedSubtrees component restricts the CA to issuing certificates for names within specified domains, IP ranges, or email patterns. When a CA certificate carries name constraints, every certificate it signs must comply with those constraints.

How pathLenConstraint limits chain depth

The pathLenConstraint field in the Basic Constraints extension limits how many additional CA certificates may follow a given CA in a valid chain. A pathLenConstraint of 0 means the CA may only sign leaf certificates; a value of 1 means it may sign one level of sub-CAs plus leaf certificates. Chains that violate either constraint fail validation even when every signature is cryptographically correct². The CapyToolkit Certificate Inspector surfaces both the name constraints and the pathLenConstraint values on each CA certificate card so you can verify the chain stays within the limits the root CA set.

A practical implication is that a chain can be cryptographically perfect yet still fail validation when a constraint is breached. The order of certificates and the fields on each CA card matter as much as the signatures, so building the chain by hand is error-prone. The CapyToolkit Certificate Inspector renders each link with its constraints visible, so you can see at a glance where a chain exceeds the depth or scope its root CA allowed.

Revocation checking and OCSP stapling

Certificate revocation adds a fourth dimension to chain validation beyond signatures, validity windows, and constraints. A certificate can be revoked before its notAfter date when its private key is compromised or when CA policy requires the CA to invalidate the binding. CAs publish revocation information through Certificate Revocation Lists (CRLs) defined in RFC 5280 and through the Online Certificate Status Protocol (OCSP) defined in RFC 6960.

Why soft-fail OCSP weakens revocation enforcement

Browsers check revocation status for the leaf certificate, and some check intermediates as well. Yet soft-fail OCSP behavior, where a browser accepts a certificate when the OCSP responder is unreachable, means revocation checks are not as reliable as chain signature verification³. An attacker who intercepts traffic can also block the OCSP request, causing the browser to accept a revoked certificate without raising an error.

How OCSP stapling closes that gap

OCSP stapling, in which the server pre-fetches and attaches the OCSP response to the TLS handshake, improves revocation reliability without depending on the client being able to reach the OCSP responder at handshake time. The stapled response is signed by the CA, so the client can trust it even when the network path to the OCSP responder itself is blocked.

When to use this

Use this guide when debugging TLS handshake errors related to chain validation, when configuring a web server to send the correct certificate chain, or when auditing an internal PKI to verify that intermediate CA constraints are correctly configured. It is equally relevant when you add a new server or CDN edge node to an existing deployment and want to confirm the certificate chain it sends matches what other nodes serve, and a quick chain inspection makes it easy to spot a missing or misordered certificate before the node goes live. Furthermore, use it when you set up a new CA hierarchy for internal services, to verify the pathLenConstraint and name constraint fields are set correctly before signing leaf certificates. Building on this, the chain validation concepts apply any time you troubleshoot why some clients succeed and others fail on the same endpoint, since missing intermediates explain the split behavior between clients that have the intermediate cached and new clients that must build the trust path from scratch using only what the server sends.

Examples