What are the different X.509 certificate formats (PEM, DER, CRT, CER)?

X.509 certificates come in multiple encoding formats: **PEM (Privacy Enhanced Mail)** - Base64-encoded, text format, enclosed in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers, most common format, .pem or .crt extension. **DER (Distinguished Encoding Rules)** - Binary format, more compact than PEM, .der or .cer extension, commonly used in Java. **PKCS#7/P7B** - Container format that can include certificate chain, Base64-encoded with .p7b extension, used by Windows and Java. **PKCS#12/PFX** - Binary format containing certificate AND private key, password protected, .p12 or .pfx extension, used for importing/exporting. **CRT/CER** - Generic extensions that can be either PEM or DER format, need to check file contents to determine actual format. To convert formats: PEM to DER: `openssl x509 -in cert.pem -outform DER -out cert.der`, DER to PEM: `openssl x509 -in cert.der -inform DER -out cert.pem`.

What is a certificate chain and why is it important?

A certificate chain (or chain of trust) is a sequence of certificates linking an end-entity certificate (your website) to a trusted root CA. Typical chain: **End-Entity Certificate** (leaf) → Your website's certificate, contains your domain. **Intermediate Certificate(s)** → Issued by CA, signs your certificate. **Root Certificate** → Self-signed, pre-installed in browsers/OS, ultimate trust anchor. Why chains matter: (1) **Security** - Root CA private keys are kept offline for security. Intermediates handle day-to-day signing. (2) **Trust** - Browsers/OS trust root CAs. Your certificate inherits that trust through the chain. (3) **Revocation** - If an intermediate is compromised, only that intermediate needs replacement, not the root. Common issues: Missing intermediate certificates (browser shows "incomplete chain"), Wrong order (chain must go leaf→intermediate→root), Expired intermediate, Self-signed certificates (no chain, browser warnings). Always include the full chain when configuring SSL/TLS servers.

What is the difference between DV, OV, and EV certificates?

SSL/TLS certificates come in three validation levels with increasing identity verification: **DV (Domain Validation)** - Verifies domain ownership only (email or DNS validation), issued in minutes, cheapest option (~$0-50/year), shows padlock in browser, suitable for blogs, personal sites. No organization validation. **OV (Organization Validation)** - Verifies domain ownership AND organization identity, CA validates organization exists and operates at claimed address, takes 1-3 days, moderate cost (~$50-200/year), shows organization name in certificate details, suitable for businesses, e-commerce. **EV (Extended Validation)** - Most rigorous validation, extensive verification of organization's legal, physical, and operational existence, takes 1-2 weeks, expensive (~$150-1000/year), historically showed company name in browser address bar (deprecated in 2019 due to phishing concerns), suitable for financial institutions, high-security needs. Modern recommendation: DV is sufficient for most websites with proper HTTPS. EV provides minimal additional security benefit after browsers removed the EV indicator.

What are Subject Alternative Names (SANs) in certificates?

Subject Alternative Names (SANs) are X.509 v3 extensions that allow a single certificate to secure multiple domains/subdomains. Before SANs: One certificate = one domain, required separate certificates or expensive wildcard certificates. With SANs: One certificate can include: Multiple domains (example.com, example.org), Multiple subdomains (www.example.com, api.example.com, mail.example.com), Wildcard and specific domains together (*.example.com, example.com), IP addresses (192.168.1.1), Email addresses (for S/MIME). Example SAN certificate: CN: example.com, SAN: example.com, www.example.com, blog.example.com, shop.example.com. Benefits: Cost-effective (one certificate for multiple domains), Easier management (single renewal/installation), Flexible (add/remove domains as needed). Limitations: Most CAs limit SANs to 100-250 domains, All domains visible in certificate (privacy concern), All domains share same validation level. Modern best practice: Use SAN certificates instead of buying separate certificates for each domain.

What information can I find in a decoded X.509 certificate?

