X.509 Certificates - Certificates and PKI | OneNoughtOne

0/240

Computer NetworksNetwork Security Protocols

Certificates and PKI

LevelIntermediate

Duration90 mins

TopicNetwork Security Protocols

1 / 5

X.509 Certificates

The Digital Passport of the Internet

Every time you see that padlock icon in your browser's address bar, you're witnessing the culmination of decades of cryptographic engineering. Behind that simple symbol lies a sophisticated system of digital certificates—electronic documents that prove identity, enable encryption, and form the foundation of trust on the internet.

At the heart of this system is the X.509 certificate, an international standard (ITU-T X.509) that defines the format for public key certificates. Originally developed in 1988 as part of the X.500 directory services standard, X.509 has evolved to become the universal credential for internet security. Every HTTPS connection, every digitally signed email, every VPN tunnel, and every secure API call relies on X.509 certificates.

Understanding X.509 certificates isn't merely academic—it's essential knowledge for any engineer working with secure systems. Misconfigurations in certificate handling are among the most common causes of security vulnerabilities and service outages. A single expired certificate can take down critical infrastructure; a compromised certificate can enable devastating man-in-the-middle attacks.

What You Will Master

By the end of this page, you will understand the complete anatomy of X.509 certificates: their internal structure, cryptographic components, encoding formats, and extensions. You'll be able to read, interpret, and troubleshoot real-world certificates—skills that every security-conscious engineer needs.

The Fundamental Problem: Identity in Cryptography

To appreciate why X.509 certificates exist, we must first understand the fundamental problem they solve: how do you verify identity in an anonymous, hostile network?

The Public Key Paradox:

Public key cryptography elegantly solves the key distribution problem—you can publish your public key openly, and anyone can use it to send you encrypted messages that only your private key can decrypt. But this introduces a new challenge: how does a sender know that a public key actually belongs to the intended recipient?

Consider this scenario:

Alice wants to send a confidential message to Bob
Alice needs Bob's public key to encrypt the message
Alice downloads a key claiming to be "Bob's Public Key"
But how does Alice verify this is actually Bob's key?

Without verification, an attacker (Mallory) could intercept Alice's request and substitute her own key. Alice would unknowingly encrypt her message with Mallory's key. Mallory decrypts it, reads the confidential content, then re-encrypts it with Bob's actual key and forwards it. Neither Alice nor Bob would ever know the message was intercepted.

The Man-in-the-Middle Threat

This attack pattern—interposing between two parties and impersonating each to the other—is called a Man-in-the-Middle (MITM) attack. It's one of the most dangerous attack categories because it can be completely invisible to the victims. Certificates exist specifically to prevent MITM attacks by binding identity to cryptographic keys.

The Certificate Solution:

A digital certificate is essentially a cryptographically signed attestation that a particular public key belongs to a particular entity. The certificate contains:

The subject's identity (e.g., "www.example.com" or "Alice Smith")
The subject's public key
Metadata (validity period, permitted usages, etc.)
A digital signature from a trusted third party

The signature is the crucial element. It comes from a Certificate Authority (CA)—an entity that the relying party already trusts. By verifying the CA's signature on the certificate, Alice can confirm that the CA vouches for the binding between Bob's identity and Bob's public key.

