Certificate Authority

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.

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

1. Identity Verification — Validates that certificate applicants are who they claim to be
2. Certificate Issuance — Creates and digitally signs X.509 certificates binding keys to verified identities
3. 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:

1. Receives a Certificate Signing Request (CSR) containing the applicant's public key and identity information
2. Performs verification appropriate to the validation level (DV, OV, or EV)
3. Creates a certificate containing the verified information
4. Signs the certificate using the CA's private key
5. 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.

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

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 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:

Organization Validation (OV):

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

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

Extended Validation (EV):

EV is the most rigorous validation, requiring:

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

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

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:

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:

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:

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.

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:

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

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:

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:

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

Lessons Learned:

These incidents drove major improvements:

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