Certificate Authorities and PKI

Summary

This chapter examines the centralized trust model built on certificate authorities and public key infrastructure. Students will learn how X.509 certificates establish identity, how certificate chains create hierarchies of trust, and critically, where this model is vulnerable. Understanding PKI strengths and weaknesses is essential for later evaluating whether blockchain offers genuine improvements or merely shifts the trust problem.

Concepts Covered

This chapter covers the following 13 concepts from the learning graph:

Certificate Authority
Public Key Infrastructure
X.509 Certificate
Certificate Chain
Root Certificate
Certificate Revocation
CA Vulnerabilities
CA Compromise Scenarios
Trust Anchor
Centralized Trust
Traditional PKI vs DLT
Centralized Database
Alternative Technologies

Prerequisites

This chapter builds on concepts from:

Rex Says: Trust, but Verify!

Rex welcomes you Welcome back, fellow analysts! Before we examine blockchain's claims, we need to understand the system it proposes to replace. Certificate authorities and PKI have secured internet commerce for over two decades, serving billions of users. They have real strengths and real weaknesses — and understanding both is essential for honest technology evaluation. Trust, but verify!

Learning Objectives

After completing this chapter, you will be able to:

Explain the role of certificate authorities in establishing digital trust
Describe the structure and contents of an X.509 certificate
Trace how certificate chains create hierarchies of trust from root to end-entity
Explain how certificate revocation works and why it is challenging
Identify the key vulnerabilities and compromise scenarios in CA-based systems
Compare centralized trust (PKI) with distributed alternatives at a structural level
Evaluate when a centralized database is sufficient and when alternative technologies add value

Certificate Authorities

A certificate authority (CA) is a trusted third party that verifies the identity of entities (individuals, organizations, or devices) and issues digital certificates binding their identity to their public key. The CA acts as a notary for the digital world — its signature on a certificate is a formal statement: "I have verified that this public key belongs to this entity."

When you visit a website using HTTPS, your browser checks the site's certificate to confirm two things: that the certificate was issued by a CA your browser trusts, and that the certificate matches the domain you're visiting. This process happens transparently — millions of certificate verifications occur every second across the internet.

The CA model solves the identity verification problem from Chapter 3 through centralized authority: rather than requiring every party to independently verify every other party's identity, all parties agree to trust a small set of CAs. This dramatically reduces complexity.

Role	Responsibility
Root CA	Issues certificates to intermediate CAs; its key is the ultimate trust anchor
Intermediate CA	Issues end-entity certificates; insulates the root key from daily operations
Registration Authority	Verifies applicant identity before the CA issues a certificate
End Entity	The website, person, or device that receives and uses the certificate

Public Key Infrastructure

Public key infrastructure (PKI) is the complete ecosystem of hardware, software, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. PKI is not a single technology — it is an operational framework that includes:

Certificate authorities that issue and manage certificates
Registration authorities that verify identities before certificate issuance
Certificate repositories that store and distribute certificates
Revocation mechanisms (CRLs and OCSP) that handle compromised certificates
Policies and practices documented in Certificate Practice Statements (CPS)

The strength of PKI lies in its maturity. It has been refined over more than 25 years, is governed by well-understood standards, is supported by extensive legal frameworks, and operates at internet scale. Every HTTPS connection, every signed email, and every code signing operation relies on PKI.

X.509 Certificates

The X.509 certificate is the standard format for digital certificates used in PKI. An X.509 certificate is a digitally signed document that binds a public key to an identity. It contains:

Subject — the identity of the certificate holder (domain name, organization, or individual)
Public key — the certificate holder's public key
Issuer — the CA that issued the certificate
Validity period — the dates between which the certificate is valid
Serial number — a unique identifier assigned by the CA
Signature algorithm — the cryptographic algorithm used by the CA to sign the certificate
Digital signature — the CA's signature over all the above fields

Reading a Certificate

When you click the padlock icon in your browser's address bar, you can view the site's X.509 certificate. You'll see the subject (the domain name), the issuer (the CA), the validity dates, and the public key. The browser verifies the CA's signature using the CA's public key and checks that the domain matches the certificate's subject. This entire process takes milliseconds.

Certificate Chains and Root Certificates

