// TLS / SSL / X.509 / Chain of Trust
This certificate analyzer works two ways: enter a domain name to fetch and analyze its live TLS/SSL certificate directly from the server, or paste a PEM certificate — or a full chain — for instant offline analysis. Either way you get subject, issuer, validity dates, Subject Alternative Names, key algorithm, and expiration status, plus automatic chain-order detection and cryptographic signature verification.
Analyzing a live domain vs. a PEM certificate
Enter any domain (e.g. example.com) in the box above and this tool connects to it on port 443, retrieves the certificate chain the server presents, and analyzes it automatically — no command line needed. This is the fastest way to check what a live site is actually serving right now. Alternatively, paste a PEM certificate you already have (from a file, an email, or a colleague) for the same analysis without any network connection.
How to get a certificate in PEM format manually
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.
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". Use openssl verify -CAfile chain.pem cert.pem to validate the full chain locally.
Verifying a chain and its signatures with this tool
Whether fetched from a live domain or pasted manually, 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 once the PEM is loaded. 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.-----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.