Visualize the complete SSL certificate chain from leaf to root CA. Check chain completeness and intermediate certificates.
Paste a PEM certificate or a full chain and this tool draws the trust path from your leaf certificate up to the root CA, matching each certificate's issuer to the next certificate's subject. It judges the chain complete or incomplete: a chain whose top certificate is not self-signed is missing at least one intermediate, and the tool names the certificate that is absent. The surprise most people hit is that their browser can load a site with a broken chain, because the browser already holds the missing intermediate in its cache - so 'it works for me' never proves the server is sending a complete chain.
A concrete input and expected output from the current implementation.
Input
Two PEM certificates pasted leaf-first, as a server would send them: 1. Leaf: Subject CN = shop.example.com, Issuer CN = R3 (Let's Encrypt) 2. Intermediate: Subject CN = R3, Issuer CN = ISRG Root X1
Expected output
A chain of three tiers is drawn: shop.example.com -> R3 -> ISRG Root X1. Both links check out: the leaf's issuer (R3) matches the intermediate's subject (R3), and the intermediate's issuer (ISRG Root X1) matches the root's subject (ISRG Root X1). The root is self-signed, so the chain terminates there. Verdict: complete, no missing intermediate.
This is the standard Let's Encrypt path: ordinary certificates are signed by the R3 intermediate, which is signed by the self-signed ISRG Root X1. Because every issuer matches the subject above it and the top certificate is self-signed, the chain needs no further certificates.
The tool reads every PEM block delimited by BEGIN CERTIFICATE and END CERTIFICATE lines, decodes the base64 DER, and extracts each certificate's subject and issuer names. It then lays the certificates out so that each one's issuer matches the subject of the certificate above it, drawing the leaf at the bottom and the terminating root at the top.
Every certificate states its issuer by name, so a truncated chain names its own missing piece: the issuer field of the topmost certificate is the subject of the certificate that should follow it. The chain is judged complete when the top certificate is self-signed, subject equal to issuer, and incomplete otherwise.
Both can be. Browsers keep intermediates cached from earlier connections, and some clients fetch a missing intermediate from the Authority Information Access URL embedded in the certificate. Others - curl with a strict bundle, many mobile apps, embedded devices - never do and will reject the site. Sending the full chain satisfies both.
No. Self-signed means the chain cannot go any higher, so it is complete in structure. Trust is a separate question: a public site should end at a root that ships with operating systems and browsers, while a chain ending at your own private root is accepted only by clients configured to trust it.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.