A certificate chain (also called a chain of trust) is a sequence of certificates where each certificate is signed by the next certificate's private key, forming a path from the end-entity certificate to a trusted root certificate.

The chain typically has three levels:

Root certificate — self-signed by the root CA; pre-installed in operating systems and browsers
Intermediate certificate — signed by the root CA; signs end-entity certificates
End-entity certificate — signed by the intermediate CA; used by the website or service

The root certificate is the trust anchor — the foundational point of trust for the entire chain. Operating systems and browsers ship with a curated set of trusted root certificates (typically 100-200 root CAs). Every certificate chain must terminate at one of these pre-trusted roots for the browser to accept it.

Key Insight

Rex is thinking The entire PKI model ultimately rests on a set of root certificates that someone decided to trust. Your browser's root store was curated by Mozilla, Google, Apple, or Microsoft — not by you. This is centralized trust in its purest form: you trust the browser vendor, who trusts the root CAs, who trust the intermediate CAs, who vouch for the end entity. It works remarkably well in practice, but it is important to understand what you're actually trusting.

Diagram: Certificate Chain of Trust

Interactive Certificate Chain Visualization

Type: MicroSim sim-id: certificate-chain-trust
Library: p5.js
Status: Specified

Learning objective: Understand (L2) — Explain how certificate chains create hierarchies of trust from root certificates to end-entity certificates, and how verification traverses the chain.

Description: An interactive vertical visualization showing a three-level certificate chain: Root CA at the top, Intermediate CA in the middle, End-Entity (website) at the bottom. Each certificate is shown as a card displaying: subject, issuer, public key (abbreviated), and digital signature. Animated arrows show the signing relationships (downward) and verification path (upward). Clicking any certificate card expands it to show full details. A "Verify Chain" button animates the verification process step by step from end-entity up to root, showing green checkmarks at each successful step. A "Break Chain" button simulates an invalid intermediate certificate, showing where verification fails.

Canvas: Responsive width, 550px height. Background: aliceblue.

Controls:

Click certificate cards to expand details
"Verify Chain" button for step-by-step animation
"Break Chain" button to simulate invalid certificate
"Reset" button

Visual elements:

3 certificate cards stacked vertically with connecting arrows
Each card: subject, issuer, key icon, signature icon
Green glow on verified certificates, red glow on failed
Animation showing signature verification at each step
Legend explaining each certificate field

Implementation: p5.js with card layout, click expansion, animation sequence

Certificate Revocation

Certificate revocation is the process of invalidating a certificate before its expiration date — typically because the private key has been compromised, the certificate was issued erroneously, or the entity's information has changed. Revocation is one of PKI's most challenging operational problems.

Two primary revocation mechanisms exist:

Certificate Revocation Lists (CRLs) — the CA publishes a periodically updated list of revoked certificate serial numbers. Clients download the CRL and check whether a certificate appears on it.
Online Certificate Status Protocol (OCSP) — the client queries the CA in real-time to check whether a specific certificate is still valid.

Both mechanisms have significant limitations:

Mechanism	Advantage	Limitation
CRL	Works offline after download	Lists grow large; update delays create vulnerability windows
OCSP	Real-time status check	Adds latency; CA sees every site you visit (privacy concern); OCSP server becomes a single point of failure

In practice, most browsers have adopted OCSP stapling — where the web server itself obtains a time-stamped OCSP response and "staples" it to the TLS handshake, reducing latency and privacy concerns. However, revocation remains imperfect: many clients fail to check revocation status at all, defaulting to "soft fail" (accepting the certificate if the revocation check fails).

CA Vulnerabilities and Compromise Scenarios

No technology assessment is complete without understanding failure modes. CA vulnerabilities include both technical weaknesses and governance failures.

Technical vulnerabilities:

Key compromise — if a CA's private key is stolen, the attacker can issue fraudulent certificates for any domain
Weak validation — domain validation (DV) certificates verify only that the applicant controls the domain, not the identity of the organization behind it
Algorithm weaknesses — certificates using deprecated algorithms (MD5, SHA-1) can be forged

Governance and operational failures:

Mis-issuance — CAs issuing certificates to the wrong parties due to procedural failures
Government coercion — authorities compelling CAs to issue surveillance certificates
Rogue CAs — CAs that deliberately issue fraudulent certificates

CA compromise scenarios have occurred in practice:

