Certificate Parser

X.509 certificates are the standard format for public key certificates used in TLS/SSL. This tool parses PEM-encoded certificates to display the subject, issuer, validity period, public key details, and extensions. Essential for debugging HTTPS connection issues.

Specifications

Common Use Cases

Debug SSL/TLS connection errors ("certificate has expired")
Verify certificate covers the correct domain names
Check certificate expiration dates for renewal planning
Inspect intermediate and root certificates in a chain
Verify certificate attributes meet compliance requirements

Features

Parse PEM-encoded certificates (-----BEGIN CERTIFICATE-----)
Display subject and issuer distinguished names
Show validity period (Not Before / Not After)
Extract public key algorithm and size
Display Subject Alternative Names (SANs)
Show certificate extensions (Key Usage, Extended Key Usage, Basic Constraints)
Authority/Subject Key Identifier display
CRL Distribution Points and Authority Information Access URLs

Examples

Self-Signed Certificate

Try it →

An X.509 certificate for example.com with Subject Alternative Names.

Private Key

Try it →

A corresponding RSA private key in PKCS#8 format.

Tips

Export a certificate from browser: click the padlock > Certificate > Details > Export.
Get a site's certificate with: openssl s_client -connect example.com:443
SANs (Subject Alternative Names) list all valid domain names.
Root certificates are self-signed (issuer = subject).
Check certificate chain with: openssl verify -CAfile ca.pem cert.pem

Understanding Certificate

X.509 certificates are the foundation of trust on the internet, enabling TLS/SSL encryption for HTTPS connections, code signing, email security (S/MIME), and VPN authentication. A certificate binds a public key to an identity (domain name, organization, or individual), and a Certificate Authority (CA) vouches for this binding by digitally signing the certificate.

Certificates are typically stored in PEM format — Base64-encoded DER data enclosed between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers. A certificate contains the subject (who the certificate identifies), the issuer (who signed it), a validity period (Not Before and Not After dates), the subject's public key, and extensions that control usage. The Subject Alternative Name (SAN) extension lists all domain names the certificate covers.

Certificate chains establish trust by linking an end-entity certificate to a trusted root CA through one or more intermediate CAs. When a browser connects to a website, it verifies the chain: the server's certificate was signed by an intermediate CA, which was signed by a root CA that the browser trusts. A broken chain — missing intermediates or an unknown root — causes the familiar "Your connection is not private" error.

Certificate management is a common source of outages. Expired certificates cause immediate service disruption. Mismatched domain names trigger browser warnings. Missing intermediate certificates work in some browsers (which may cache or fetch them) but fail in others and in API clients. Monitoring certificate expiration and automating renewal with tools like Let's Encrypt and certbot is essential for reliable operations.

To check when a certificate expires, paste the PEM content into this tool and look at the Not After date. From the command line, run openssl x509 -enddate -noout -in cert.pem for a local file, or openssl s_client -connect example.com:443 piped to openssl x509 -noout -enddate for a remote server. Automated monitoring through certbot, cert-manager, or dedicated monitoring services can alert well before expiration to prevent outages.

Root certificates are self-signed (the issuer equals the subject) and come pre-installed in browsers and operating systems as trust anchors. Intermediate certificates are signed by a root CA and are used to sign end-entity certificates. This chain of trust protects the root key — if an intermediate is compromised, only that intermediate is revoked rather than the root. Servers must send the full chain (end-entity plus all intermediates) but should not include the root certificate itself.

Subject Alternative Names (SANs) list all the domain names and IP addresses a certificate is valid for. A single certificate can protect multiple domains like example.com, www.example.com, and api.example.com using SANs. Modern browsers use SANs instead of the Common Name (CN) field for domain validation. Wildcard certificates (*.example.com) cover one level of subdomains but not the apex domain itself.

A certificate that works in browsers but fails in API clients is a common issue caused by incomplete certificate chains. Browsers are more forgiving — some fetch missing intermediates automatically through AIA (Authority Information Access) fetching or use previously cached intermediates. API clients like curl, Node.js, and Python's requests library typically require the complete chain to be sent by the server. Ensure your server is configured to send the end-entity certificate plus all intermediate certificates, and test with curl -v or openssl s_client to verify the chain is complete.

← Back to all tools