X.509 Certificate Decoder

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.

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.

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.

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.

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.

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.

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.