Certificates And Pki - Learning Module

Loading content...

0/228

Certificate Authority

The Gatekeepers of Digital Trust

In the physical world, we trust passports because governments issue them through rigorous verification processes. We trust notarized documents because notaries are licensed, bonded, and legally accountable. The digital world has its own equivalent: Certificate Authorities (CAs)—the gatekeepers that verify identities and issue the digital certificates enabling secure communications.

A Certificate Authority is an entity trusted to issue digital certificates that bind public keys to identities. When you connect to your bank's website and see the padlock indicating a secure connection, you're implicitly trusting that some CA properly verified the bank's identity before issuing their certificate.

But what makes a CA trustworthy? How do they verify identity? What happens when they fail? Understanding CAs is crucial for any security professional, because the entire web PKI (Public Key Infrastructure) rests on the assumption that CAs do their job correctly. History has shown, repeatedly, that this assumption requires constant vigilance.

What You Will Master

By the end of this page, you will understand how Certificate Authorities operate: their verification procedures, security requirements, the distinction between root and intermediate CAs, the process of becoming a trusted CA, and the consequences when CAs fail their trust obligations.

What is a Certificate Authority?

A Certificate Authority is an organization that performs three essential functions:

Identity Verification — Validates that certificate applicants are who they claim to be
Certificate Issuance — Creates and digitally signs X.509 certificates binding keys to verified identities
Lifecycle Management — Manages certificate renewal, revocation, and status reporting

At its core, a CA operates as a trusted third party. When your browser trusts a website's certificate, it's really trusting the CA's assertion that the certificate holder legitimately controls that domain.

The Technical Mechanics:

When a CA issues a certificate, it:

Receives a Certificate Signing Request (CSR) containing the applicant's public key and identity information
Performs verification appropriate to the validation level (DV, OV, or EV)
Creates a certificate containing the verified information
Signs the certificate using the CA's private key
Returns the signed certificate to the applicant

The CA's signature is the crucial element. Anyone can verify this signature using the CA's public key (contained in the CA's own certificate). If the signature is valid, the certificate is authentic—it was genuinely issued by that CA.

certificate-signing-request.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
# Generate a private key
openssl genrsa -out mydomain.key 2048
 
# Create a Certificate Signing Request
openssl req -new -key mydomain.key -out mydomain.csr \
    -subj "/CN=www.mydomain.com/O=My Organization/L=San Francisco/ST=California/C=US"
 
# View the CSR contents
openssl req -in mydomain.csr -text -noout
 
# CSR structure:
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: CN = www.mydomain.com, O = My Organization, L = San Francisco, ST = California, C = US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b4:5f:c3:a2:... (256 bytes)
                Exponent: 65537 (0x10001)
        Attributes:
            a]  Requested extensions are often included here
    Signature Algorithm: sha256WithRSAEncryption
         [Signature proving possession of private key]

The CSR Proves Key Possession

The CSR is signed with the applicant's private key. This proves the applicant possesses the corresponding private key—an essential security property. The CA never sees the private key; it only receives the public key and proof that the applicant can sign with the private key.

Types of Certificate Authorities

CAs exist in a hierarchical structure. Understanding this hierarchy is essential for comprehending how trust flows through the PKI system.

Root CAs:

A Root CA is the ultimate trust anchor. Its certificate is self-signed—the issuer and subject are the same entity. Root CA certificates are directly embedded in operating systems: and browsers (the "root store"). These certificates are implicitly trusted; no signature verification is possible because there's no higher authority.

Root CAs are extraordinarily security-sensitive. A compromised root CA can issue certificates for any domain, enabling undetectable MITM attacks against any website. Therefore, root CA private keys are protected with extreme measures:

Stored in Hardware Security Modules (HSMs) that never expose the key
Kept offline (air-gapped) except during signing ceremonies
Require multiple people with split key components to access
Subject to extensive auditing and physical security

