Skip to content

Certificate Anatomy

Why This Matters

For executives: Understanding certificate structure isn't just technical detail - it's critical for security decisions. When vendors claim "compliant certificates" or auditors question your PKI, knowing what's actually IN certificates helps you ask the right questions and avoid security theater.

For security leaders: Certificate misconfigurations cause 94% of certificate-related outages. Understanding certificate anatomy helps you identify misconfigured Key Usage extensions, missing Subject Alternative Names, and improper Basic Constraints that create security vulnerabilities or operational failures.

For engineers: You need to understand certificate anatomy when debugging "certificate validation failed" errors, implementing certificate generation, or troubleshooting SSL/TLS issues. Knowing what's in certificates and why each field matters is foundational to PKI work.

Common scenario: Your application works locally but fails in production with "certificate validation error." You need to understand certificate extensions (Key Usage, Extended Key Usage, Subject Alternative Name) to diagnose why validation succeeds in one environment but fails in another.

TL;DR: X.509 certificates contain a public key, identity information, validity period, and extensions, all signed by a Certificate Authority. Understanding certificate structure is essential for troubleshooting, security analysis, and proper implementation.

Overview

An X.509 certificate is a structured data format defined by RFC 52801 that binds a public key to an identity through a digital signature. Think of it as a tamper-evident digital passport that contains identification information, a cryptographic key, usage constraints, and an authoritative signature.

Certificates are encoded using ASN.1 (Abstract Syntax Notation One) and typically represented in DER (binary) or PEM (base64-encoded) format. While the encoding is complex, the logical structure follows a clear hierarchy designed for machine parsing and cryptographic verification.

Understanding certificate anatomy is critical for: validating trust chains, diagnosing SSL/TLS errors, implementing certificate generation, configuring proper extensions, and performing security assessments.

Related Pages: What Is Pki, X509 Standard, Trust Models, Chain Validation Errors

Key Concepts

Certificate Structure Overview

An X.509 v3 certificate consists of three main components:

  1. TBS Certificate (To Be Signed): The core certificate data
  2. Signature Algorithm: The algorithm used by the CA to sign
  3. Signature Value: The actual cryptographic signature

The TBS Certificate contains all the certificate information. The CA signs this section, allowing relying parties to verify the entire certificate hasn't been tampered with.

TBS Certificate Fields

Version

Indicates the X.509 version (1, 2, or 3). Modern certificates must be version 3 to support extensions, which are required for internet PKI according to CA/Browser Forum requirements2.

Version: 3 (0x2)

Serial Number

A unique identifier assigned by the issuing CA. According to RFC 5280, serial numbers must be unique within a CA and should be unpredictable to prevent certain attacks. Modern CAs use at least 64 bits of entropy3.

Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94

Security Note: Predictable serial numbers historically enabled attacks where attackers could pre-compute hash collisions for certificates the CA would issue next.

Signature Algorithm Identifier

Specifies the algorithm used to sign the certificate. Must match the signature algorithm field at the certificate end. Common values include:

  • sha256WithRSAEncryption - RSA with SHA-256 (most common)
  • ecdsa-with-SHA256 - ECDSA with SHA-256 (increasingly common)
  • sha384WithRSAEncryption - RSA with SHA-384
  • ecdsa-with-SHA384 - ECDSA with SHA-384

Older algorithms like MD5 and SHA-1 are deprecated due to collision vulnerabilities4.

Issuer Distinguished Name

The identity of the Certificate Authority that issued this certificate. Uses X.500 Distinguished Name format with hierarchical components:

Issuer: C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1

Common components:

  • C (Country): Two-letter country code
  • O (Organization): Legal entity name
  • OU (Organizational Unit): Department (deprecated in modern certs)
  • CN (Common Name): The CA name

Validity Period

Specifies when the certificate becomes valid and when it expires. Certificates must not be trusted outside this period.

