101
0/240
Loading content...
How can you trust that you're actually communicating with your bank's server, not an attacker's imitation? This is the authentication problem—and at internet scale, it requires infrastructure far more sophisticated than simple passwords or shared secrets.
TLS solves this through certificate-based authentication, a system where trusted third parties vouch for the identity of servers (and optionally clients). Understanding this infrastructure is crucial for network security professionals, as misconfigured certificates are among the most common causes of TLS security failures.
By the end of this page, you will understand X.509 certificate structure and fields, the Certificate Authority hierarchy, chain of trust validation, certificate lifecycle management, and common certificate-related security issues. This knowledge is essential for deploying, troubleshooting, and auditing TLS implementations.
An X.509 certificate is a standardized digital document that binds a public key to an identity. The standard, defined in RFC 5280, specifies the exact format and fields that certificates must contain.
What a Certificate Proves:
When a server presents a valid certificate, it proves:
Certificate Structure:
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, -- The 'meat' of the certificate signatureAlgorithm AlgorithmIdentifier, -- How CA signed it signatureValue BIT STRING -- The actual signature} TBSCertificate ::= SEQUENCE { version [0] Version DEFAULT v1, -- Usually v3 (= integer 2) serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, -- Same as signatureAlgorithm issuer Name, -- CA that issued this cert validity Validity, -- notBefore and notAfter subject Name, -- Entity this cert identifies subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL -- Where the real magic is}| Field | Description | Example |
|---|---|---|
| Version | Certificate format version (usually 3) | v3 (0x2) |
| Serial Number | Unique identifier from CA | 03:A4:F7:2B:... |
| Issuer | Distinguished Name of signing CA | CN=DigiCert CA, O=DigiCert Inc |
| Validity Period | Start and end dates | Not Before: Jan 1, Not After: Dec 31 |
| Subject | Distinguished Name of certificate owner | CN=www.example.com, O=Example Inc |
| Public Key | Algorithm and key material | RSA 2048-bit or EC P-256 |
| Extensions | Additional constraints and metadata | Subject Alt Names, Key Usage, etc. |
| Signature | CA's cryptographic signature over all above | SHA256withRSA or ECDSA-SHA384 |
'TBS' stands for 'To Be Signed.' The TBSCertificate is the portion over which the CA computes its signature. The signature covers everything from version through extensions. Any modification to any field invalidates the signature.
While the core certificate structure provides basic identity binding, the extensions define crucial constraints and capabilities. Understanding these extensions is essential for security analysis.
Extension Basics:
Essential Extensions for TLS:
Subject Alternative Name (SAN):
The SAN extension lists all identities (hostnames, IP addresses, emails) for which the certificate is valid. This is the authoritative source for hostname matching in modern TLS.
SAN Types:
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = *.example.com
IP.1 = 192.168.1.1
email.1 = admin@example.com
Why SAN Over Subject CN:
Hostname Matching Rules:
example.com matches only example.com*.example.com matches www.example.com but NOT example.com or sub.www.example.comTLS implementations MUST validate all critical extensions and reject certificates with unrecognized critical extensions. Failure to do so has led to real-world security breaches where CSR injection or constraint bypass allowed unauthorized certificate issuance.
The Public Key Infrastructure (PKI) underpinning TLS is built on a hierarchical trust model where trust flows from a small number of root CAs down through intermediate CAs to end-entity certificates.
The Trust Chain:
┌─────────────────────────────────────────────────────────────────┐│ ROOT CA ││ ┌───────────────────────────────────────────────────────────┐ ││ │ Subject: CN=DigiCert Global Root G2 │ ││ │ Issuer: CN=DigiCert Global Root G2 (SELF-SIGNED) │ ││ │ Validity: 25 years │ ││ │ Basic Constraints: CA:TRUE │ ││ │ Key Usage: keyCertSign, cRLSign │ ││ │ STORED IN: Browser/OS trust store │ ││ └───────────────────────────────────────────────────────────┘ ││ │ ││ Signs ▼ ││ ││ INTERMEDIATE CA ││ ┌───────────────────────────────────────────────────────────┐ ││ │ Subject: CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 │ ││ │ Issuer: CN=DigiCert Global Root G2 │ ││ │ Validity: 10 years │ ││ │ Basic Constraints: CA:TRUE, pathlen:0 │ ││ │ Key Usage: keyCertSign, cRLSign │ ││ │ SENT BY: Server during handshake │ ││ └───────────────────────────────────────────────────────────┘ ││ │ ││ Signs ▼ ││ ││ END-ENTITY CERTIFICATE ││ ┌───────────────────────────────────────────────────────────┐ ││ │ Subject: CN=www.example.com │ ││ │ Issuer: CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 │ ││ │ Validity: 1 year (max 398 days per CAB Forum) │ ││ │ Basic Constraints: CA:FALSE │ ││ │ Key Usage: digitalSignature │ ││ │ Extended Key Usage: serverAuth │ ││ │ Subject Alt Name: www.example.com, example.com │ ││ │ SENT BY: Server during handshake │ ││ └───────────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────────┘Why Use Intermediate CAs?
Root CAs never directly sign end-entity certificates in modern practice. Instead:
Root Key Protection: Root private keys are kept offline in HSMs (Hardware Security Modules), air-gapped from networks. They're used only to sign intermediate CA certificates.
Damage Limitation: If an intermediate CA is compromised, it can be revoked without replacing the root. Browsers can update revocation lists, but replacing roots requires OS/browser updates.
Operational Flexibility: Different intermediates can serve different purposes (DV vs EV certs), geographic regions, or key types.
Key Rotation: Intermediates can use shorter-lived keys without requiring trust store updates.
Trust Store Contents:
| Platform | Root CAs | Update Mechanism |
|---|---|---|
| Mozilla NSS (Firefox) | ~150 roots | Quarterly releases |
| Apple Trust Store | ~160 roots | macOS/iOS updates |
| Microsoft Root Program | ~350+ roots | Windows Update |
| Chrome Root Store | ~120 roots | Chrome updates (transitioning) |
| Android | ~150 roots | System updates (varies) |
The CA/Browser Forum (CAB Forum) is an industry consortium that sets policies all public CAs must follow. Their Baseline Requirements specify maximum certificate validity (398 days), required verification procedures, and security practices. Non-compliance can result in CA removal from trust stores.
When a TLS client receives a certificate from a server, it must perform rigorous validation before trusting it. This validation process is complex and multi-faceted.
The Complete Validation Algorithm:
notBefore <= now <= notAfter for all certificates in chainSignature Verification Deep Dive:
The cryptographic core of certificate validation is signature verification:
For each certificate in chain (except root):
1. Extract TBSCertificate from certificate
2. Extract signatureAlgorithm (e.g., SHA256withRSA)
3. Extract signatureValue
4. Get issuer's public key (from issuer certificate)
5. Verify: signature_verify(issuer_public_key, hash(TBSCertificate), signatureValue)
Path Building Challenges:
The server typically sends its certificate plus intermediates, but path building can be complex:
When intermediates are missing, some clients fetch them via the Authority Information Access (AIA) extension. This creates a network dependency during TLS handshake, adding latency and potential failure modes. Always configure servers to send the complete chain (excluding the root, which clients have locally).
Certificates are issued with validity periods, but sometimes they must be invalidated before expiration—when private keys are compromised, when an employee leaves, or when certificate information changes. This is revocation, and it's one of the most challenging aspects of PKI.
Why Revocation is Hard:
Certificate Revocation Lists (CRL):
A CRL is a signed list of revoked certificate serial numbers published by a CA.
Structure:
CRL:
issuer: CN=Example CA
thisUpdate: 2024-01-01
nextUpdate: 2024-01-08
revokedCertificates:
- serialNumber: 03:AF:21...
revocationDate: 2023-12-15
reason: keyCompromise (1)
- serialNumber: 07:B2:44...
revocationDate: 2023-12-20
reason: cessationOfOperation (5)
signature: [CA signature over above]
Advantages:
Disadvantages:
Most browsers 'soft-fail' on revocation: if CRL/OCSP checks fail (network error, timeout), they proceed anyway. This means a network attacker who can block revocation checks can use revoked certificates. Chrome addressed this by moving to CRLite (compact, pushable revocation data) rather than per-connection checks.
Managing certificates throughout their lifecycle is a critical operational responsibility. Certificate-related outages are embarrassingly common and entirely preventable.
The Certificate Lifecycle:
┌───────────────────────────────────────────────────────────────────┐│ CERTIFICATE LIFECYCLE ││ ││ ┌──────────────┐ ┌─────────────┐ ┌─────────────────┐ ││ │ 1. Generate │ │ 2. Request │ │ 3. Validate │ ││ │ Key Pair │ ──> │ (CSR) │ ──> │ Domain/Org │ ││ │ │ │ │ │ (by CA) │ ││ └──────────────┘ └─────────────┘ └────────┬────────┘ ││ │ ││ ▼ ││ ┌──────────────┐ ┌─────────────┐ ┌─────────────────┐ ││ │ 6. Renew │ │ 5. Monitor │ │ 4. Install │ ││ │ (before │ <── │ Expiration │ <── │ Certificate │ ││ │ expiry) │ │ │ │ │ ││ └──────────────┘ └─────────────┘ └─────────────────┘ ││ │ ││ │ ┌─────────────────────────────────────────────┐ ││ │ │ 7. Revoke (if key compromised, etc.) │ ││ │ └─────────────────────────────────────────────┘ ││ │ ││ └──────> Loop forever or until domain retired │└───────────────────────────────────────────────────────────────────┘openssl s_client -connect host:443Let's Encrypt revolutionized certificate management by providing free certificates via the ACME protocol. With 90-day certificate validity and automated renewal, the 'forgot to renew' failure mode becomes rare. Aim for certificates renewed at 60 days, providing 30-day buffer for any issues.
Certificate Transparency (CT) is a system designed to detect fraudulently or mistakenly issued certificates. It provides public, append-only logs of all issued certificates, enabling monitoring and auditing.
The Problem CT Solves:
Before CT, a misbehaving or compromised CA could issue a certificate for any domain without detection. If DigiCert issued a fake certificate for google.com, Google would have no way to know until the certificate was used in an attack.
How CT Works:
Certificate Authority CT Log Operators │ │ │ 1. CA issues certificate │ │ to customer │ │ │ │ 2. CA submits certificate │ │ to CT logs (required) │ │ ────────────────────────────────────>│ │ │ │ 3. Logs return Signed │ │ Certificate Timestamp (SCT) │ │ <────────────────────────────────────│ │ │ │ 4. CA embeds SCT(s) in │ │ certificate or staples │ │ │ ▼ │Website Server │ │ │ │ 5. Include SCTs in │ │ TLS handshake │ │ │ ▼ │Browser (Client) │ │ │ │ 6. Verify SCTs signed by │ │ known CT logs │ │ │ │ 7. Require SCTs from │ │ multiple logs (diversity) │ │ │ ▼ │ │ 8. Domain owners can │ │ monitor logs for │ │ their domains │ └──────────────────────────────────────────>Key CT Components:
CT Logs:
Signed Certificate Timestamps (SCTs):
Browser Requirements (Chrome Policy):
CT has detected numerous mis-issued certificates including: Google certificates mistakenly issued by Symantec, fraudulent certificates from TURKTRUST, and compliance violations by multiple CAs. These detections led to CA sanctions and trust store removals, demonstrating CT's effectiveness.
We have thoroughly examined the certificate infrastructure that makes TLS authentication possible. Let's consolidate the key insights:
What's Next:
With a solid understanding of TLS fundamentals—purpose, versions, security services, and certificates—we will explore modern TLS usage. The final page examines contemporary deployment practices: TLS 1.3 adoption, cipher suite selection, testing and auditing tools, and emerging developments like encrypted SNI and post-quantum cryptography.
You now have comprehensive knowledge of certificate-based authentication in TLS. This enables you to troubleshoot certificate issues, configure servers correctly, monitor for mis-issuance, and understand the trust model underlying secure internet communications.