Intermediate CAs (Subordinate CAs):

To reduce risk, root CAs rarely sign end-entity certificates directly. Instead, they sign certificates for Intermediate CAs, which then sign end-entity certificates. This creates a chain:

Root CA → Intermediate CA → End-Entity Certificate

Benefits of this architecture:

Root key exposure is minimized (used only to sign intermediates)
Intermediates can be revoked without replacing root stores
Different intermediates can have different policies or purposes
Operational flexibility without risking the root

Root vs. Intermediate Certificate Authorities
Characteristic	Root CA	Intermediate CA
Certificate Type	Self-signed	Signed by root or higher intermediate
Trust Source	Embedded in root stores	Derives trust from parent CA
Private Key Storage	HSM, offline, air-gapped	HSM, may be online for automation
Signing Frequency	Rare (years between signings)	Frequent (issues end-entity certs)
Compromise Impact	Catastrophic (affects all certs)	Serious but contained (revocable)
Validity Period	20-30 years typical	5-10 years typical
Revocation	Extremely difficult (root store updates)	Standard CRL/OCSP mechanisms

Registration Authorities (RAs):

Some CAs delegate identity verification to Registration Authorities. An RA performs the verification process but doesn't have signing keys—it submits approved requests to the CA for signing. This separation allows:

Geographic distribution (local RAs in different regions)
Specialized verification (enterprise RAs for employee certs)
Risk reduction (RA compromise doesn't expose signing keys)

Private/Enterprise CAs:

Organizations can run their own CAs for internal use. These are not trusted by the public internet but are deployed to corporate devices through enterprise management:

Issue certificates for internal services
Enable mutual TLS between microservices
Provide code signing for internal applications
Authenticate employees via smart cards or certificates

The Root Store Problem

A significant tension exists: for a CA to be useful, its root must be widely distributed. But updating root stores requires operating system or browser updates—a slow process. This means adding new CAs takes years, and removing compromised CAs is an emergency operation that may leave users unable to access sites.

How CAs Verify Identity

The value of a certificate depends entirely on the rigor of the CA's verification. Different validation levels require different procedures.

Domain Validation (DV):

DV is the simplest and most automated validation. The CA verifies only that the applicant controls the domain—not who they are. Methods include:

DV Verification Methods

•Email Validation — CA sends verification email to admin@domain.com or similar administrative addresses; applicant clicks link to prove access
•HTTP Validation — Applicant places CA-specified file at /.well-known/acme-challenge/[token]; CA retrieves it to prove domain control
•DNS Validation — Applicant creates TXT record with CA-specified value; CA queries DNS to verify
•TLS-ALPN Validation — Applicant configures server to present specific certificate during TLS handshake with special ALPN extension

acme-http-challenge-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# ACME HTTP-01 Challenge Example (Let's Encrypt)
 
# 1. CA provides a token and expected key authorization
Token: abc123def456
Key Authorization: abc123def456.thumbprint-of-account-key
 
# 2. Applicant places file at:
http://www.mydomain.com/.well-known/acme-challenge/abc123def456
 
# File contents:
abc123def456.thumb<print-of-account-key
 
# 3. CA makes HTTP request to verify
GET /.well-known/acme-challenge/abc123def456 HTTP/1.1
Host: www.mydomain.com
 
# 4. If response matches, domain control is proven
 
# DNS-01 Challenge Example
# CA provides token, applicant creates DNS record:
_acme-challenge.www.mydomain.com. TXT "dGVzdC12YWx1ZS1mb3ItZG5zLXByb29m"

Organization Validation (OV):

OV adds verification that the organization exists and is entitled to use the domain:

Domain control verification (same as DV)
Organization verification through:
- Government databases or registrations
- Third-party business databases (Dun & Bradstreet, etc.)
- Phone verification using published numbers
- Legal documentation review
Domain ownership verification — Confirm organization's right to the domain

Extended Validation (EV):

EV is the most rigorous validation, requiring:

All OV requirements, plus:
Legal existence verification — Incorporation documents, government records
Physical existence verification — Verified business address
Operational existence verification — Active business operations
Domain authorization verification — Documented authorization from domain owner
Authorization verification — Confirm the certificate requester is authorized to act for the organization
In-person or equivalent verification — Verify contact information through trusted channels
Subscriber agreement — Legal agreement accepting CA responsibilities

EV certificates typically take 1-5 business days to issue due to manual verification steps.

Baseline Requirements

The CA/Browser Forum publishes 'Baseline Requirements' that all publicly trusted CAs must follow. These specify minimum validation procedures, certificate contents, validity periods, and key sizes. CAs are audited against these requirements to maintain root store inclusion.

CA Security and Operational Requirements

CAs must maintain extraordinarily high security standards. A CA compromise would undermine trust in the entire PKI. The industry has developed comprehensive requirements that CAs must meet.

Physical Security:

Root CA keys are protected with military-grade physical security:

Hardware Security Modules (HSMs) rated FIPS 140-2 Level 3 or higher
Secure rooms with biometric access control
Video surveillance with retention requirements
Environmental controls (fire suppression, power backup)
Multi-person access requirements (no single person can access keys)

Ceremony Procedures:

Root CA private keys are used in formal "key ceremonies" with strict procedures:

Key Ceremony Requirements

•Advance scheduling — Ceremonies planned weeks in advance with detailed scripts
•Multiple parties required — Typically 3-5 key holders, each with a portion of activation credentials
•Independent witness — Qualified auditor observes and documents all actions
•Video recording — Entire ceremony is recorded and archived
•Tamper-evident controls — HSMs and keys are sealed with tamper-evident bags/seals
•Detailed logging — Every keystroke and action is logged with timestamps
•Air-gapped environment — Signing systems have no network connectivity

Auditing Requirements:

Publicly trusted CAs must undergo regular audits to maintain root store inclusion:

WebTrust for CAs:

Comprehensive audit program by AICPA/CPA Canada
Covers security, operational practices, and controls
Annual audit with publicly released report
Specific criteria for SSL/TLS certificate issuance

ETSI Standards:

European alternative to WebTrust
EN 319 401 (general CA requirements)
EN 319 411-1 (certificate policies)
Equivalent recognition for root store programs

Key Management Requirements:

CA Key Security Requirements
Requirement	Root CA	Intermediate CA	Rationale
Key Storage	HSM, FIPS 140-2 Level 3+	HSM, FIPS 140-2 Level 2+	Hardware protection prevents key extraction
Network Connectivity	Air-gapped (offline)	Can be online for automation	Reduces attack surface for most critical keys
Backup Key Storage	Multiple HSM copies in secure locations	HSM with geographic redundancy	Ensure key availability while maintaining security
Key Recovery	M-of-N key shareholders	Documented recovery procedures	Prevent single-point-of-failure while requiring multiple parties
Key Destruction	Documented, witnessed destruction	Secure deletion procedures	Ensure keys cannot be recovered after end-of-life

The Cost of CA Operations

Running a publicly trusted CA is expensive. HSMs cost tens of thousands of dollars. Audits cost hundreds of thousands annually. Secure facilities, trained staff, and insurance add to costs. This is why there are relatively few publicly trusted CAs, and why certificate prices historically reflected these costs (before Let's Encrypt changed the economics).

The Major Public Certificate Authorities

A handful of organizations dominate the public CA market. Understanding who they are and their market positions provides context for the PKI ecosystem.

Market Leaders:

Major Public Certificate Authorities
CA / Parent Company	Market Position	Notable Characteristics
DigiCert (includes Symantec, GeoTrust, Thawte)	Largest commercial CA	Enterprise focus, high-assurance certificates, acquired several legacy CAs
Let's Encrypt (ISRG)	Largest by volume	Free, automated, 90-day certificates, revolutionized DV issuance
Sectigo (formerly Comodo CA)	Major commercial CA	Wide product range, competitive pricing, strong in SMB market
GlobalSign	Enterprise CA	PKI solutions, IoT certificates, owned by GMO Internet
GoDaddy	Volume commercial CA	Bundled with hosting services, consumer-focused
Entrust	Government and enterprise	Strong in regulated industries, smart card / PKI solutions
IdenTrust	Specialized CA	Powers Let's Encrypt cross-sign, federal PKI bridge

Let's Encrypt: The Revolution:

Let's Encrypt, launched in 2016, fundamentally changed the CA landscape:

Before Let's Encrypt:

Certificates cost $50-$500+ per year
Manual verification and issuance processes
Renewal required human intervention
HTTPS was a premium feature

After Let's Encrypt:

Free DV certificates for anyone
Fully automated issuance via ACME protocol
90-day validity encourages automation
HTTPS became the default expectation

Today, Let's Encrypt issues over 3 million certificates daily and secures a majority of the web's encrypted connections. Their success proved that the barrier to HTTPS was primarily cost and complexity, not technical capability.

Government CAs:

Many governments operate their own CAs for internal use:

U.S. Federal PKI — Certificates for federal agencies and employees
Estonian SK ID Solutions — Powers Estonia's e-identity system
India CCA — Root for Indian government PKI

Government CAs are typically not in public root stores but are distributed through government-controlled systems.

CA Consolidation Risks

The CA market has consolidated significantly through acquisitions. DigiCert acquired Symantec's CA business, Thawte, and GeoTrust. This concentration creates systemic risk—a problem at a major CA affects a large portion of the web. It also raises concerns about pricing power and innovation.

How to Become a Publicly Trusted CA

Becoming a publicly trusted CA is a multi-year, multi-million dollar endeavor. The process is deliberately arduous to ensure only well-resourced, committed organizations can issue publicly trusted certificates.

The Path to Trust:

Steps to Becoming a Trusted CA

•Infrastructure Investment — Build secure facilities, acquire HSMs, establish redundant systems, hire qualified staff. Initial investment: $2-10 million.
•Policy Development — Create comprehensive Certificate Policy (CP) and Certification Practice Statement (CPS) documents. These must meet CAB Forum Baseline Requirements.
•Operational Procedures — Develop and implement all verification, issuance, revocation, and security procedures. Staff must be trained and procedures tested.
•Initial Audit — Pass WebTrust for CAs audit or equivalent. Auditor verifies all controls are in place and operating effectively.
•Root Program Application — Apply to each root program separately (Mozilla, Microsoft, Apple, Google). Each has different requirements and review processes.
•Review Period — Detailed review of policies, procedures, and audit reports. May include public discussion period (Mozilla has community review).
•Gradual Trust — Initial inclusion may be limited (e.g., email only, notBefore restrictions). Full trust is granted after demonstrated track record.
•Ongoing Compliance — Annual audits, continuous monitoring, prompt incident response. Any failure can result in removal from root programs.

Root Program Requirements:

Each major root program has its own requirements:

Mozilla Root Store Policy:

Public discussion of inclusion request
Community can raise objections
Detailed technical requirements
Transparency requirements (Certificate Transparency logging)

Microsoft Root Certificate Program:

Requires annual audit (WebTrust or equivalent)
Technical requirements for algorithms and key sizes
Business stability requirements
USD $75,000-$150,000 annual program fee

Apple Root Certificate Program:

Aligned with Mozilla requirements
Additional requirements for specific certificate types
Focus on compliance track record

Google Chrome Root Program:

Stricter than baseline requirements
Certificate Transparency mandatory
Moving toward own root store (CCADB-based)

Timeline:

The entire process typically takes 3-5 years from decision to inclusion:

1-2 years: Building infrastructure and processes
6-12 months: Achieving audit certification
1-3 years: Root program review and gradual inclusion

The Cross-Sign Shortcut

New CAs often accelerate trust by getting their root cross-signed by an existing trusted CA. This provides immediate trust while their own root propagates through root stores. Let's Encrypt's ISRG Root was cross-signed by IdenTrust's DST Root CA X3 for exactly this reason.

When CAs Fail: Notable Incidents

CA failures demonstrate why the trust model requires vigilance. Historical incidents have shaped current requirements and have led to CA removals from root stores.

DigiNotar (2011) — Complete CA Compromise:

DigiNotar: A Cautionary Tale

In 2011, attackers completely compromised DigiNotar's CA infrastructure, issuing over 500 fraudulent certificates including one for *.google.com. The fake Google certificate was used to intercept Iranian users' Gmail traffic. DigiNotar was removed from all root stores within weeks and the company declared bankruptcy shortly after. This single incident led to massive improvements in CA security requirements.

What Went Wrong at DigiNotar:

Weak infrastructure security (outdated software, no intrusion detection)
All CA systems on a single network (no segmentation)
Delayed detection (compromise went unnoticed for weeks)
Poor incident response (initially downplayed severity)

Symantec (2015-2017) — Systematic Mis-issuance:

Symantec, then the world's largest CA, was found to have:

Issued test certificates for domains they didn't control (including google.com)
Failed to verify domain ownership in thousands of cases
Allowed partners to issue certificates without proper oversight
Repeatedly failed to meet commitments for improvement

Google Chrome progressively distrusted Symantec certificates, forcing a sale to DigiCert and complete reissuance of all certificates—affecting millions of websites.

WoSign/StartCom (2016) — Backdating and Deception:

WoSign Violations

•Backdating certificates — Issued SHA-1 certificates after the deadline by backdating notBefore to appear compliant
•Secret acquisition — Acquired StartCom CA without disclosure, violating transparency requirements
•Mis-issuance — Issued certificates without proper domain validation
•Deception — Provided misleading information to browser vendors during investigation

Mozilla completely removed WoSign and StartCom from their trust store—a death sentence for a public CA.

Lessons Learned:

These incidents drove major improvements:

Certificate Transparency (CT) — All certificates must be logged to public logs, enabling detection of mis-issuance
CAA Records — DNS records specify which CAs can issue for a domain
Stricter Baseline Requirements — More prescriptive rules, fewer areas of CA discretion
Faster Distrust Mechanisms — OneCRL, CRLSets allow rapid certificate blocking
Public Disclosure — Incidents must be publicly disclosed and discussed
Accountability — CAs face real consequences for violations (removal from root stores)

Summary: Certificate Authorities Mastered

Certificate Authorities are the trust anchors of internet security. Let's consolidate the essential knowledge:

Key Takeaways

•CAs verify identity and sign certificates — They are trusted third parties that vouch for the binding between keys and identities
•Root CAs anchor trust — Self-signed certificates in root stores are implicitly trusted; their security is paramount
•Intermediate CAs protect roots — Hierarchical structure minimizes root key exposure while enabling operational flexibility
•Validation levels matter — DV proves domain control; OV verifies organization; EV provides highest assurance
•Rigorous security is mandatory — HSMs, key ceremonies, audits, and compliance programs ensure CA trustworthiness
•Consequences are real — CAs that fail their obligations face removal from root stores, effectively destroying their business

What's Next:

We've seen how individual CAs operate. But how does trust flow when certificates are signed by intermediates that are signed by roots? The next page explores the Chain of Trust—the mechanism by which your browser verifies an arbitrary certificate by tracing it back to a trusted root.

Page Complete

You now understand Certificate Authorities in depth: their verification procedures, security requirements, the major players, and the consequences of failure. This knowledge is essential for understanding why we trust certificates and what risks exist in the current PKI model. Next, we explore how Chain of Trust verification works.