What is a Certificate Authority (CA)

Key Takeaways

A CA signs public keys to vouch for identity — browsers trust certificates that chain to known roots

Root CAs stay offline; Intermediate CAs handle daily issuance

CA compromise (like DigiNotar 2011) invalidates every certificate ever issued by that CA

Private CAs are used for internal mTLS, VPN, Wi-Fi auth — not trusted by public browsers

A Certificate Authority (CA) is an entity that issues digital certificates. It vouches for the identity of a server, user, or device by signing their public key with its own private key. Browsers and operating systems ship with a pre-installed list of trusted Root CAs — if your certificate chains back to one of those roots, it’s trusted automatically.

Why it matters

Trust anchor — the entire HTTPS ecosystem depends on CAs. No CA signature = browser shows “Not Secure”
Identity binding — proves that bank.com is actually operated by the bank, not an attacker
Hierarchy — enables delegation (Root CA → Intermediate CA → End Entity) so the root key stays protected
Revocation — CAs can revoke compromised certificates, signaling to clients “don’t trust this anymore”
Policy enforcement — CAs enforce rules about key sizes, validity periods, and domain validation

How it works

Applicant generates a key pair and creates a Certificate Signing Request (CSR)
CSR is submitted to the CA with proof of domain ownership (DNS record, HTTP challenge, or manual verification)
CA validates the request against its Certificate Practice Statement (CPS)
CA signs the applicant’s public key with its own private key → produces the certificate
Applicant installs the signed certificate on their server
Clients verify the signature chain: End Entity → Intermediate CA → Root CA (in their trust store)

In real systems

Public CAs (DigiCert, Let’s Encrypt, Sectigo) — issue certificates trusted by all browsers. Used for public-facing websites and APIs. Let’s Encrypt automates this via ACME protocol for free.

Private/Enterprise CAs (Microsoft AD CS, EJBCA, QCecuring PKI) — issue certificates for internal systems. Not trusted by public browsers, but trusted within your organization’s devices. Used for mTLS, internal APIs, Wi-Fi auth, VPN, code signing.

Cloud CAs (AWS Private CA, Google CAS) — managed private CA infrastructure. You define the hierarchy, the cloud provider handles availability and HSM-backed key storage.

Types of Certificate Authorities

Public CA — trusted by all browsers/OS by default. Used for external-facing TLS. You don’t control the root.
Private CA — trusted only within your organization. You own the root. Used for internal mTLS, device auth, code signing.
Cloud-managed CA — private CA hosted by a cloud provider (AWS Private CA, Google CAS). You define policy, they handle infra + HSM.
Intermediate/Issuing CA — subordinate to a Root CA. Does the daily signing work. Can be revoked without destroying the root.

Where it breaks

CA compromise — if a CA’s private key is stolen, every certificate it ever issued is suspect. This happened to DigiNotar (2011) — the entire CA was shut down permanently. This is why Root CAs stay offline.

Over-trusting public CAs — your browser trusts ~150 Root CAs by default. Any one of them could theoretically issue a certificate for your domain. Certificate Transparency (CT) logs exist to detect this, but it’s a reactive control, not preventive.

Operational insight

Certificate Transparency (CT) means any publicly-trusted CA can issue a certificate for your domain — and you’ll only find out after the fact by monitoring CT logs. This isn’t theoretical: misissued certificates have been caught via CT for Google, Facebook, and government domains. If you operate sensitive domains, CT log monitoring is the only proactive defense against rogue or compromised CAs issuing certificates you didn’t request.