Back to Blog

How to Decode a PEM Certificate (and What Every Field Actually Means)

April 18, 2026 Justin 4 min read
SSL Certificates PEM X.509 Tutorial

A PEM certificate looks like this: a Base64 blob wrapped between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. It is completely opaque until you decode it. Here is what is actually inside and how to read it.

The Two Ways to Decode

Option 1 — Paste it into our decoder. Go to /certdecoder, paste the PEM contents (or upload the file), and everything is parsed instantly. No install, no commands, nothing stored server-side beyond the single decode.

Option 2 — OpenSSL locally. If you have a terminal handy:

openssl x509 -in cert.pem -text -noout

The output is dense. Below is what each section actually tells you.

What the Fields Mean

Subject

The domain (or entity) the certificate was issued for. Look for CN=example.com — that is the common name. Modern browsers ignore CN and use Subject Alternative Names (SANs) instead, so the SAN list is what actually matters.

Subject Alternative Names (SANs)

The list of hostnames the certificate covers. example.com, www.example.com, *.example.com, and so on. If you visit a hostname that is not in this list, the browser will show a mismatch error — even if the DNS points to the right server. This is the field that causes the most "why is my cert broken?" tickets.

Issuer

The Certificate Authority that signed the cert. Let's Encrypt, DigiCert, Sectigo, Google Trust Services, and similar. A cert is only trusted if its issuer is trusted, and trust flows up the chain to a root CA pre-installed in browsers and operating systems.

Validity (Not Before / Not After)

The dates the certificate is valid. Let's Encrypt certs are 90 days by default. Commercial certs are typically 1 year (and capped at 398 days by browser policy). Monitor the "Not After" date — an expired cert means your site goes offline for users who do not ignore browser warnings.

Public Key Algorithm & Size

Usually RSA 2048, RSA 4096, or ECDSA P-256. ECDSA certs are smaller and faster — if you are rotating certs and have a choice, pick ECDSA. RSA 1024 is deprecated and will cause browser warnings.

Signature Algorithm

How the CA signed the cert. Look for sha256WithRSAEncryption or ecdsa-with-SHA384. SHA-1 signatures have been untrusted since 2017 — if you see one, your cert is broken in every modern browser.

Serial Number

A unique identifier assigned by the CA. Useful when reporting a cert to the CA for revocation, or when correlating logs across systems.

Key Usage & Extended Key Usage

What the certificate is allowed to do. A web server cert will list TLS Web Server Authentication. A client cert will list TLS Web Client Authentication. If these are missing or wrong, clients will reject the cert even if everything else looks fine.

PEM vs CRT vs CER vs DER

These are all the same X.509 data in different wrappings.

  • PEM — Base64 encoded with -----BEGIN CERTIFICATE----- headers. Human readable. Default for Apache, Nginx, Let's Encrypt.
  • DER — raw binary X.509. Smaller, not human readable. Default for Java keystores and some Windows tools.
  • CRT / CER — file extensions, not formats. A .crt file might contain PEM or DER depending on how it was exported. If you open it in a text editor and see -----BEGIN, it is PEM. Otherwise it is DER.

Our certificate decoder accepts all of them.

Is It Safe to Paste My Cert Online?

Yes. Public certificates contain no secret information — they are designed to be handed out to every browser that connects to your server. The part that must stay private is the private key, which lives in a separate file (usually .key or privkey.pem) and is never embedded in the cert itself.

Never paste a private key into any online tool. If a file starts with -----BEGIN PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY-----, that is the secret half. Keep it on disk.

What About the Full Chain?

A PEM file often contains multiple certificates — your leaf cert plus one or more intermediates. Our decoder parses each one individually. If you want to validate the full trust path (leaf → intermediates → root, with CRL checks), use the Certificate Chain Checker instead. Missing intermediates is the most common SSL misconfiguration in production — browsers cache intermediates and hide the problem, but API clients and mobile apps will fail with trust errors.

Paste any PEM, CRT, CER, or X.509 certificate into our decoder and you will see every field parsed in under a second. No signup, no logging, no data retention.