// TLS / SSL / X.509 / Chain of Trust
This certificate analyzer instantly inspects a PEM certificate — or a full chain — showing subject, issuer, validity dates, Subject Alternative Names, key algorithm, and expiration status. Analyze certificate chains in seconds: it automatically detects chain order and cryptographically verifies certificate signatures. Runs entirely in your browser.
How to get a certificate in PEM format
From a server: openssl s_client -connect example.com:443 -showcerts < /dev/null 2>/dev/null | openssl x509. For the full chain, drop the trailing | openssl x509 and paste every -----BEGIN CERTIFICATE----- block shown. From a file: if your certificate is in DER format (.cer, .crt binary), convert with openssl x509 -inform DER -in cert.cer -out cert.pem. From a PKCS#12 bundle (.pfx, .p12): openssl pkcs12 -in bundle.pfx -clcerts -nokeys -out cert.pem. The PEM format starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----.
Subject Alternative Names (SANs) — why they matter
Modern browsers require SANs — the Common Name (CN) field alone is no longer trusted. SANs list every hostname the certificate is valid for. A wildcard SAN like *.example.com covers all single-level subdomains but not sub.sub.example.com. Multi-domain (SAN) certificates can include hundreds of hostnames. Let's Encrypt certificates always include SANs. If a browser shows "certificate does not match", it means the hostname is not in the SANs list.
Certificate chain — why a valid cert can still fail
A TLS handshake requires the full chain: your end-entity certificate + all intermediate CA certificates up to a trusted root. If intermediates are missing, some clients (curl, older Android) fail with "certificate verify failed". Check the chain with openssl s_client -connect example.com:443 -showcerts — you should see multiple certificates. Use openssl verify -CAfile chain.pem cert.pem to validate the full chain locally.
Verifying a chain and its signatures with this tool
Paste more than one certificate block and this analyzer detects each certificate's role (leaf, intermediate, or self-signed root), checks that each issuer matches the next certificate's subject, and cryptographically verifies each signature against the next certificate's public key using your browser's Web Crypto API — no data leaves your browser. Supports RSA (SHA-256/384/512/1) and ECDSA (P-256/P-384/P-521) signatures. A broken link or a failed signature check means the chain would not validate on a real client.
openssl x509 -in cert.pem -text -noout shows all fields. To inspect a live server: openssl s_client -connect example.com:443 < /dev/null | openssl x509 -text -noout. For quick expiry check: openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates.-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. PEM files can contain a single certificate or a full chain (multiple BEGIN/END blocks). Used by Apache, Nginx, Let's Encrypt, and most modern web servers. Alternative formats: DER (binary), PKCS#12/PFX (includes private key), PKCS#7/P7B (chain without private key).openssl verify or SSL Labs (ssllabs.com/ssltest) for full trust-store and revocation checks.openssl s_client -showcerts) into the tool above. It checks that each certificate's issuer matches the next certificate's subject, and cryptographically verifies each signature against the next certificate's public key — directly in your browser. A missing root at the end is normal (roots live in the trust store, not the chain sent by the server); a broken link in the middle or a failed signature check is not, and typically causes "unable to get local issuer certificate" or "certificate verify failed" errors on real clients.