A decoded X.509 certificate reveals extensive information: **Subject Information** - Common Name (CN): domain name, Organization (O), Organizational Unit (OU), Locality (L), State/Province (ST), Country (C). **Issuer Information** - Certificate Authority that issued the certificate, Issuer's signature algorithm. **Validity** - Not Before date (certificate start), Not After date (expiration), Days remaining until expiration. **Public Key** - Algorithm (RSA, ECDSA, EdDSA), Key size (2048-bit, 3072-bit, 4096-bit), Public key value. **Extensions** - Subject Alternative Names (SAN), Key Usage (encryption, signing), Extended Key Usage, Basic Constraints (CA certificate?), Authority Key Identifier, Subject Key Identifier, CRL Distribution Points, Authority Information Access (OCSP). **Signature** - Signature algorithm (SHA256withRSA), Signature value, Thumbprint/fingerprint (SHA-1, SHA-256). **Certificate Policies** - OIDs indicating certificate purpose, EV status indicators. This information helps verify certificate authenticity, check expiration, validate domain coverage, and audit security properties.

How can I check if a certificate is expired or will expire soon?

Certificate expiration checking is critical for maintaining secure connections: **Check Methods:** (1) **Browser** - Visit HTTPS site, click padlock, view certificate, check "Valid until" date. (2) **OpenSSL** - `openssl x509 -in cert.pem -noout -dates` shows validity period. (3) **Online Tools** - This decoder tool, SSL Labs SSL Test. (4) **Monitoring** - Automated tools that alert before expiration. **Expiration Timeline:** Modern certificates: 398 days maximum (13 months), Old certificates: Previously 825 days (2-3 years), Let's Encrypt: 90 days (encourages automation). **Best Practices:** Monitor 30 days before expiration, Automate renewal (Let's Encrypt certbot, ACME protocol), Set up alerts (email, Slack, PagerDuty), Test renewal process quarterly, Keep contact information updated. **Consequences of Expiration:** Browser warnings ("Your connection is not private"), Users can't access site (especially mobile), SEO ranking impacts, Lost revenue and trust, API integrations fail. Set up automated renewal to avoid manual tracking. Certificate transparency logs can help discover forgotten certificates.

What is the difference between RSA and ECDSA certificates?

RSA and ECDSA are two different public-key cryptography algorithms used in X.509 certificates: **RSA (Rivest-Shamir-Adleman)** - Older algorithm (1977), Widely supported everywhere, Larger keys (2048-bit minimum, 4096-bit recommended), Larger certificates (~1-2KB), Slower signing and encryption, Battle-tested and trusted. **ECDSA (Elliptic Curve Digital Signature Algorithm)** - Modern algorithm, Smaller keys (256-bit = 3072-bit RSA security), Much smaller certificates (~500 bytes), Faster operations (3x faster signing), Lower CPU and bandwidth usage, Growing support (all modern browsers, some older clients incompatible). **Key Size Equivalence:** RSA 2048-bit ≈ ECDSA 224-bit, RSA 3072-bit ≈ ECDSA 256-bit, RSA 7680-bit ≈ ECDSA 384-bit. **Modern Recommendation:** Use ECDSA for new deployments (P-256 curve), Provides dual RSA+ECDSA certificates for compatibility, Benefits: Faster TLS handshakes, Lower server CPU usage, Smaller certificate chains. If supporting legacy clients (Windows XP, old Android), stick with RSA 2048-bit or provide dual certificates.

Home/Tools/Security/X.509 Certificate Decoder

X.509 Certificate Decoder

Decode and analyze X.509 SSL/TLS certificates. Parse PEM, DER, and CRT formats with detailed certificate chain validation and security analysis.

100% Private - Runs Entirely in Your Browser

No data is sent to any server. All processing happens locally on your device.

Loading X.509 Certificate Decoder...

Certificate (PEM)

Input Method

Loading interactive tool...

JavaScript Required

This interactive tool requires JavaScript to function. Please enable JavaScript in your browser to use the full features.

The tool description and documentation above provide information about this tool's capabilities. For the best experience, please enable JavaScript and refresh the page.

Need Professional Security Testing?

Our penetration testers find vulnerabilities before attackers do. Get a comprehensive security assessment.

Learn About Penetration Testing Explore Risk Assessment

What Is an X.509 Certificate Decoder

An X.509 certificate decoder parses and displays the contents of digital certificates used in TLS/SSL, code signing, email encryption (S/MIME), and other PKI (Public Key Infrastructure) applications. X.509 is the ITU-T standard that defines the format of public key certificates, and decoding them reveals critical information about identity, validity, key usage, and the trust chain.