This transforms the problem from "How do I trust this random public key?" to "Do I trust the entity that signed this certificate?" And if that entity is well-known and reputable (like DigiCert, Let's Encrypt, or GlobalSign), the answer is yes.

What Certificates Accomplish

•Authentication — Prove that a server or user is who they claim to be
•Key Distribution — Provide a trusted mechanism to obtain verified public keys
•Integrity — Ensure the public key hasn't been tampered with during transmission
•Non-repudiation — Create a binding that the subject cannot later deny
•Trust Delegation — Allow trust in known CAs to extend to unknown entities

A Brief History of X.509

Understanding the history of X.509 helps explain some of its design choices and the existence of multiple versions.

The Genesis (1988):

X.509 was developed by the International Telecommunication Union (ITU-T) as part of the X.500 directory services standard. The original vision was ambitious: create a global directory service (like a worldwide phone book for the digital age) with built-in authentication. X.509 certificates were the authentication mechanism.

The first version (X.509v1) was simple: subject name, public key, validity dates, and a CA signature. It assumed a hierarchical, centralized world of tightly controlled directories—a vision that never materialized.

The Internet Adoption (1990s):

When the web emerged and e-commerce required secure transactions, the internet community adapted X.509 for its needs. The IETF's PKIX working group (Public Key Infrastructure using X.509) extended and profiled the standard for internet use (RFC 5280).

X.509v2 (1993) added issuer and subject unique identifiers—rarely used in practice. X.509v3 (1996) introduced the extension mechanism that proved transformative, allowing the certificate format to evolve without breaking backward compatibility.

Evolution of X.509 Versions
Version	Year	Key Additions	Usage Today
X.509v1	1988	Basic structure: subject, issuer, validity, public key, signature	Obsolete; not used
X.509v2	1993	Issuer/subject unique identifiers	Rarely used; considered deprecated
X.509v3	1996	Extension mechanism enabling future flexibility	Universal standard; all modern certificates

The Power of Extensions

The v3 extension mechanism is what made X.509 adaptable to unforeseen requirements. Subject Alternative Names, Key Usage constraints, Certificate Policies, and dozens of other features all came through extensions—without requiring yet another version of the base standard.

Anatomy of an X.509 Certificate

An X.509v3 certificate contains three main sections, each with specific fields. Understanding every field is essential for proper certificate handling and debugging.

The Three Primary Sections:

TBSCertificate ("To Be Signed") — All certificate data that the CA signs
Signature Algorithm — The algorithm used to create the signature
Signature Value — The actual digital signature from the CA

The TBSCertificate contains all the meaningful content. The signature algorithm appears twice (in TBS and separately) as a security measure to prevent algorithm substitution attacks.

x509-certificate-structure.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,         -- The signed data
    signatureAlgorithm   AlgorithmIdentifier,    -- How it was signed
    signatureValue       BIT STRING              -- The actual signature
}
 
TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,  -- Must match outer signatureAlgorithm
    issuer               Name,                 -- Who signed this
    validity             Validity,             -- When it's valid
    subject              Name,                 -- Who this cert is for
    subjectPublicKeyInfo SubjectPublicKeyInfo, -- The public key
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,  -- v2, rarely used
    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,  -- v2, rarely used
    extensions      [3]  EXPLICIT Extensions OPTIONAL         -- v3, always used now
}

Detailed Field Analysis:

Core Certificate Fields

•Version — Integer 0, 1, or 2 representing v1, v2, or v3 (offset by 1). Modern certificates are always v3 (integer value 2).
•Serial Number — A unique integer assigned by the CA. Must be positive and at most 20 bytes. Combined with issuer, uniquely identifies any certificate globally.
•Signature Algorithm — OID (Object Identifier) specifying the signature algorithm (e.g., sha256WithRSAEncryption, ecdsa-with-SHA256). Critical for verification.
•Issuer — Distinguished Name (DN) of the CA that signed this certificate. Structured as ordered set of attribute-value pairs (CN, O, OU, C, etc.).
•Validity — Two timestamps (notBefore and notAfter) defining the certificate's valid time window. UTCTime or GeneralizedTime format.
•Subject — Distinguished Name of the entity the certificate is issued to. For web certificates, CN often contains the domain name (though SAN is preferred now).
•Subject Public Key Info — The public key and its algorithm. Contains the algorithm OID and the key as a BIT STRING.

Distinguished Names Explained

Distinguished Names follow LDAP conventions: CN (Common Name), O (Organization), OU (Organizational Unit), L (Locality/City), ST (State/Province), C (Country). Example: CN=www.example.com, O=Example Inc., L=San Francisco, ST=California, C=US

X.509v3 Extensions: The Flexibility Layer

Extensions are the mechanism that makes X.509 certificates adaptable and powerful. Each extension has:

Extension OID — Identifies the extension type
Critical Flag — Boolean indicating if the extension is critical
Extension Value — The actual extension data (ASN.1 encoded)

The Critical Flag:

This flag has profound implications:

If an extension is marked critical and the software doesn't recognize it, the certificate must be rejected
If an extension is marked non-critical and not recognized, it can be safely ignored

This mechanism allows new extensions to be added while maintaining backward compatibility (non-critical) or enforcing new requirements (critical).

Essential X.509v3 Extensions
Extension	OID	Purpose	Typically Critical?
Basic Constraints	2.5.29.19	Indicates if subject is a CA; path length limit	Yes (for CA certs)
Key Usage	2.5.29.15	Permitted uses: signing, encryption, key agreement	Yes
Extended Key Usage	2.5.29.37	Specific purposes: TLS server, code signing, email	Usually no
Subject Alternative Name	2.5.29.17	Additional identities: DNS names, IPs, emails	No
Authority Key Identifier	2.5.29.35	Identifies issuer's public key (for chain building)	No
Subject Key Identifier	2.5.29.14	Hash of subject's public key (for chain building)	No
CRL Distribution Points	2.5.29.31	URLs where revocation lists can be obtained	No
Authority Information Access	1.3.6.1.5.5.7.1.1	OCSP responder URL, CA issuer certificate URL	No
Certificate Policies	2.5.29.32	Policy under which certificate was issued	Optional

Deep Dive: The Most Important Extensions:

Basic Constraints: This extension is crucial for security. It has two components:

cA boolean: TRUE if the subject can issue certificates, FALSE otherwise
pathLenConstraint: Maximum number of non-self-issued intermediate certs below this

Without proper Basic Constraints, an end-entity certificate could be used to sign other certificates, enabling massive fraud.

Key Usage: A 9-bit field specifying permitted operations:

digitalSignature (bit 0): Sign data (except certificates/CRLs)
nonRepudiation/contentCommitment (bit 1): Binding signature
keyEncipherment (bit 2): Encrypt other keys (e.g., in RSA key exchange)
dataEncipherment (bit 3): Encrypt data directly
keyAgreement (bit 4): Key agreement protocols (DH, ECDH)
keyCertSign (bit 5): Sign certificates (CA only)
cRLSign (bit 6): Sign CRLs (typically CA only)
encipherOnly (bit 7): Only encipher during key agreement
decipherOnly (bit 8): Only decipher during key agreement

Subject Alternative Name (SAN): Modern web certificates rely heavily on SAN. It allows multiple identities:

DNS names (dNSName): www.example.com, *.example.com
IP addresses (iPAddress): 192.168.1.1, 2001:db8::1
Email addresses (rfc822Name): user@example.com
URIs (uniformResourceIdentifier): https://example.com

Browsers now require domain names in SAN, not just CN. A certificate without SAN for the accessed domain will be rejected.

The CN Deprecation

Using Common Name (CN) for domain validation is deprecated. Chrome, Firefox, and other browsers no longer accept certificates that only have the domain in CN without a matching SAN entry. Always use Subject Alternative Name for domain names.

Certificate Encoding Formats

X.509 certificates can exist in multiple encoding formats. Understanding these formats is essential for working with certificates across different systems and applications.

ASN.1: The Foundation:

X.509 certificates are defined using Abstract Syntax Notation One (ASN.1), a standard for describing data structures. ASN.1 is a schema language (similar to JSON Schema or Protocol Buffers definitions) that precisely specifies what data a certificate contains.

ASN.1 definitions are then encoded using Distinguished Encoding Rules (DER) or Basic Encoding Rules (BER). DER is a subset of BER that ensures deterministic encoding—given the same data, you always get the same bytes. This property is essential for digital signatures.

Common File Formats:

X.509 Certificate File Formats
Format	Extensions	Encoding	Description
DER	.der, .cer, .crt	Binary	Raw DER-encoded certificate; compact but not human-readable
PEM	.pem, .crt, .cer	Base64 + headers	Base64-encoded DER with -----BEGIN/END CERTIFICATE----- headers
PKCS#7	.p7b, .p7c	Binary or PEM	Container for multiple certificates; no private keys
PKCS#12/PFX	.pfx, .p12	Binary	Container for certificate + private key; password-protected