Validity
    Not Before: Nov  1 00:00:00 2024 GMT
    Not After : Nov  1 23:59:59 2025 GMT

Important: As of 2020, publicly-trusted TLS certificates are limited to 398 days maximum validity2. Internal PKI can use longer periods, but shorter lifespans improve security through forced rotation.

Subject Distinguished Name

The identity of the entity this certificate represents (server, person, device, organization).

Subject: C=US, ST=California, L=San Francisco, O=Example Corp, CN=www.example.com

For TLS server certificates, the Common Name (CN) historically contained the domain name, but this is now deprecated in favor of the Subject Alternative Name extension.

Subject Public Key Info

Contains the public key and its algorithm. This is the key that will be used for encryption or signature verification.

Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
        Public-Key: (2048 bit)
        Modulus: 00:c3:e5:...
        Exponent: 65537 (0x10001)

For RSA keys, 2048 bits is the current minimum for publicly-trusted certificates2. NIST recommends 2048-bit RSA or 256-bit ECDSA as secure through 20305.

X.509 Extensions

Extensions provide additional capabilities beyond the basic certificate fields. Version 3 certificates introduced extensions, which are now essential for modern PKI.

Critical vs Non-Critical

Extensions can be marked as:

  • Critical: Must be processed and understood by the relying party. If unknown, the certificate must be rejected.
  • Non-Critical: Can be safely ignored if not understood.
X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA:FALSE
    X509v3 Key Usage: critical
        Digital Signature, Key Encipherment

Essential Extensions

Subject Alternative Name (SAN): Specifies additional identities bound to this certificate. For TLS certificates, this is where domain names must appear (not in CN).

X509v3 Subject Alternative Name:
    DNS:www.example.com, DNS:example.com, DNS:*.example.com

Can include:

  • DNS names
  • IP addresses
  • Email addresses
  • URIs
  • Other name forms

Key Usage: Defines cryptographic operations this key can perform. This is critical for security—prevents misuse of keys.

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment

Common values:

  • Digital Signature: For signing data
  • Key Encipherment: For encrypting keys (RSA key exchange)
  • Key Agreement: For key agreement protocols (ECDH)
  • Certificate Sign: For CA certificates
  • CRL Sign: For signing CRLs

Extended Key Usage (EKU): Specifies application-specific purposes.

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

Common OIDs:

  • serverAuth (1.3.6.1.5.5.7.3.1): TLS server certificates
  • clientAuth (1.3.6.1.5.5.7.3.2): TLS client certificates
  • codeSigning (1.3.6.1.5.5.7.3.3): Code signing
  • emailProtection (1.3.6.1.5.5.7.3.4): S/MIME email
  • timeStamping (1.3.6.1.5.5.7.3.8): Trusted timestamping

Basic Constraints: Indicates if this is a CA certificate and the maximum path length.

X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
  • CA:TRUE: This is a CA certificate that can issue other certificates
  • CA:FALSE: End-entity certificate (leaf certificate)
  • pathlen: Maximum number of intermediate CAs that can follow in chain

Authority Key Identifier (AKI): Identifies the CA's key that signed this certificate. Helps with chain building.

X509v3 Authority Key Identifier:
    keyid:B7:6B:A2:EA:A8:AA:84:8C:79:EA:B4:DA:0F:98:B2:C5:95:76:B9:F4

Subject Key Identifier (SKI): Unique identifier for this certificate's public key. Used in chain validation.

X509v3 Subject Key Identifier:
    A1:2F:3E:4D:5C:6B:7A:8E:9F:A0:B1:C2:D3:E4:F5:06

Authority Information Access (AIA): URLs for obtaining CA certificate and OCSP responder location.

Authority Information Access:
    CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1-1.crt
    OCSP - URI:http://ocsp.digicert.com

CRL Distribution Points: Where to obtain the Certificate Revocation List.

X509v3 CRL Distribution Points:
    Full Name:
      URI:http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1-4.crl

