Certificate Authorities and Trust Chains

Asymmetric encryption is only useful if you can trust that a public key actually belongs to whom you think it does. Without a trust mechanism, an attacker can intercept your request for someone's public key and substitute their own — a classic man-in-the-middle attack. Public Key Infrastructure (PKI) solves this trust problem by introducing a Certificate Authority (CA) — a trusted third party that digitally signs certificates binding public keys to verified identities. If you trust the CA, you can trust anyone the CA has certified.

A Certificate Authority (CA) is an organization that issues digital certificates after verifying the identity of the certificate requestor. The CA signs each certificate with its own private key, allowing anyone who trusts the CA to verify the certificate's authenticity using the CA's public key. There are two types: Public CAs (like DigiCert, GlobalSign, Let's Encrypt) whose root certificates are pre-installed in operating systems and browsers; and Private (Internal) CAs that organizations run themselves for internal certificate issuance (VPNs, internal services, device certificates).

A Root CA is the highest authority in a PKI hierarchy. Root CA certificates are self-signed — there is no higher authority to validate them. Instead, root certificates are trusted because operating system vendors (Microsoft, Apple, Mozilla) vet root CAs through rigorous auditing processes and pre-install their certificates in trusted certificate stores. There are approximately 130-150 trusted root CAs in a typical browser's trust store. If a root CA is compromised, every certificate it has ever issued becomes suspect — which is why root CA private keys are stored in offline, air-gapped hardware security modules (HSMs).

Root CAs rarely issue certificates directly to end entities. Instead, they create Intermediate CAs (also called subordinate CAs) by issuing certificates to intermediate CA operators. Intermediate CAs then issue end-entity certificates (like HTTPS server certificates). This delegation hierarchy serves several purposes: it protects root CA private keys by keeping them offline (if an intermediate CA is compromised, only its certificate chain is revoked, not the entire root); it allows specialized CAs for different use cases (code signing vs TLS); and it enables organizational hierarchy within private PKI.

A certificate chain (or chain of trust) is the sequence of certificates from the end-entity certificate back to the trusted root CA. For a typical HTTPS website, the chain is: End-entity cert (e.g., *.google.com) → Intermediate CA cert (e.g., Google Trust Services WR2) → Root CA cert (e.g., Google Trust Services LLC). When your browser visits a site, it validates this entire chain — checking that each certificate's signature was made by the level above it, and that the root is in the trusted store. Any break in this chain causes a certificate error.

When two separate PKI hierarchies need to establish mutual trust, they use cross-certification. Each CA issues a certificate to the other's root, establishing trust in both directions. A Bridge CA is a central hub CA that cross-certifies with multiple domain CAs, creating a web of trust across different organizations or government agencies. The US Federal Bridge CA connects multiple federal government PKI systems. Cross-certification is complex to manage but necessary when merging organizations or establishing inter-agency trust without collapsing into a single hierarchy.

A Registration Authority (RA) is an entity that performs identity verification on behalf of a CA but does not issue certificates itself. The RA receives certificate requests, verifies the applicant's identity (through document checks, domain validation, or in-person verification depending on the certificate type), and forwards approved requests to the CA for signing. This delegation allows CAs to scale their issuance without performing all verification themselves. In enterprise PKI, an RA might be the HR department or IT helpdesk that validates employee certificate requests.

CAs offer certificates at different validation levels reflecting how thoroughly the requester's identity was verified. Domain Validation (DV): CA verifies only that the requester controls the domain (automated, takes minutes, used by Let's Encrypt). Organization Validation (OV): CA verifies the organization's legal existence (1-3 business days). Extended Validation (EV): most thorough vetting — legal identity, physical address, operational existence (1-2 weeks, used to show the green company name in browser address bars). DV is fine for basic encryption; EV is appropriate for high-value targets like banking sites.

Certificate pinning is a technique where an application is hardcoded to trust only a specific certificate or CA, rather than any certificate from any trusted root CA. This prevents MITM attacks even if an attacker obtains a fraudulent certificate from a trusted CA. Mobile apps and security-sensitive applications use pinning to ensure they only accept their own servers' certificates. The downside: if the pinned certificate expires or is rotated, the application breaks until the app is updated. HPKP (HTTP Public Key Pinning) was a browser-based pinning mechanism that has been deprecated due to mis-deployment risks.

Organizations run their own private CA for internal certificate needs — authenticating VPN clients, issuing certificates for internal HTTPS services, signing code, and authenticating devices. Microsoft Active Directory Certificate Services (AD CS) is the most common enterprise private CA. Internal CA certificates must be distributed to all devices and browsers that need to trust internally issued certificates, typically via Group Policy. Private CAs cannot issue certificates that are trusted by the public internet — their use is limited to the organization's devices that have the private CA root installed.

The DigiNotar compromise (2011) is the most important CA incident for Security+ candidates to know. Dutch CA DigiNotar was breached by attackers who issued fraudulent certificates for Google, Mozilla, and government domains. These were used in Iran to perform man-in-the-middle attacks on citizens. The result: every major browser and OS vendor immediately removed DigiNotar from their trusted root stores, invalidating all certificates DigiNotar had ever issued. DigiNotar went bankrupt within weeks. This incident demonstrated that CA compromise is catastrophic and why CAA DNS records, Certificate Transparency, and multi-factor authentication for CA systems are now required.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: Certificate Authorities bind public keys to verified identities; the chain of trust runs from end-entity through intermediate CAs to a self-signed root; Root CAs are kept offline in HSMs and pre-trusted by OSes; and CA compromise (DigiNotar) can invalidate millions of certificates. Next up we explore X.509 Certificate Structure.