example-pem-certificate.pem

-----BEGIN CERTIFICATE-----
MIIFazCCBFOgAwIBAgISA0MQ2vICEADBICxQ4RJNxw4jMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA5MjMxNjUxMzlaFw0y
MDEyMjIxNjUxMzlaMBkxFzAVBgNVBAMTDnd3dy5leGFtcGxlLmNvbTCCASIwDQYJ
[... base64 encoded certificate data ...]
VKGaoHPRd/6t3Ry9QNLHI3Dcr5bQhQ==
-----END CERTIFICATE-----

PEM Format Details:

PEM (Privacy-Enhanced Mail) is the most common format for certificates in Unix/Linux systems. The format consists of:

A header line: -----BEGIN CERTIFICATE-----
Base64-encoded DER data (64 characters per line, typically)
A footer line: -----END CERTIFICATE-----

PEM files can contain multiple objects (certificates, keys, etc.) concatenated together. Order often matters—for a certificate chain, the order is typically: end-entity cert, intermediate(s), root.

Working with Formats:

openssl-format-conversions.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# View certificate contents (PEM format)
openssl x509 -in cert.pem -text -noout
 
# Convert PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.der
 
# Convert DER to PEM
openssl x509 -in cert.der -inform DER -outform PEM -out cert.pem
 
# Extract certificate from PKCS#12
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem
 
# View certificate chain
openssl s_client -connect example.com:443 -showcerts
 
# Verify certificate validity
openssl verify -CAfile ca-bundle.crt cert.pem
 
# Check certificate expiration
openssl x509 -in cert.pem -noout -dates
 
# View Subject Alternative Names
openssl x509 -in cert.pem -noout -ext subjectAltName

Quick Format Identification

If you can open the file in a text editor and see '-----BEGIN CERTIFICATE-----', it's PEM. If you see binary gibberish, it's DER. If you see '-----BEGIN PKCS7-----' or the file has .p7b extension, it's PKCS#7. If the file requires a password to open and has .pfx or .p12 extension, it's PKCS#12.

Reading and Interpreting Real Certificates

Let's examine a real-world certificate to see how all these concepts come together. The following is an actual certificate (anonymized) from a production web server:

decoded-certificate-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:65:d5:40:6c:e7:78:94:4e:8b:f6:15:81:c7:fa:c1:d4:32
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Jan 15 00:00:00 2024 GMT
            Not After : Apr 15 23:59:59 2024 GMT
        Subject: CN = www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b4:5f:c3:a2:... (256 bytes)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                8D:9E:32:6B:... (20 bytes)
            X509v3 Authority Key Identifier: 
                keyid:14:2E:B3:17:... (20 bytes)
            Authority Information Access: 
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/
            X509v3 Subject Alternative Name: 
                DNS:www.example.com, DNS:example.com
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://r3.c.lencr.org/
    Signature Algorithm: sha256WithRSAEncryption
         7a:f3:4e:6c:... (256 bytes)

Certificate Analysis:

Let's decode what each part tells us:

Identity and Authority:

Subject: CN = www.example.com — This certificate identifies the web server at www.example.com
Issuer: C = US, O = Let's Encrypt, CN = R3 — Let's Encrypt's R3 intermediate CA signed this
Serial Number: Unique identifier assigned by Let's Encrypt

Validity:

Valid from January 15 to April 15, 2024 — 90 days (Let's Encrypt's standard period)
Short validity reduces exposure if key is compromised

Cryptography:

Algorithm: RSA with 2048-bit key (industry standard minimum)
Exponent: 65537 (0x10001) — the universally standard RSA public exponent
Signature: SHA-256 with RSA — modern, secure algorithm

Extension Analysis:

