What information can I find in a decoded X.509 certificate?

What a decoded X.509 certificate contains

A decoded X.509 certificate exposes three groups of information: identity fields (subject, issuer, serial number), a validity window (Not Before / Not After), and cryptographic material (the public key, signature algorithm, and the CA's signature), plus a set of v3 extensions that govern how the certificate may be used. The extensions are where the operationally important detail lives — the Subject Alternative Name lists every hostname the certificate is valid for, Key Usage and Extended Key Usage restrict what the key may do, and the AIA and CRL Distribution Points tell you where to check revocation. Everything above the signature line is defined by RFC 5280 as the tbsCertificate ("to be signed") body; the CA signs a hash of exactly that body, which is why altering any single field breaks the certificate.

That is the summary a search engine can give you. What it can't show you is where each field sits in the structure, which ones actually matter when you are debugging a broken TLS handshake, and which values are red flags in 2026. The diagram below maps the anatomy of a real certificate, and the tables further down turn each field into a "is this good or bad?" judgment you can apply to your own decoded output.

The signature covers only the tbsCertificate — change one byte of any field and every client rejects it.

X.509 certificates are the foundation of public key infrastructure (PKI) and HTTPS security. They contain cryptographic information proving that a server is who it claims to be. Understanding what information X.509 certificates contain and how to interpret that information is essential for security professionals, system administrators, and anyone managing HTTPS infrastructure.

An X.509 certificate is a digital document that binds a public cryptographic key to a real-world identity. It's signed by a trusted Certificate Authority (CA), which vouches that the certificate holder is legitimately entitled to use the associated private key.

Certificate Structure and Main Fields

Subject: The entity the certificate belongs to. For a website certificate, this includes:

• Common Name (CN): The fully qualified domain name (example.com)
• Organization (O): Company name
• Organizational Unit (OU): Department or division
• Locality (L): City
• State (ST): State or province
• Country (C): Country code (US, UK, etc.)

Example:

Subject:
  Common Name: example.com
  Organization: Example, Inc.
  Country: US
  State: California
  Locality: San Francisco

Issuer: The Certificate Authority that issued and signed the certificate. Same structure as Subject.

Issuer:
  Common Name: Let's Encrypt Authority X3
  Organization: Let's Encrypt
  Country: US

Validity Dates:

• Not Before: When the certificate becomes valid
• Not After: When the certificate expires

Not Before: Jan 15, 2024
Not After: Jan 14, 2025

This defines the certificate's valid period. Any time outside this range, the certificate is invalid.

Public Key Information:

• Key Algorithm: RSA, ECDSA, or other
• Key Size: 2048-bit, 4096-bit, etc.

Public Key Algorithm: RSA
Public Key Size: 2048 bits

The public key is used by clients to verify the certificate and establish encrypted connections.

Serial Number: A unique identifier assigned by the CA. No two certificates from the same CA should have the same serial number.

Serial Number: 0x1234567890ABCDEF

Serial numbers are used for certificate revocation tracking.

Signature Algorithm: The algorithm used to sign the certificate:

• SHA-256 with RSA
• SHA-384 with ECDSA
• SHA-512 with RSA

Example:

Signature Algorithm: SHA-256 with RSA

Signature Value: The actual cryptographic signature proving the CA endorsed this certificate.

Extensions: The Detailed Information

X.509 certificates include extensions providing detailed information about certificate usage and limitations.

Subject Alternative Name (SAN): Modern websites use SAN instead of just the CN field. It lists all domains the certificate covers:

Subject Alternative Name:
  DNS: example.com
  DNS: www.example.com
  DNS: mail.example.com
  DNS: *.subdomain.example.com

This allows one certificate to cover multiple domains. Wildcard certificates (*.example.com) cover all subdomains.

Key Usage: Specifies what the certificate can be used for:

• Digital Signature
• Non-Repudiation
• Key Encipherment
• Data Encipherment
• Key Agreement
• Certificate Sign
• CRL Sign
• Encipher Only
• Decipher Only

Example:

Key Usage:
  Digital Signature
  Key Encipherment

This indicates the certificate is for HTTPS (requires digital signature and key encipherment).

Extended Key Usage (EKU): Specifies purposes the certificate can be used for:

• Server Authentication (TLS/SSL)
• Client Authentication
• Code Signing
• Email Protection
• Timestamp Authority
• OCSP Signing

For HTTPS certificates:

Extended Key Usage:
  Server Authentication
  Client Authentication (sometimes)

Certificate Path Length Constraint: For intermediate CAs, limits how many intermediate certificates can appear below this certificate in the chain.

Path Length Constraint: 0

A constraint of 0 means this CA cannot issue intermediate CA certificates, only end-entity certificates.

Authority Key Identifier: Identifies the CA's public key that signed this certificate, useful for certificate chain validation.

Authority Key Identifier: 1234567890ABCDEF...

Subject Key Identifier: Identifies this certificate's public key, used when this certificate becomes a CA.

Subject Key Identifier: FEDCBA0987654321...

Certificate Policies: Identifies policies the CA followed when issuing the certificate:

Certificate Policies:
  Policy: 2.23.140.1.2.1 (EV Certificate)
  Policy: 1.2.3.4.5.6.7.8.9 (Organization-specific policy)

Different policy OIDs indicate different types of validation (DV, OV, EV).

CRL Distribution Points (CDP): URLs where revocation information can be found:

CRL Distribution Points:
  http://crl.example.com/ca.crl

The Certificate Revocation List at this URL lists revoked certificates.

Authority Information Access (AIA): URLs for accessing information about the issuing CA:

Authority Information Access:
  OCSP: http://ocsp.example.com
  CA Issuers: http://ca.example.com/cert.crt

OCSP (Online Certificate Status Protocol) allows real-time revocation checking.

Constraints (Name Constraints, etc.): Limits on how the certificate can be used:

Name Constraints:
  Permitted: .example.com, .subdomain.example.com
  Excluded: .restricted.example.com

This restricts the certificate to certain domain ranges.

Certificate Chain Information

Most HTTPS certificates are part of a chain:

End-Entity Certificate (website)
         ↓
Intermediate CA (issued by Let's Encrypt)
         ↓
Root CA (self-signed, trusted by browsers)

Each certificate is signed by the one above it. Browsers trust root CAs, which validate intermediate CAs, which validate end-entity certificates.

Version Information

The certificate version indicates which format and features are supported:

• Version 1 (X.509 v1): Very old, no extensions
• Version 2 (X.509 v2): Rarely used
• Version 3 (X.509 v3): Modern standard, includes extensions

All modern certificates are v3.

Reading a Decoded Certificate Example

Here's what a decoded certificate looks like:

Certificate:
  Version: 3
  Serial Number: 04:A3:F4:5D:6E:7F:8A:9B
  Signature Algorithm: sha256WithRSAEncryption
  Issuer:
    C = US
    O = Let's Encrypt
    CN = R3
  Validity:
    Not Before: Jan 15 12:34:56 2024 GMT
    Not After: Apr 14 12:34:55 2024 GMT
  Subject:
    CN = example.com
  Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (2048 bit)
  Extensions:
    X509v3 Key Usage: critical
      Digital Signature, Key Encipherment
    X509v3 Extended Key Usage: critical
      TLS Web Server Authentication
    Subject Alternative Name:
      DNS:example.com, DNS:*.example.com
    X509v3 Certificate Policies:
      Policy: 2.23.140.1.2.1 (EV)
    Authority Key Identifier:
      keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

Security Analysis Using Certificate Information

When you decode a certificate, the point is not to read every field — it's to spot the handful of values that indicate a misconfiguration or a genuine risk. Use this table as a triage checklist: find the field in your decoded output, then map its value to a verdict.

Field in decoded output	Good (leave it)	Warning (plan a change)	Bad (fix now)
Signature algorithm	SHA-256 / SHA-384 with RSA or ECDSA	—	SHA-1 or MD5 (browser-distrusted)
Public key	RSA 2048/4096-bit, ECDSA P-256/P-384	RSA 2048 nearing a long lifetime	RSA 1024-bit or smaller
Not After (expiry)	More than 30 days out	Inside 30 days — renew	Already past — TLS fails
Subject Alternative Name	Every hostname you serve is listed	CN present but hostname only in CN	Served hostname missing from SAN
Basic Constraints	CA:FALSE on a leaf certificate	—	CA:TRUE on a leaf (mis-issued)
Extended Key Usage	Contains Server Authentication	Client Auth also present (usually fine)	EKU absent or wrong purpose only
Issuer	A publicly trusted CA in the chain	Unfamiliar but valid CA	Self-signed on a public endpoint

Which one breaks the handshake first? In practice a missing SAN entry and an expired Not After cause the most outages, because both produce an immediate hard failure in every modern browser rather than a warning. Check those two before anything else.

Certificate Expiration: Monitor "Not After" dates to ensure certificates don't expire unexpectedly. A certificate expiring in 30 days needs renewal.

Certificate Validity Period: Longer validity periods (1-3 years) are now deprecated. Modern certificates are valid for shorter periods (3-12 months). Shorter validity means faster key rotation but more administrative overhead.

Key Size Analysis:

• 2048-bit RSA: Currently acceptable
• 4096-bit RSA: More secure but slower
• ECDSA with P-256: Equivalent to 3072-bit RSA
• ECDSA with P-384: Very strong

Weaker keys (1024-bit RSA) are deprecated and untrusted by modern browsers.

Signature Algorithm:

• SHA-256: Modern standard (acceptable)
• SHA-1: Deprecated (should not be used)
• MD5: Completely broken (should never be used)

Old certificates using SHA-1 or MD5 are security risks.

Issuer Reputation: Certain CAs have better reputations:

• Let's Encrypt: Free, trustworthy, popular
• Digicert: Highly trusted, used for high-security applications
• Comodo/Sectigo: Large, widely used
• Self-signed: Only acceptable for internal use

Certificates from unknown or disreputable CAs are suspicious.

Subject Alternative Names: If the certificate lists many domains, it's a multi-domain or wildcard certificate. Verify all listed domains are controlled by the certificate owner.

Certificate Transparency Logs

Modern certificates are logged in Certificate Transparency (CT) logs. These logs provide records of all publicly issued certificates, preventing unauthorized issuance.

Certificate information includes:

• CT Log Entry ID
• Timestamp
• Which CT logs included this certificate

You can search CT logs to see all certificates ever issued for a domain.

Tools for Reading Certificates

OpenSSL:

openssl x509 -in certificate.crt -text -noout

Online tools:

• https://www.sslshopper.com/certificate-decoder.html
• https://mxtoolbox.com/ssl.aspx

Browsers: Click the lock icon → Details → Certificate → Certificate Viewer

Conclusion

X.509 certificates contain rich information that reveals details about the server's identity, security practices, and intended usage. By understanding certificate structure, reading all available fields and extensions, and analyzing validity periods, key algorithms, and issuer reputation, security professionals can assess whether a certificate is trustworthy and properly configured. This analysis is essential for identifying misconfigured systems, spotting potential security risks, and ensuring proper certificate management across organizations.