How to Decode an SSL Certificate

An SSL certificate is just a file, but it's not one you can read by opening it in a text editor. What you see is a block of Base64-encoded data between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers. Decoding it turns that blob into readable information: who it was issued to, who issued it, when it expires, and what domains it covers. Here's how to do it.

What "Decoding" Actually Means

An SSL certificate is a structured data object defined by the X.509 standard. The actual data is in ASN.1 (Abstract Syntax Notation One) format, which is binary. For transport and storage, this binary data is Base64-encoded and wrapped in PEM format -- the text block you see in .pem and .crt files.

Decoding means converting that Base64 back into structured, human-readable fields. You're not decrypting anything (certificates are public by design). You're just translating the format.

Method 1: Decode with OpenSSL (Command Line)

The fastest way to decode a certificate if you have terminal access.

Decode a PEM file:

openssl x509 -in certificate.pem -text -noout

The -text flag outputs all fields in readable format. The -noout flag suppresses the raw PEM output (so you don't get the encoded blob repeated at the end).

Decode a certificate from a live server:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -text -noout

Extract specific fields only:

# Subject (the entity the cert was issued to)
openssl x509 -in cert.pem -noout -subject

# Issuer (the CA that signed it)
openssl x509 -in cert.pem -noout -issuer

# Validity dates
openssl x509 -in cert.pem -noout -dates

# Subject Alternative Names
openssl x509 -in cert.pem -noout -ext subjectAltName

# Serial number
openssl x509 -in cert.pem -noout -serial

# Fingerprint (SHA-256)
openssl x509 -in cert.pem -noout -fingerprint -sha256

Method 2: Decode with Online Tools

If you don't have OpenSSL installed or prefer a visual interface:

• SSL Shopper Certificate Decoder (sslshopper.com/certificate-decoder.html) -- Paste in PEM content, get a formatted breakdown.
• Certlogik (certlogik.com/decoder) -- Clean interface, shows SANs and chain details.
• Red Kestrel Certificate Decoder -- Parses and displays all X.509 extensions.

Method 3: Decode a CSR (Certificate Signing Request)

When you generate a CSR to request a certificate from a CA, you can decode it the same way to verify the information before submitting:

openssl req -in request.csr -text -noout

This shows the subject information (domain, organization, country) and the public key that will be included in the certificate. Always verify your CSR before submitting it -- a typo in the domain name means you'll get a certificate for the wrong domain.

Understanding Certificate Fields

Here's what each field in a decoded certificate means and why it matters:

Subject

The entity the certificate was issued to. For a DV (Domain Validated) certificate, this is typically just the domain name:

Subject: CN = example.com

For OV and EV certificates, it includes the organization:

Subject: C = US, ST = California, O = Example Inc, CN = example.com

Issuer

The Certificate Authority that signed the certificate:

Issuer: C = US, O = Let's Encrypt, CN = R3

This tells you which CA issued it and which intermediate certificate signed it.

Validity

Not Before: Jan 15 00:00:00 2025 GMT
Not After : Apr 15 23:59:59 2025 GMT

The window during which the certificate is valid. All dates are in UTC.

Subject Alternative Names (SANs)

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com, DNS:api.example.com

This is the definitive list of domains the certificate covers. Modern browsers check SANs, not the CN field. If a domain isn't in the SANs, the certificate isn't valid for it -- even if it matches the CN.

Key Usage and Extended Key Usage

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

These fields define what the certificate is allowed to do. A TLS server certificate should have TLS Web Server Authentication. A code signing certificate would have Code Signing instead. If the key usage doesn't match the intended purpose, the certificate will be rejected.

Basic Constraints

X509v3 Basic Constraints: critical
    CA:FALSE

Tells you whether this is a CA certificate (can sign other certificates) or an end-entity/leaf certificate (can't). Your server's certificate should always say CA:FALSE.

Authority Information Access

Authority Information Access:
    OCSP - URI:http://ocsp.example.com
    CA Issuers - URI:http://certs.example.com/intermediate.pem

The OCSP URI is where browsers check if the certificate has been revoked. The CA Issuers URI is where the intermediate certificate can be downloaded (this is how Chrome can sometimes fix incomplete chains automatically).

Signature Algorithm

Signature Algorithm: sha256WithRSAEncryption

The algorithm used to sign the certificate. SHA-256 is the current standard. SHA-1 has been deprecated and is rejected by modern browsers. ECDSA signatures (like ecdsa-with-SHA256) are becoming more common and are faster than RSA.

Public Key

Public Key Algorithm: rsaEncryption
    RSA Public-Key: (2048 bit)

The algorithm and key size. RSA 2048-bit is the minimum. RSA 4096 and ECDSA P-256 are common for higher security. The public key in the certificate must correspond to the private key on your server -- if they don't match, the TLS handshake will fail.

Certificate Formats: PEM vs. DER vs. PKCS

Certificates come in several file formats. Understanding the differences helps you decode the right way:

PEM is the most common format on Linux/Apache/Nginx. It's the Base64 text block with header and footer lines.

DER is the raw binary ASN.1 encoding. Common on Windows and Java systems. You can convert between them:

# PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.der

# DER to PEM
openssl x509 -in cert.der -inform DER -outform PEM -out cert.pem

PKCS#7 bundles multiple certificates (typically the chain) without a private key. Used when you need to export or import a certificate chain.

PKCS#12 bundles the certificate, chain, and private key together in one encrypted file. Common for Windows IIS and for transferring certificates between systems. You'll need the password to decode it:

openssl pkcs12 -in cert.pfx -nokeys -clcerts -out cert.pem

When to Decode a Certificate

You'll typically decode certificates when:

• Debugging SSL errors -- Check if the SANs match, the chain is correct, or the dates are valid.
• Verifying a new certificate before deploying it -- Make sure the CA issued it for the right domains.
• Auditing your infrastructure -- Inventory all certificates, their issuers, and expiry dates.
• Comparing certificates -- Confirm that a renewed certificate has the same SANs as the one it replaces.

Decoding is a diagnostic tool. For ongoing awareness of your certificates' status, pair it with monitoring that checks continuously and alerts you when something changes.

---

A certificate you can't read is a certificate you can't trust. Decode first, deploy second.