Certificate Policies: Indicates which policies govern certificate issuance and use.

X509v3 Certificate Policies:
    Policy: 2.23.140.1.2.2
    Policy: 2.16.840.1.114412.1.1

Common OIDs:

  • 2.23.140.1.2.2: Domain Validated (DV)
  • 2.23.140.1.2.1: Organization Validated (OV)
  • 2.23.140.1.1: Extended Validation (EV)

Certificate Transparency SCTs: Signed Certificate Timestamps proving the certificate was logged to CT logs6.

CT Precertificate SCTs:
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : B7:3E:FB:...
        Timestamp : Nov  1 12:45:32.456 2024 GMT

Decision Framework

When examining certificates, focus on these critical fields first:

For troubleshooting: 1. Validity period - Most common issue: expired certificates 2. Subject Alternative Name - Must match requested hostname for TLS 3. Key Usage - Must match intended use (signing vs. encryption) 4. Certificate chain - Check Authority Key Identifier matches parent's Subject Key Identifier

For security assessment: 1. Basic Constraints - Verify end-entity certs have CA:FALSE 2. Extended Key Usage - Verify appropriate restrictions (serverAuth for TLS servers) 3. Serial number - Check for sufficient entropy (modern CAs use 64+ bits) 4. Signature algorithm - Verify SHA-256 or better (no MD5, SHA-1)

Red flags indicating problems: - End-entity certificate with CA:TRUE (can issue certificates inappropriately) - Missing Subject Alternative Name on TLS certificates (will fail in modern browsers) - Key Usage doesn't match certificate purpose (e.g., encryption-only key used for signing) - Certificate validity >398 days for publicly-trusted certificates (violates CA/B Forum requirements) - Weak signature algorithms (MD5, SHA-1) - Predictable serial numbers (security vulnerability)

Common mistakes when generating certificates: - Putting hostname only in Common Name, not Subject Alternative Name - Not marking Basic Constraints as critical for CA certificates - Using overly permissive Extended Key Usage (no restrictions) - Not including Authority Information Access (breaks OCSP validation) - Copy/paste existing certificates without understanding field requirements

Practical Guidance

Examining Certificates

Use OpenSSL to decode and examine certificates:

# View certificate in text format
openssl x509 -in certificate.pem -text -noout

# View certificate from a server
openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -text

# Check specific fields
openssl x509 -in cert.pem -noout -subject
openssl x509 -in cert.pem -noout -dates
openssl x509 -in cert.pem -noout -ext subjectAltName

Validating Certificate Structure

Check for required extensions:

  • TLS server certs must have: SAN, Key Usage, Extended Key Usage
  • CA certs must have: Basic Constraints (CA:TRUE), Key Usage (Certificate Sign)

Verify critical extensions:

  • Unknown critical extensions must cause validation failure
  • Key Usage must match intended purpose

Validate against CA/B Forum requirements (for publicly-trusted certs):

  • Maximum 398 day validity
  • No OU field in subject (deprecated)
  • SAN must contain all domain names
  • Must include Certificate Transparency SCTs

Common Certificate Issues

Missing SAN: Older certificates relied on CN for domain name. Modern browsers require SAN.

Incorrect Key Usage: Certificate used for purpose not specified in Key Usage/EKU extensions.

Chain building failures: Missing or incorrect AKI/SKI, preventing proper chain construction.

Expired intermediate CA: Even if leaf certificate valid, expired intermediate breaks chain.

Security Considerations

Extension Misuse

Improperly configured extensions can create security vulnerabilities:

  • Missing Key Usage constraints: Allows key misuse (e.g., signing certificate used for encryption)
  • Overly permissive EKU: Certificate usable for unintended purposes
  • Incorrect Basic Constraints: End-entity certificate marked as CA, allowing certificate issuance

Serial Number Entropy

Serial numbers must be unpredictable. Predictable serials enabled MD5 collision attacks where attackers pre-computed rogue CA certificates7.