Key Usage: Digital Signature, Key Encipherment (critical) — Can sign data and encrypt session keys
Extended Key Usage: TLS Server and Client auth — Can be used by servers and clients
Basic Constraints: CA:FALSE (critical) — This is NOT a CA certificate; cannot sign other certs
Subject Alternative Name: Covers both www.example.com AND example.com
Authority Information Access: OCSP responder for revocation checking; URL to download issuing CA cert
CRL Distribution Points: URL for Certificate Revocation List

Well-Formed Modern Certificate

This certificate follows current best practices: SHA-256 signatures, proper Key Usage and Basic Constraints, SAN for domain names, OCSP for revocation, and reasonable validity period. These are the characteristics to look for when evaluating certificate quality.

Types of X.509 Certificates

Not all certificates serve the same purpose. Understanding the different types helps you select and configure the right certificate for each use case.

Certificate Categories by Purpose

•TLS Server Certificates — Authenticate web servers; contain domain names in SAN; Most common type you'll encounter
•TLS Client Certificates — Authenticate clients to servers (mutual TLS/mTLS); Used in high-security environments and service-to-service authentication
•Code Signing Certificates — Sign software to prove publisher identity; Used by operating systems to verify application integrity
•S/MIME Certificates — Sign and encrypt email; Bind identity to email addresses
•Document Signing Certificates — Sign PDFs and other documents; Provide legally binding digital signatures
•CA Certificates — Issue other certificates; Have Basic Constraints cA:TRUE; Strictly controlled

Validation Levels (for TLS Server Certificates):

CAs offer different validation levels, each with different verification rigor and visual indicators:

TLS Certificate Validation Levels
Level	Abbreviation	Verification	Use Cases	Visual Indicator
Domain Validation	DV	Prove domain control only (email, DNS, HTTP)	Blogs, small sites, development	Padlock only (no org name)
Organization Validation	OV	DV + verify organization exists	Business sites, moderate trust needs	Padlock + org name in cert details
Extended Validation	EV	OV + rigorous verification, legal existence	Financial services, high-value transactions	Padlock + org name (varies by browser)

EV Indicator Changes

Major browsers (Chrome, Firefox, Safari) have removed the green address bar and prominent organization name display for EV certificates. While EV still requires more verification, the visual distinction has diminished. For most use cases, DV certificates provide equivalent cryptographic security.

Wildcard and SAN Certificates:

Wildcard Certificates:

Cover one level of subdomains: *.example.com matches www.example.com, api.example.com, but NOT login.api.example.com
Cannot be EV validation
Single point of compromise if private key is leaked

Multi-Domain (SAN) Certificates:

Multiple distinct domains in one certificate
Can combine example.com, example.org, example.net
More flexible but requires re-issuance to add domains

Wildcard + SAN:

Best of both: *.example.com AND *.example.org in one cert
Common for large organizations managing multiple domains

Summary: X.509 Certificates Mastered

We've explored X.509 certificates in comprehensive depth. Let's consolidate the essential knowledge:

Key Takeaways

•Certificates solve the identity problem — They cryptographically bind public keys to verified identities, preventing MITM attacks
•X.509v3 is the universal standard — Evolved since 1988, now handles everything from web servers to code signing through its flexible extension mechanism
•Structure matters for security — Version, serial number, validity, subject, issuer, extensions—each field serves a specific security purpose
•Extensions enable policy enforcement — Key Usage, Basic Constraints, and SAN are critical for proper certificate validation
•Multiple encoding formats exist — PEM (text, portable), DER (binary, compact), PKCS#12 (with keys, password-protected)
•Validation levels indicate verification rigor — DV/OV/EV reflect how thoroughly the CA verified the certificate applicant

What's Next:

Now that you understand certificates themselves, the next critical question is: Who issues these certificates and why should we trust them?

The next page explores Certificate Authorities—the entities that vouch for certificate holders. We'll examine how CAs verify identity, the trust model that makes web PKI work, and the implications of CA compromise.

Page Complete

You now possess deep knowledge of X.509 certificates—their structure, encoding, extensions, and types. This foundation is essential for understanding the broader PKI ecosystem, debugging certificate issues, and making informed security decisions. Next, we explore the Certificate Authorities that make the trust system work.