Reading a PEM Certificate: Subject, Issuer, SANs and Expiry

You receive a certificate file in email, a webhook tells you a certificate is expiring, or your load balancer rejects a certificate you just installed. You open the .pem file in a text editor and see a block of base64 between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. It is not readable by eye. What does it actually contain?

The PEM Certificate Inspector decodes any PEM certificate in your browser and shows every field clearly. Here is what you are looking at.

What a PEM file is

PEM (Privacy-Enhanced Mail, now a misnomer) is a container format: base64-encoded DER (Distinguished Encoding Rules) binary data, wrapped in ASCII armor. The base64 block encodes a single DER-encoded X.509 certificate.

The header tells you what the block contains:

-----BEGIN CERTIFICATE-----
...base64...
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE REQUEST-----
...base64...
-----END CERTIFICATE REQUEST-----

-----BEGIN RSA PRIVATE KEY-----
...base64...
-----END RSA PRIVATE KEY-----

BEGIN CERTIFICATE is the server or client certificate. BEGIN CERTIFICATE REQUEST is a CSR (Certificate Signing Request). BEGIN RSA PRIVATE KEY is a private key. Confusing them is a common mistake.

The key fields inside an X.509 certificate

Subject — who this certificate identifies. A series of key=value pairs in Distinguished Name order:

C=US, ST=California, L=San Francisco, O=Acme Corp, CN=*.acme.com

C = Country, ST = State, L = Locality (city), O = Organization, OU = Organizational Unit, CN = Common Name. The CN is the hostname in most TLS certificates.

Issuer — who signed and issued this certificate. The chain of trust follows issuers: your server certificate is issued by an Intermediate CA, which is issued by a Root CA (in your OS or browser trust store).

C=US, O=DigiCert Inc, CN=DigiCert SHA2 Extended Validation Server CA

Validity period — Not Before and Not After. The certificate is valid only within this window. A certificate expiring is one of the most common causes of production outages. Browser clients reject expired certificates.

Subject Alternative Names (SANs) — this is the field that actually controls which hostnames the certificate is valid for. The Common Name is largely legacy.

DNS:*.acme.com
DNS:acme.com
DNS:www.acme.com
IP:192.0.2.1

If a browser connects to api.acme.com but the SAN list only contains *.acme.com, it is valid. If it connects to different.com, it is not — even if different.com appears in the CN.

This is why SANs matter more than CN. Many older certificates have CN=example.com but no SANs. Modern browsers (Chrome since 2017) ignore the CN for hostname validation and require SANs.

Key Usage and Extended Key Usage

These fields declare what the certificate is authorized to do:

Key Usage:
  Digital Signature
  Key Encipherment

Extended Key Usage:
  TLS Web Server Authentication
  TLS Web Client Authentication

A server certificate with only Digital Signature key usage (but no Key Encipherment) cannot be used for TLS key exchange. A code signing certificate has Digital Signature but not Key Encipherment. Using the wrong certificate type causes confusing errors.

The certificate chain

A typical TLS connection presents not one certificate but a chain:

Your server certificate
    → Intermediate CA (signed your cert)
        → Root CA (signed the intermediate, in browser trust store)

The server should present the full chain (excluding the root, which is already trusted). If the chain is incomplete, the client attempts to build it using cached intermediates or AIA (Authority Information Access) URLs — which can fail in restricted network environments.

The PEM Certificate Inspector parses the chain and shows each certificate in the chain with its subject, issuer, validity, and SANs. An incomplete chain shows only one certificate.

Fingerprints and the serial number

Each certificate has a unique serial number (not globally unique — it is unique within a given CA's scope) and a SHA-1 and SHA-256 fingerprint. The fingerprint is how you identify a certificate definitively:

SHA-256: 5E:CF:09:88:BF:74:22:4A:E2:1E:8B:3D:8F:68:3F:4E:5D:8A:7C:2F:2A:...

If you see a fingerprint in documentation or an alert, it is an unambiguous identity for this exact certificate — useful when multiple certificates are deployed and you need to identify which one is causing an issue.

Decoding in practice

# OpenSSL (installed on most servers)
openssl x509 -in server.pem -text -noout

# Check expiry
openssl x509 -in server.pem -noout -dates

# Check SANs
openssl x509 -in server.pem -noout -ext subjectAltName

# Check issuer
openssl x509 -in server.pem -noout -issuer

For quick analysis without installing OpenSSL, paste a PEM block into the PEM Certificate Inspector — it decodes all fields, shows the full chain, and flags expiry and SAN issues.

What PEM certificates do not contain

A PEM certificate does not contain the private key (unless it is a combined file — a bad practice). It does not contain revocation status (CRL or OCSP responses are separate). It does not contain the full chain by default — only the leaf certificate. If you received a certificate that works in some clients but not others, check that you included the intermediate certificate(s) in the chain.

For checking live servers, the SSL Certificate Checker fetches the certificate from a URL. For generating a CSR to submit to a CA, the CSR Decoder can parse and validate your request before submission.