Real-World CA Compromises

DigiNotar (2011): A Dutch CA was hacked, and the attacker issued fraudulent Google certificates used to intercept Gmail traffic in Iran. DigiNotar was removed from all browser trust stores and went bankrupt.

Symantec (2015-2017): Google discovered that Symantec had mis-issued over 30,000 certificates. After a prolonged dispute, Google Chrome progressively distrusted all Symantec-issued certificates, forcing Symantec to sell its CA business to DigiCert.

These incidents demonstrate a structural vulnerability of centralized trust: when a CA fails, the consequences can affect millions of users simultaneously. This is one of the legitimate motivations for exploring distributed trust alternatives — but the skeptic asks whether the proposed alternatives actually eliminate this class of risk or merely introduce different ones.

Bias Alert

Rex warns you Blockchain proponents often cite CA compromises as evidence that centralized trust is fundamentally broken. But notice the system's response: the compromised CAs were detected, removed from trust stores, and in DigiNotar's case, went bankrupt. The PKI ecosystem has self-correcting mechanisms. Ask whether proposed alternatives have equivalent mechanisms for responding to failures.

Traditional PKI vs Distributed Ledger Technology

The comparison between traditional PKI and distributed ledger technology (DLT) is central to this course's analytical framework. Both systems aim to solve the same problem — binding public keys to identities — but through fundamentally different architectures.

Dimension	Traditional PKI	Distributed Ledger
Trust model	Centralized (trust the CA)	Distributed (trust the protocol/majority)
Identity verification	CA verifies identity before issuing certificate	Self-asserted or community-verified
Revocation	CRL/OCSP (imperfect but functional)	Immutable records — revocation is architecturally difficult
Cost per verification	Fractions of a cent	Varies widely; PoW can be very expensive
Throughput	Thousands of verifications per second	Limited by consensus mechanism
Latency	Milliseconds	Seconds to minutes (block confirmation time)
Legal framework	Well-established across jurisdictions	Evolving, uncertain in many jurisdictions
Failure mode	CA compromise affects all certificates it issued	51% attack or protocol-level vulnerability

Centralized Databases as an Alternative

Before reaching for blockchain, it is worth asking: would a centralized database solve the problem? A well-designed centralized database with proper access controls, audit logging, and backup procedures addresses many of the same requirements that blockchain proponents cite:

Data integrity — achieved through checksums, write-ahead logs, and replication
Access control — role-based permissions, authentication, audit trails
High availability — database clustering, failover, geographic replication
Performance — thousands to millions of transactions per second

The critical question is whether your use case specifically requires that no single entity controls the data. If all participants are within one organization, or if a regulatory body can serve as the trusted authority, a centralized database is almost certainly cheaper, faster, and simpler than any blockchain alternative.

Rex's Tip

Rex shares a tip A useful heuristic: if you can identify a single entity that all participants would accept as the trusted authority, you probably don't need blockchain. The honest use case for blockchain is when no such entity exists and participants need to transact without trusting each other — a scenario that is less common than marketing materials suggest.

Key Takeaways

Certificate authorities solve the identity verification problem through centralized trust — a CA vouches for the binding between a public key and an identity
Public key infrastructure is the complete ecosystem of policies, technology, and operations that supports certificate-based trust
X.509 certificates are the standard format, containing subject, issuer, public key, validity, and the CA's signature
Certificate chains create hierarchies from root certificates (trust anchors) through intermediates to end-entity certificates
Certificate revocation is operationally challenging — CRLs are delayed and OCSP has privacy and availability concerns
CA vulnerabilities include key compromise, mis-issuance, and governance failures, with real-world examples like DigiNotar and Symantec
PKI vs. DLT is a tradeoff between centralized efficiency/accountability and distributed resilience/autonomy
Centralized databases often solve the same problems at lower cost and higher performance — blockchain is only justified when no trusted central authority exists

Excellent Analytical Work!

Rex celebrates You now understand the incumbent trust technology that blockchain proposes to supplement or replace. PKI is mature, fast, and legally established — but it has real vulnerabilities. The honest evaluation question isn't "is PKI perfect?" (it isn't) but "does the proposed alternative actually reduce risk at an acceptable cost?" Next, we enter the blockchain world itself. Outstanding work, fellow analyst!