Subject Name Validation

For TLS, only SAN matters for hostname validation. CN is ignored by modern browsers. Attackers exploited this by getting certificates with legitimate-looking CN but malicious SAN.

Real-World Examples

Case Study: Microsoft Weak Serial Number Generation (2012)

Microsoft's CA generated predictable serial numbers, allowing attackers to potentially create hash collision attacks. This was disclosed and fixed before exploitation, demonstrating the importance of proper entropy in certificate generation.

Key Takeaway: Every certificate field has security implications. Serial number generation must use cryptographically secure random number generators.

Case Study: Subject Alternative Name Transition

The deprecation of Common Name for hostname validation caused significant operational issues as organizations discovered certificates that worked in OpenSSL but failed in browsers. This highlighted the importance of understanding certificate structure and validation requirements.

Key Takeaway: Standards evolve. Certificate generation must follow current best practices, not legacy behaviors.

Lessons from Production

What We Learned at Vortex (Subject Alternative Name Migration)

When Vortex migrated to Kubernetes with automated certificate management, we initially generated certificates with hostnames only in Common Name (CN), not Subject Alternative Name (SAN). This worked in testing but failed in production:

Problem: Certificates worked in curl, failed in browsers

  • OpenSSL-based tools (curl, wget) validated certificates successfully
  • Chrome and Firefox rejected certificates with "hostname mismatch"
  • Developers confused: "It works on my machine!"

Root cause: Modern browsers ignore Common Name entirely for hostname validation - only SAN matters. Our certificate generation used legacy patterns that no longer met browser requirements.

What we did: - Updated certificate generation to always include SAN extension - Migrated all hostnames from CN to SAN (CN kept for compatibility but not relied upon) - Added validation in CI/CD to reject certificates without SAN - Documented browser requirements for team

Warning signs you're heading for same mistake: - Certificates generated using old templates or copy/paste from legacy examples - Testing only with command-line tools, not actual browsers - Assuming "certificate works in OpenSSL" means it's standards-compliant - Not validating certificate generation against current CA/B Forum requirements

What We Learned at Nexus (Key Usage Extension Misconfigurations)

Nexus implemented certificate-based authentication for trading systems. Initial certificates had incorrect Key Usage extensions:

Problem: Certificates accepted in development, rejected in production

Development environment had lenient validation. Production environment (configured per compliance requirements) strictly enforced Key Usage.

Root cause: Certificates generated without Key Usage extension (not marked critical). When used for both: - mTLS client authentication (requires "Digital Signature") - TLS server authentication (requires "Key Encipherment" for RSA)

Some systems required Key Usage to be present and critical per policy.

What we did: - Defined certificate profiles for different use cases: - Client authentication: Digital Signature only - Server authentication: Digital Signature + Key Encipherment - CA certificates: Certificate Sign + CRL Sign - Marked Key Usage as critical on all certificates - Implemented certificate validation before deployment - Added pre-deployment testing with production-equivalent validation

Warning signs you're heading for same mistake: - "Works everywhere except production" - indicates environment-specific validation - Copy/pasting certificate configurations without understanding extensions - Not testing certificate validation with actual client/server software - Assuming "certificate validates" without knowing what's being validated

What We Learned at Apex Capital (Certificate Chain Building Failures)

Apex Capital deployed new intermediate CA certificates. Services intermittently failed TLS validation:

Problem: Certificate validation failures were non-deterministic

  • Same certificate worked sometimes, failed other times
  • Error: "unable to get local issuer certificate"
  • Engineers couldn't reproduce consistently

Root cause: Missing Subject Key Identifier (SKI) / Authority Key Identifier (AKI) in certificates. Some TLS implementations cached intermediate certificates, others didn't. When intermediate wasn't cached, chain building failed because client couldn't determine which cached intermediate to use.

What we did: - Regenerated all certificates with proper SKI/AKI - Ensured AKI in child certificate matched SKI in parent - Implemented automated chain validation before certificate deployment - Added monitoring for "missing intermediate certificate" errors

