X.509 Certificates Explained: How to Read and Inspect SSL Certificate Details

Every HTTPS connection starts with your browser inspecting the server's SSL/TLS certificate. Understanding what's inside that certificate — and how to read it — is essential for developers and sysadmins deploying secure services.

What is an X.509 Certificate?

An X.509 certificate is a standardized digital document that binds a public key to an identity (a domain name, organization, or person). It is signed by a Certificate Authority (CA) — a trusted third party that vouches for the identity claim.

When your browser connects to https://example.com, the server presents its X.509 certificate. Your browser checks: Does this certificate say it belongs to example.com? Is it signed by a CA I trust? Has it expired? If all three pass, the connection proceeds.

Certificate Structure

An X.509 certificate contains several fields. Here's what each one means:

Subject

Identifies who the certificate was issued to. For a website, this is the domain owner:

Subject:
  CN = example.com              ← Common Name (domain)
  O  = Example Corp             ← Organization
  OU = IT Department            ← Organizational Unit
  L  = Bangkok                  ← City/Locality
  ST = Bangkok                  ← State/Province
  C  = TH                       ← Country (ISO 2-letter code)

For a DV (Domain Validated) certificate, only the CN is verified. For OV (Organization Validated) and EV (Extended Validation), the O and other fields are also verified by the CA.

Issuer

The CA that signed the certificate. Same DN format as Subject:

Issuer:
  CN = R11
  O  = Let's Encrypt
  C  = US

For self-signed certificates, the Issuer and Subject are identical — the certificate signed itself.

Validity Period

Not Before: 2025-01-01 00:00:00 UTC
Not After:  2025-04-01 23:59:59 UTC

Certificates have an expiry date. Let's Encrypt certificates expire after 90 days. Commercial CA certificates can be valid for up to 1 year (previously 2 years — browsers reduced this limit in 2020).

A certificate used outside its validity window is rejected by browsers, regardless of the signature. Set up auto-renewal (e.g. with certbot) before the expiry date.

Subject Alternative Names (SANs)

SANs list all the domain names the certificate is valid for. Modern certificates use SANs instead of (or in addition to) the CN for domain validation:

Subject Alternative Names:
  DNS: example.com
  DNS: www.example.com
  DNS: api.example.com
  DNS: *.staging.example.com   ← wildcard

Wildcard entries (*.example.com) cover all direct subdomains but not deeper nesting — *.example.com covers www.example.com but not api.v2.example.com.

Public Key Info

Public Key Algorithm: rsaEncryption
RSA Public Key: 2048 bit

The certificate's public key is what browsers use to establish the encrypted session. Key size matters for security: 2048-bit RSA is current standard; 4096-bit is higher security but slower. ECDSA (P-256, P-384) keys are smaller and faster than RSA at equivalent security levels.

Signature Algorithm

Signature Algorithm: sha256WithRSAEncryption

The algorithm the CA used to sign this certificate. sha256WithRSAEncryption is standard. Older certificates used sha1WithRSAEncryption, which is now rejected by browsers.

Fingerprints

SHA-1:   A1:B2:C3:D4:...
SHA-256: 3F:8A:...

Fingerprints are hash digests of the entire certificate. They're used to uniquely identify a specific certificate (e.g. for certificate pinning). SHA-1 fingerprints are shown for legacy compatibility; use SHA-256 for any security purpose.

Reading a Certificate with OpenSSL

# Inspect a certificate file
openssl x509 -in certificate.pem -text -noout

# Check a live server's certificate
openssl s_client -connect example.com:443 -showcerts

# Check expiry date only
openssl x509 -in certificate.pem -noout -dates

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

# Get certificate fingerprint
openssl x509 -in certificate.pem -noout -fingerprint -sha256

Certificate Chain

A single certificate is rarely trusted on its own. Browsers trust a small set of Root CAs. Intermediate certificates chain from the Root CA to the server certificate:

Root CA (trusted by browsers)
  └── Intermediate CA (signed by Root)
        └── Server Certificate (signed by Intermediate)

When deploying an SSL certificate, always include the full chain — the server certificate plus all intermediate certificates. Missing intermediates cause "certificate not trusted" errors on some clients even when it works in Chrome (which fetches missing intermediates automatically).

Common Certificate Errors