When you visit https://bank.example.com, how does your browser know it's actually communicating with your bank and not a sophisticated imposter? The answer lies in a global infrastructure of trust called the Public Key Infrastructure (PKI), at the heart of which stand Certificate Authorities (CAs).

Certificate Authorities are trusted third parties that vouch for the binding between public keys and identities. When your browser sees a certificate signed by a CA in its trust store, it accepts that the public key in the certificate genuinely belongs to the entity named in the certificate.

This trust model has enabled secure e-commerce, online banking, and private communication for billions of users. Yet it remains one of the most criticized components of internet security—a single compromised CA can undermine trust in the entire system. Understanding how CAs work, what they protect against, and their limitations is essential for any security practitioner.

The Public Key Infrastructure (PKI) is a framework for managing public key cryptography at scale. Its core problem: how can parties who have never met verify each other's public keys?

The Public Key Binding Problem:

Public key cryptography enables authentication—if Alice has Bob's public key, Bob can prove his identity by signing a challenge with his private key. But how does Alice obtain Bob's genuine public key?

• Direct exchange: Alice and Bob meet in person. Doesn't scale.
• Key server: Trusted server holds everyone's keys. Single point of failure.
• Web of Trust: Users sign each other's keys (PGP model). Hard to bootstrap.
• Certificate Authorities: Trusted authorities vouch for key bindings. The dominant model.

X.509 Certificates:

An X.509 certificate is a digitally signed document that binds a public key to an identity. The structure (defined in RFC 5280) includes:

Certificate ::= SEQUENCE {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING
}

TBSCertificate ::= SEQUENCE {
    version              [0] Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID       [1] IMPLICIT UniqueIdentifier OPTIONAL,
    subjectUniqueID      [2] IMPLICIT UniqueIdentifier OPTIONAL,
    extensions           [3] Extensions OPTIONAL
}

Critical Certificate Extensions:

• Subject Alternative Name (SAN): Lists all hostnames the certificate is valid for. Modern certificates primarily use SAN rather than Common Name.

• Key Usage: Specifies permitted operations (digitalSignature, keyEncipherment, keyCertSign)

• Extended Key Usage (EKU): Further restricts usage (serverAuth, clientAuth, codeSigning)

• Basic Constraints: Indicates if the certificate can sign other certificates (CA:TRUE/FALSE)

• Authority Information Access (AIA): URLs for CA certificate and OCSP responder

• CRL Distribution Points: URLs where revocation lists are published

Certificate Authorities operate in hierarchies to balance security with operational flexibility. Understanding this structure is crucial for certificate chain validation and trust management.

CA Types:

Root CAs:

• Self-signed certificates (issuer = subject)
• Stored in trust stores of operating systems and browsers
• Extremely high security requirements (often offline, in HSMs)
• Long validity periods (10-25 years)
• Compromise is catastrophic and irreversible for that root

Intermediate (Subordinate) CAs:

• Signed by root or other intermediate CAs
• Perform day-to-day certificate issuance
• Shorter validity periods than roots
• Can be revoked if compromised without replacing roots
• Often specialized by product line or region

Issuing CAs:

• Leaf-level CAs that directly issue end-entity certificates
• May be further specialized or constrained
• Highest volume of signing operations

Certificate Chains:

End-entity certificates must be verified by building a chain to a trusted root:

End-Entity Certificate
    ↓ verified by signature from
Intermediate CA Certificate
    ↓ verified by signature from
Root CA Certificate
    ↓ found in
Trust Store (trusted anchor)

Chain Building and Validation:

1. Receive certificates: Server sends its certificate plus intermediates
2. Build chain: Find a path from end-entity to trusted root
3. Verify signatures: Each certificate's signature verified with issuer's public key
4. Check validity: All certificates within validity period
5. Check revocation: Verify no certificate is revoked (CRL/OCSP)
6. Check constraints: Name constraints, path length, key usage all satisfied
7. Hostname validation: Certificate SANs match requested hostname

Cross-Signing:

New CAs often get cross-signed by established roots for immediate trust:

Let's Encrypt ISRG Root X1 (new, may not be in old trust stores)
                   ↑ cross-signed by
DST Root CA X3 (widely trusted, expired Sept 2021)

Clients trust either path, maximizing compatibility.

Certificate issuance follows a defined process to ensure CAs only issue certificates to legitimate requesters. The rigor of this process determines the level of assurance the certificate provides.

Certificate Signing Request (CSR):

The requester generates a key pair and creates a CSR containing:

• Subject information (organization name, domain name)
• Public key
• Proof of possession of private key (self-signed)

# Generate private key
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# Generate CSR
openssl req -new -key server.key -out server.csr \
    -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=www.example.com"

# Inspect CSR
openssl req -in server.csr -text -noout

Domain Validation (DV):

The CA verifies the requester controls the domain. Methods include:

1. HTTP Challenge: Place a CA-specified file at /.well-known/acme-challenge/
2. DNS Challenge: Create a specific TXT record in DNS
3. Email Verification: Respond to email sent to admin contact addresses
4. TLS-ALPN Challenge: Serve a CA-specified certificate on port 443

ACME Protocol Flow (Let's Encrypt):

1. Client → CA: Request authorization for domain.com
2. CA → Client: Here's a token; prove control via HTTP or DNS
3. Client: Places token at http://domain.com/.well-known/acme-challenge/[token]
4. CA: Verifies challenge from multiple network vantage points
5. CA → Client: Authorization granted
6. Client → CA: Submit CSR for domain.com
7. CA → Client: Signed certificate (and chain)

Organization and Extended Validation:

OV Certificates: CA verifies the organization exists and is the domain owner

• Phone verification against official records
• Business registration verification
• Callback to verified phone numbers

EV Certificates: Most rigorous verification

• Legal existence verification (articles of incorporation)
• Operational existence verification (bank account, listings)
• Physical address verification
• Authorized requester confirmation
• Annual renewal of verification

The Decline of EV Visual Indicators:

Browsers originally displayed EV certificates with green address bars and organization names. This has been largely removed:

• Chrome removed EV visual distinction (2019)
• Firefox removed green bar (2019)
• Research showed users didn't notice or understand the indicators
• EV is now primarily a compliance/liability distinction, not user-facing

When your browser or application validates a certificate, it performs a complex series of checks. Understanding this process is essential for diagnosing certificate errors and building secure systems.

Complete Validation Algorithm:

Hostname Verification Details:

Hostname matching is often the source of validation bugs:

Certificate SANs: www.example.com, example.com, api.example.com

Request for www.example.com  → Match (exact)
Request for example.com      → Match (exact)  
Request for api.example.com  → Match (exact)
Request for mail.example.com → NO MATCH (not in SANs)
Request for www.example.org  → NO MATCH (wrong domain)

Wildcard Certificates:

Certificate SAN: *.example.com

Request for www.example.com    → Match
Request for api.example.com    → Match
Request for example.com        → NO MATCH (wildcard doesn't match empty string)
Request for sub.www.example.com → NO MATCH (wildcard matches one label only)

Common Validation Errors:

When a private key is compromised, an organization changes, or a certificate is no longer valid, it must be revoked before its natural expiration. However, distributing revocation information to all relying parties is one of PKI's hardest problems.

Certificate Revocation Lists (CRL):

CRLs are CA-signed lists of all revoked certificate serial numbers:

CRL Structure:
- CRL Version
- Issuer (CA that issued revoked certificates)
- This Update (CRL issue date)
- Next Update (expected next CRL)
- Revoked Certificates List:
    - Serial Number, Revocation Date, Reason Code
    - Serial Number, Revocation Date, Reason Code
    ...
- CRL Signature

CRL Problems:

• Size: Popular CAs may revoke millions of certificates; CRLs become huge
• Latency: CRLs are cached; revocations don't take effect immediately
• Privacy: Downloading CRLs reveals what sites user visits (indirectly)
• Reliability: CRL servers must be highly available; failures cause soft-fails

Online Certificate Status Protocol (OCSP):

OCSP provides real-time, per-certificate revocation checks:

Client → OCSP Responder: Is certificate [serial] from [issuer] revoked?
OCSP Responder → Client: Good / Revoked / Unknown
                         + signature + validity period

OCSP Advantages:

• Small response size (specific to one certificate)
• Fresher revocation information
• Cacheable responses reduce load

OCSP Problems:

• Privacy: OCSP responder learns user's browsing history
• Performance: Adds round-trip latency to every connection
• Reliability: OCSP server downtime affects all users
• Soft-Fail: Most browsers continue if OCSP is unavailable, defeating the purpose

Short-Lived Certificates:

An alternative approach: issue certificates with very short validity (days to hours). Revocation becomes unnecessary because compromised certificates expire quickly.

Advantages:

• No revocation infrastructure needed
• Compromise window is small
• Forces automation (reduces stale certificates)

Disadvantages:

• Requires robust automated issuance
• Higher CA load
• Clock synchronization more critical

Browser Revocation Checking Reality:

Despite the importance of revocation, browser behavior is pragmatic:

• Chrome: Uses CRLSets (Google-curated subset of revocations) pushed via browser updates. Does not check OCSP by default.
• Firefox: OCSP checking with soft-fail. CRLite (compressed revocation data) in development.
• Safari: OCSP checking with soft-fail.

The industry consensus is that traditional revocation checking is unreliable. Short-lived certificates and improved browser-side solutions are preferred.

The CA trust model's Achilles heel is that any trusted CA can issue certificates for any domain. A single compromised or malicious CA can issue fraudulent certificates that browsers will trust. History has shown this is not merely theoretical.

Notable CA Incidents:

Attack Scenarios:

State-Level Attacks: Governments can compel domestic CAs to issue surveillance certificates. A trusted CA in Country X can issue a certificate for any domain, enabling state-level MITM attacks on encrypted traffic.

CA Key Compromise: If an attacker obtains a CA's private key, they can issue unlimited fraudulent certificates. This is why root CA keys are kept offline in HSMs with extreme physical security.

Validation Bypass: Weaknesses in domain validation allow attackers to obtain certificates for domains they don't control (BGP hijacking to intercept validation traffic, compromised DNS, etc.).

Consequences of Misissuance:

1. Browser Distrust: CAs that misissue certificates face browser distrust—the ultimate penalty
2. Revocation Rush: Fraudulent certificates must be found and revoked
3. Trust Degradation: Each incident erodes confidence in the CA system
4. User Vulnerability: Users affected by fraudulent certificates have no defense

Certificate Transparency (CT) is a system of public logs that record all issued certificates. It transforms certificate issuance from a private transaction into an auditable, public process.

The CT Vision:

If every certificate is logged publicly:

• Domain owners can monitor for unauthorized certificates
• Misissuance is detectable rather than invisible
• CAs are held accountable for all certificates they issue
• The attack window shrinks from 'until expiration' to 'until detection'

CT Architecture:

CT Components:

1. CT Logs: Append-only cryptographic logs (Merkle trees) that record certificates:

• Anyone can submit certificates
• Log operators are separate from CAs
• Merkle trees provide efficient inclusion proofs
• Logs are auditable and tamper-evident

2. Signed Certificate Timestamps (SCT): When a log accepts a certificate, it returns an SCT—a promise to include the certificate:

SCT = {
    version: v1,
    log_id: <hash of log's public key>,
    timestamp: <milliseconds since epoch>,
    extensions: <future use>,
    signature: <log's signature over the above>
}

3. SCT Delivery: SCTs must reach the client to prove logging. Three methods:

• Embedded in Certificate: CA submits pre-certificate, gets SCTs, embeds in final cert
• TLS Extension: Server provides SCTs during TLS handshake
• OCSP Stapling: SCTs included in stapled OCSP response

4. Monitors: Services that watch CT logs for certificates affecting specific domains:

• Domain owners run monitors or use services
• Alert when any certificate is logged for their domains
• Enables rapid detection of misissuance

CT Enforcement:

Chrome requires SCTs for all certificates issued after April 2018. Certificates without valid SCTs from multiple logs are rejected. This makes CT mandatory for web certificates, not optional.

Certificate Transparency augments but doesn't replace the CA system. Additional mechanisms provide defense-in-depth against certificate misissuance.

CAA (Certificate Authority Authorization):

DNS records that specify which CAs are authorized to issue certificates for a domain:

; Only DigiCert and Let's Encrypt may issue
example.com.  CAA  0 issue "digicert.com"
example.com.  CAA  0 issue "letsencrypt.org"

; No wildcard certificates allowed
example.com.  CAA  0 issuewild ";"

; Report violations to security team
example.com.  CAA  0 iodef "mailto:security@example.com"

CAs are required to check CAA before issuance. Violating CAA isn't cryptographically prevented but creates clear CA compliance failures.

DANE (DNS-Based Authentication of Named Entities):

TLSA DNS records specify exactly which certificates are valid for a domain:

; Pin the exact certificate for www.example.com
_443._tcp.www.example.com. TLSA 3 1 1 <SHA-256 hash of certificate>

; Usage field options:
; 0 - PKIX-TA: Pin a CA certificate
; 1 - PKIX-EE: Pin end-entity with PKIX validation
; 2 - DANE-TA: Trust anchor assertion (no PKIX)
; 3 - DANE-EE: Pin specific certificate (no PKIX)

DANE Limitations:

• Requires DNSSEC (not universally deployed)
• Limited client support (no major browsers implement)
• Useful for email (SMTP) where server-to-server trust is simpler

HTTP Public Key Pinning (HPKP) — A Cautionary Tale:

HPKP allowed sites to tell browsers to accept only specific public key pins:

Public-Key-Pins: pin-sha256="base64+hash"; max-age=5184000;
                 pin-sha256="base64+backup-hash";

Why It Was Removed:

• Misconfiguration could permanently lock users out of a site
• Pin expiry outlasted some site lifetimes
• Attackers could maliciously set pins (ransom attacks)
• Operational complexity was extreme

HPKP was deprecated and removed from browsers in 2020. The lesson: mechanisms that can cause permanent self-denial-of-service are operationally unacceptable.

Expect-CT Header:

Expect-CT: max-age=86400, enforce, report-uri="https://example.com/ct-report"

Signals that the site expects CT enforcement. Useful during transition to mandatory CT and for gathering compliance reports.

Certificate Authorities form the trust foundation for secure communication on the internet. While imperfect, the CA system—augmented by Certificate Transparency and other mechanisms—enables billions of secure connections daily.

What's Next:

With trust established through certificate authentication, secure channels require another critical component: key exchange. The next page explores the cryptographic protocols that enable two parties to establish shared secrets over public channels, even when eavesdroppers observe every message.