Every HTTPS connection relies on X.509 certificates to establish trust between a client and server. When your browser connects to a website, it receives the server's X.509 certificate, verifies the signature chain back to a trusted root Certificate Authority (CA), and checks that the certificate is valid for the requested domain. Understanding certificate contents is essential for security professionals, system administrators, and developers working with encrypted communications.

How X.509 Certificates Work

An X.509 v3 certificate contains these key fields:

Field	Description	Example
Version	Certificate format version	v3 (most common)
Serial Number	Unique identifier from the CA	03:A1:B2:...
Signature Algorithm	Algorithm used to sign	SHA256withRSA, ECDSA
Issuer	CA that issued the certificate	CN=Let's Encrypt R3
Validity	Not Before / Not After dates	2024-01-01 to 2025-01-01
Subject	Entity the cert identifies	CN=example.com
Public Key	Subject's public key	RSA 2048-bit, EC P-256
Extensions	Additional constraints and usage	SAN, Key Usage, CRL

Subject Alternative Names (SANs) are a critical extension that lists all domain names and IP addresses the certificate is valid for. Modern certificates rely on SANs rather than the Common Name (CN) field for domain matching. A single certificate might cover example.com, www.example.com, and api.example.com.

Key Usage and Extended Key Usage extensions restrict what the certificate can be used for—server authentication, client authentication, code signing, or email protection. A TLS server certificate should have the "serverAuth" extended key usage.

Common Use Cases

TLS troubleshooting: Decode certificates to diagnose handshake failures, expiration issues, or domain mismatches
Security auditing: Verify certificate key lengths, signature algorithms, and trust chains meet organizational policies
Certificate management: Inspect certificates before deployment to confirm SANs, validity periods, and key usage settings
Incident response: Analyze certificates from suspicious infrastructure to identify threat actor patterns
Compliance verification: Confirm certificates meet requirements like minimum RSA 2048-bit keys or specific CA policies

Best Practices

Check SANs, not just the Common Name — Browsers match domains against SANs; the CN field is largely ignored in modern TLS
Verify the full chain — A valid leaf certificate is useless if intermediate CA certificates are missing or expired
Monitor expiration dates proactively — Set alerts at 30, 14, and 7 days before expiry to prevent outages
Reject weak algorithms — SHA-1 signatures and RSA keys under 2048 bits are considered insecure
Use Certificate Transparency logs — CT logs provide a public record of all issued certificates, helping detect unauthorized issuance for your domains

References & Citations

D. Cooper et al.. (2008). RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Internet Engineering Task Force. Retrieved from https://www.rfc-editor.org/rfc/rfc5280 (accessed January 2025)
International Telecommunication Union. (2019). ITU-T X.509 Recommendation. Retrieved from https://www.itu.int/rec/T-REC-X.509/ (accessed January 2025)
B. Laurie et al.. (2013). Certificate Transparency (RFC 6962). Internet Engineering Task Force. Retrieved from https://www.rfc-editor.org/rfc/rfc6962 (accessed January 2025)
CA/Browser Forum. (2024). CA/Browser Forum Baseline Requirements. Retrieved from https://cabforum.org/baseline-requirements-documents/ (accessed January 2025)

Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.

Frequently Asked Questions

Common questions about the X.509 Certificate Decoder

X.509 is the standard format for public key certificates used in TLS/SSL and other cryptographic protocols. An X.509 certificate contains: (1) Public Key - The certificate holder's public key, (2) Identity Information - Domain name, organization, location, (3) Digital Signature - Signed by a Certificate Authority (CA) to prove authenticity, (4) Validity Period - Start and expiration dates, (5) Extensions - Subject Alternative Names (SANs), key usage, policies. X.509 certificates enable: HTTPS websites (SSL/TLS), Code signing, Email encryption (S/MIME), VPN authentication, and Document signing. When you visit an HTTPS website, your browser verifies the site's X.509 certificate to ensure you're connecting to the legitimate site and that the connection is encrypted. The certificate chain links back to a trusted root CA.

⚠️ Security Notice

This tool is provided for educational and authorized security testing purposes only. Always ensure you have proper authorization before testing any systems or networks you do not own. Unauthorized access or security testing may be illegal in your jurisdiction. All processing happens client-side in your browser - no data is sent to our servers.