SSL Certificate Analyzer
Analyze X.509 SSL/TLS certificates. View issuer, validity, SANs, certificate chain. Check SSL certificate details. Free online certificate decoder
An X.509 certificate is a binary structure encoding the holder's public key, identity, and cryptographic signatures from issuing authorities. The interesting fields are not "Issued to: example.com" — they are the SANs (which hostnames this cert actually covers), Key Usage extensions (what the key is allowed to do), and the signature chain (which CAs vouched for this and when they will expire). This tool parses PEM and DER certificates client-side, walks the trust chain, and flags the modern security concerns (deprecated SHA-1, RSA-1024, missing AIA/OCSP fields).
Certificate fields by importance
- Subject — who the cert identifies. For TLS, the CN was historically the hostname; modern certs use Subject Alternative Names (SAN) instead.
- Subject Alternative Names (SAN) — list of hostnames the cert covers. example.com, www.example.com, api.example.com. Browsers ignore CN and require SAN for hostname verification since 2017.
- Issuer — who signed this cert. Trust chain follows: leaf → intermediate(s) → root.
- Validity — not-before (when cert becomes valid) and not-after (when it expires). Most modern leaf certs are 90 days (Let's Encrypt) or 1 year (commercial). After 2020, browsers reject leaf certs valid longer than ~398 days.
- Public Key — algorithm (RSA, ECDSA, Ed25519) and parameters. Modern: ECDSA P-256 or RSA-2048+. Avoid RSA-1024.
- Signature Algorithm — how the issuer signed this cert. Modern: SHA256-RSA or SHA256-ECDSA. SHA-1 deprecated.
- Key Usage / Extended Key Usage — what the key is allowed to do (server auth, client auth, code signing, email, etc.). Wrong EKU means a TLS cert cannot validate.
- Authority Info Access (AIA) — URL to fetch the issuing CA cert. Required for chain building when the server does not provide all intermediates.
- CRL / OCSP — where to check for revocation.
Working example
Input
A typical Let's Encrypt cert
Output
Subject: CN = example.com Subject Alternative Names: DNS: example.com DNS: www.example.com Issuer: CN = E1 O = Let's Encrypt C = US Validity: Not Before: 2026-04-01 00:00:00 UTC Not After: 2026-06-30 23:59:59 UTC → 91 days lifetime, 47 days remaining Public Key: Algorithm: ECDSA P-256 Size: 256 bits Curve: prime256v1 Signature Algorithm: ecdsa-with-SHA256 Key Usage: Digital Signature, Key Agreement Extended Key Usage: TLS Web Server Authentication TLS Web Client Authentication Chain: → example.com (leaf, just parsed) → Let's Encrypt E1 (intermediate) → ISRG Root X2 (trusted root) All good. Modern algorithms, short lifetime, complete chain.
Most TLS certificate issues in 2026 are operational (renewal didn't fire, chain not served by server) rather than cryptographic. Use this tool to verify the chain a server actually serves, not just what you assume should be served.
Modern certificate red flags
- Lifetime > 398 days — browsers reject new certs exceeding this. Trusted CAs no longer issue 2-year certs.
- Signature using SHA-1 or MD5 — deprecated since 2017. Browsers reject SHA-1-signed leaf certs.
- Public key RSA-1024 — too small for 2026. RSA-2048 minimum; ECDSA-P256 preferred.
- Missing SAN — only CN-based hostname matching is deprecated. Modern browsers require SAN.
- Wildcard cert (*.example.com) — works for one subdomain level only. Does not match a.b.example.com.
- Self-signed cert in production — fine for internal tools with controlled trust; never serve to public users.
- Cert issued by unknown CA �� verify chain terminates at a major trusted root (Let's Encrypt, DigiCert, Sectigo, GoDaddy, Cloudflare).
- Inconsistent dates — not-before in the future, or expired before issuance, indicates clock issues.
When to reach for this tool
- You captured a certificate (with openssl s_client -showcerts or curl --insecure -v) and want to inspect its details.
- You are debugging "the certificate chain is incomplete" — verify whether intermediate certs are in your captured chain.
- You inherited a server and want to audit when each certificate expires before something fails.
- You are migrating CAs and want to compare old and new certs for parity.
What this tool will not do
- It will not validate revocation. CRL and OCSP queries require fetching from the issuing CA; this tool parses cert structure only. For revocation status, use openssl ocsp or browser-based checks.
- It will not check that the server actually serves this cert. Browser-based fetch over TLS to your hostname is the right test for "what does the server actually serve" — see the SSL Checker tool.
- It will not generate certificates. For self-signed certs use openssl req -x509; for real production certs use a CA (Let's Encrypt or commercial).
All parsing happens in your browser. Certificates pasted are not transmitted. Useful for inspecting certs from private CAs, internal infrastructure, or anywhere you would not want to upload to a third-party analyzer.
Frequently asked questions
PEM or DER — what is the difference?
PEM is Base64-encoded DER wrapped between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" markers. DER is the raw binary form. PEM is text-friendly (paste in chat, paste in config files); DER is more compact. The cert content is identical; the encoding differs.
Why is my "wildcard cert" not covering a.b.example.com?
Wildcard *.example.com matches one level — a.example.com, b.example.com — but not a.b.example.com. For multi-level wildcards, you need a wildcard SAN at each level OR a SAN list specifying every subdomain you need.
What is an "intermediate certificate"?
A cert that signs leaf certs but is itself signed by a root cert. Root certs are stored in browser/OS trust stores; intermediates are not. The server must serve the intermediate(s) with the leaf so the client can build a chain to the root.
Does a missing intermediate matter?
Depends on the client. Some browsers (Chrome) cache intermediates from prior visits and can build the chain anyway. Others (Safari, curl, server-to-server TLS) cannot. For reliability, always serve the full chain — Let's Encrypt provides fullchain.pem for this reason.
How do I trust a custom CA on my own machine?
Linux: add the root CA cert to /etc/ssl/certs/ and run update-ca-certificates. macOS: add to Keychain and mark as trusted. Windows: certmgr.msc to Trusted Root Certification Authorities. For applications using their own trust store (curl with --cacert, npm with NODE_EXTRA_CA_CERTS), configure separately.
Does the certificate expire matter exactly to the second?
Yes — most TLS libraries reject certificates not-before is in the future or not-after is in the past, both checked precisely. A 30-second clock skew between client and server can cause "certificate not yet valid" errors right after issuance. NTP-synchronized time prevents this.
Related tools
Check SSL certificate for any domain. View expiration date, issuer, certificate chain. Verify HTTPS security and get SSL rating
Generate SSH key pairs (RSA, Ed25519) in your browser. Export in OpenSSH or PEM format. Secure client-side key generation. Free online SSH keygen tool
Generate MD5, SHA-1, SHA-256, SHA-512 hashes from text or files. Verify file checksums. Free online hash calculator and checksum generator
Build Content-Security-Policy headers visually. Add directives, sources, preview policy. Free online CSP generator for web security
Learn how AES and RSA encryption works step by step. Visualize encryption process, key generation, and cipher operations. Interactive cryptography tutorial
Last updated · E-Utils editorial team