Warning signs you're heading for same mistake: - Intermittent certificate validation failures - Works on first connection, fails on subsequent connections (or vice versa) - Different behavior across TLS implementations - Missing or incorrect SKI/AKI in certificates

Business Impact

Cost of getting this wrong: Certificate misconfigurations cause operational outages and security vulnerabilities. Vortex's SAN migration cost 2 weeks of engineering time debugging "works in dev, fails in production" issues. Nexus's Key Usage problems delayed trading system launch by 6 weeks (regulatory approval required re-validation). Apex Capital's chain building failures caused intermittent customer-facing outages costing $50K+ in SLA credits.

Value of getting this right: Understanding certificate anatomy enables: - Rapid troubleshooting: Identify misconfiguration in minutes instead of days - Security assessment: Spot vulnerabilities in certificate generation before deployment - Vendor validation: Ask informed questions about PKI products and services - Compliance: Ensure certificates meet regulatory requirements (CA/B Forum, NIST, FIPS) - Operational excellence: Generate correct certificates first time, avoiding costly rework

Strategic capabilities: Certificate anatomy knowledge is foundational for: - Implementing certificate automation (need to know what to automate) - Security incident response (analyze compromised certificates) - Vendor selection (evaluate certificate generation capabilities) - Compliance audits (demonstrate understanding of PKI security controls)

Executive summary: Certificate anatomy isn't just technical detail - it's operational risk management. Misconfigurations cause outages, delay projects, and create security vulnerabilities. Investment in understanding certificate structure prevents expensive mistakes.

When to Bring in Expertise

You can probably handle this yourself if: - Standard certificate use cases (TLS server, basic authentication) - Using well-tested certificate generation tools (cert-manager, Let's Encrypt, established CAs) - Small scale (<100 certificates) - Time to learn through trial and error

Consider getting help if: - Complex certificate requirements (custom extensions, specialized use cases) - Compliance requirements with specific certificate profile needs - Migrating certificate generation to new platform - Debugging persistent certificate validation issues

Definitely call us if: - Certificate misconfigurations causing production outages - Regulatory audit findings related to certificate generation - Implementing custom CA with specific certificate profile requirements - Need expert certificate forensics after security incident

We've debugged certificate issues at Vortex (SAN migration affecting 15,000 services), Nexus (Key Usage problems in compliance-critical environment), and Apex Capital (chain building affecting customer transactions). We can identify certificate misconfigurations in minutes that might take days to debug without expertise.

Further Reading

Essential Resources

Advanced Topics

References

Change History

Date Version Changes Reason
2025-11-09 1.0 Initial creation Foundational certificate structure documentation

Quality Checks:

  • [x] All claims cited from authoritative sources
  • [x] Cross-references validated
  • [x] Practical guidance included
  • [x] Examples are current and relevant
  • [x] Security considerations addressed

  1. Cooper, D., et al. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile." RFC 5280, May 2008. Rfc-editor - Rfc5280 ↩

  2. CA/Browser Forum. "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates," Version 2.0.0, November 2023. Cabforum - Baseline Requirements Documents ↩↩↩

  3. CA/Browser Forum Baseline Requirements, Section 7.1 - Certificate Profile. ↩

  4. NIST. "Transitioning the Use of Cryptographic Algorithms and Key Lengths." NIST SP 800-131A Rev.2, March 2019. Nist - Detail ↩

  5. NIST. "Recommendation for Key Management." NIST SP 800-57 Part 1 Rev. 5, May 2020. Nist - Detail ↩

  6. Laurie, B., et al. "Certificate Transparency." RFC 6962, June 2013. Rfc-editor - Rfc6962 ↩

  7. Stevens, M., et al. "Short chosen-prefix collisions for MD5 and the creation of a rogue CA certificate." CRYPTO 2009. Tue - Rogue Ca ↩