SSL Certificate Decoder

How to Use

1. Copy your PEM-encoded certificate — everything from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----, inclusive.
2. Paste it into the text area and click Decode.
3. Review the decoded fields: subject, issuer, validity period, SANs, public key algorithm, key size, and extensions.
4. For certificate chains, paste the entire chain (multiple PEM blocks) — each certificate is decoded separately with a clear label.

What Are SSL/TLS Certificates?

SSL/TLS certificates are digital documents that bind a cryptographic public key to an organization's identity. When you visit a website over HTTPS, the server presents its certificate to your browser, which verifies the certificate's authenticity against a list of trusted Certificate Authorities (CAs). This process ensures two things: the server is who it claims to be (authentication), and the connection between your browser and the server is encrypted (confidentiality).

Every certificate contains structured data defined by the X.509 standard (RFC 5280). The key fields include the subject (who the certificate is issued to), the issuer (which CA signed it), the validity period (when it becomes active and when it expires), the public key (used for TLS key exchange), and extensions like Subject Alternative Names that list which domain names the certificate covers.

Understanding the PEM Format

PEM is the most widely used certificate encoding format. Under the hood, a PEM file is simply a DER-encoded (binary) certificate that has been Base64-encoded and wrapped with human-readable header and footer lines. The DER binary data follows the ASN.1 (Abstract Syntax Notation One) encoding rules, which define how the certificate fields are structured as nested sequences of typed data.

You can obtain a server's certificate using OpenSSL: openssl s_client -connect example.com:443 -showcerts. This outputs the full certificate chain in PEM format, which you can paste directly into this tool. Alternatively, click the padlock icon in your browser's address bar, view the certificate details, and export it as a PEM or Base64-encoded file.

Certificate Chains Explained

Browsers and operating systems ship with a set of trusted root CA certificates. When a server presents its certificate, the browser builds a chain from the server's certificate up to one of these trusted roots. Intermediate certificates bridge the gap between the server certificate and the root CA. If the chain is incomplete (missing intermediates), browsers may show a trust error even though the server certificate itself is valid.

A typical chain has three certificates: the leaf (server) certificate, an intermediate CA certificate, and the root CA certificate. Some chains are longer, especially for certificates issued by smaller CAs that chain through multiple intermediates. This tool decodes each certificate in the chain separately, making it easy to inspect the full trust path.

Certificate Signature Algorithms

The signature algorithm determines how the CA digitally signs the certificate. SHA-256 with RSA is the most common algorithm in use today. Older certificates may use SHA-1 with RSA, which is deprecated and no longer trusted by modern browsers. Elliptic curve signatures (ECDSA with SHA-256) are increasingly common because they offer equivalent security with smaller keys and faster verification. Ed25519 signatures are the newest option, offering excellent performance and compact signatures.

Common Certificate Issues

• Certificate expired — The current date is past the "Not After" date. Renew the certificate with your CA or use automated renewal via ACME/Let's Encrypt.
• Name mismatch — The domain you are connecting to is not listed in the certificate's Common Name (CN) or Subject Alternative Names (SANs). Reissue the certificate with the correct domain names.
• Incomplete chain — The server is not sending intermediate certificates. Configure your web server to serve the full chain, not just the leaf certificate.
• Self-signed certificate — The certificate is not signed by a trusted CA. This is normal for development environments but will cause browser warnings in production.
• Weak key size — RSA keys under 2048 bits are considered insecure. Modern best practice is 2048-bit RSA or 256-bit ECDSA (P-256).

CSR (Certificate Signing Request) Decoding

This tool also decodes Certificate Signing Requests. A CSR contains the subject information and public key that you want the CA to include in your certificate, along with a signature proving you hold the corresponding private key. CSRs do not contain issuer or validity information — those are set by the CA during issuance. Decode a CSR to verify its contents before submitting it to a CA.

Related Tools

Certificates use Base64 encoding for the PEM format. Verify certificate fingerprints with the Hash Generator. Decode JWT tokens, which also use public key cryptography for signing. Check certificate data programmatically with the JSON Formatter when working with certificate APIs.