How to Decode and Inspect SSL Certificates & CSRs (X.509 Guide)

What is an X.509 certificate and CSR?

When securing web infrastructure, you routinely handle cryptographic blocks formatted as Base64-encoded strings wrapped in PEM headers:

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIUQZ...
-----END CERTIFICATE-----

To human eyes, this ciphertext is unreadable. However, packed inside this ASN.1 structured container are critical public key infrastructure (PKI) parameters governed by the ITU-T X.509 standard.

Similarly, before a Certificate Authority (CA like DigiCert, Sectigo, or Let's Encrypt) can issue an SSL/TLS certificate, you must generate a CSR (Certificate Signing Request):

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkG...
-----END CERTIFICATE REQUEST-----

A CSR contains your organization's identity, the exact domain names to be secured, and your public key, digitally signed by your private key to prove ownership.

Why you should inspect certificates before deployment

Deploying an uninspected certificate into production often leads to catastrophic outages or unexpected security failures:

1. Common Name & SAN Mismatches: If you order an SSL certificate for yourdomain.com but forget to include the Subject Alternative Name (SAN) for www.yourdomain.com, visitors to the www address will see alarming NET::ERR_CERT_COMMON_NAME_INVALID warnings.
2. Weak Public Key Sizes: Modern security compliance (PCI-DSS, NIST) mandates at least 2048-bit RSA or 256-bit ECDSA keys. Generating a certificate with a legacy 1024-bit key will cause payment gateways and security scanners to fail your site.
3. Unexpected Expiration Timestamps: Verifying the Not Before and Not After timestamps ensures your certificate is already valid and will not expire unexpectedly during an upcoming promotional campaign.

How to decode certificates online and via OpenSSL

Method 1: Client-Side Browser Decoding (No Private Data Leaves Your Device)

Use our free PEM Certificate & CSR Decoder.

Paste your raw certificate, CSR, or public key block into the tool. The decoder parses the cryptographic fields in memory inside your browser and presents a clean, readable breakdown:

• Subject & Issuer details (Common Name, Organization, Country).
• Subject Alternative Names (SANs) list.
• Key algorithm (RSA / ECDSA) and key size (2048-bit, 4096-bit).
• Validity dates and active countdown.
• SHA-256 and SHA-1 cryptographic fingerprints.

Method 2: Inspecting via OpenSSL in your terminal

If you are logged into a Linux server via SSH, you can inspect .pem or .crt files using OpenSSL commands:

# Decode an X.509 Certificate completely:
openssl x509 -in certificate.crt -text -noout

# View only the Subject and Expiry Dates:
openssl x509 -in certificate.crt -noout -subject -dates

# Inspect Subject Alternative Names (SANs):
openssl x509 -in certificate.crt -noout -ext subjectAltName

# Calculate the SHA-256 Fingerprint:
openssl x509 -in certificate.crt -noout -fingerprint -sha256

Anatomy of a certificate: Subject, Issuer, and SANs

When inspecting an X.509 certificate, four primary sections define its cryptographic authority:

1. Subject (Who owns the certificate?)

Identifies the entity that holds the private key:

• CN (Common Name): The primary fully qualified domain name (e.g. yourdomain.com).
• O (Organization): The registered legal company name (present in OV and EV certificates).
• C (Country): Two-letter ISO country code (e.g. US, GB, DE).

2. Issuer (Who vouched for this certificate?)

Identifies the Certificate Authority that verified the domain and signed the certificate (e.g. Let's Encrypt Authority X3, DigiCert Global Root CA).

3. Subject Alternative Names (SANs)

In modern web browsers, the CN field is deprecated for host validation. Browsers rely exclusively on the subjectAltName extension. A single certificate can protect dozens of domains:

DNS:yourdomain.com, DNS:www.yourdomain.com, DNS:api.yourdomain.com

4. Public Key & Signature Algorithm

Specifies the mathematical algorithm used for key exchange and authentication:

• RSA 2048-bit or RSA 4096-bit
• ECDSA (Elliptic Curve) with P-256 or P-384 curve
• Signature Algorithm: sha256WithRSAEncryption (Legacy SHA-1 signatures are rejected by all modern browsers).

Verifying a CSR before ordering an SSL certificate

Before paying a commercial Certificate Authority or submitting an order, decode your CSR to verify that you did not make a typo in your domain name or organization details:

openssl req -in request.csr -text -noout -verify

Verify that:

1. The Subject contains the exact domain name you intend to secure.
2. The Public Key Algorithm matches your intended specifications (e.g., 2048-bit minimum).
3. The self-signature verifies with verify OK.

You can also paste the CSR block into our free PEM Certificate & CSR Decoder for an immediate visual validation.