Certificate Authorities
In short: Trusted organisations (certificate authorities, CAs) that issue digital certificates and confirm them with their own signature.
In more detail: Before a CA issues a certificate, it checks (more or less strictly, depending on the certificate type) whether the applicant really has control over the relevant domain/organisation. Browsers and operating systems trust a predefined list of root CAs — every certificate that can be traced back to one of these root CAs (certificate chain) is considered trustworthy. Well-known CAs: Let’s Encrypt (free, automated), DigiCert.
In Depth
CAs form a hierarchical trust structure:
Root CA (extremely strictly protected private key, rarely used directly)
|
v
Intermediate CA (signs on behalf of the root CA)
|
v
Server certificate (e.g. emzett-digital.com, signed by the intermediate CA)
Root CAs practically never use their own, highly sensitive private key directly for everyday server certificates — the key is often physically separated from the internet (“air-gapped”) and is only used, rarely, to authorise new intermediate CAs. These intermediate CAs handle the day-to-day operational business, so that in the (rare) case of a compromised intermediate certificate, only that one has to be revoked, instead of endangering the much more valuable root CA itself.
Let’s Encrypt has fundamentally changed the landscape since 2016: previously, certificates often cost money and issuance was a manual, multi-day process — Let’s Encrypt offers free, fully automated domain-validation certificates that are automatically renewed every few months via a script (e.g. certbot). This has contributed decisively to HTTPS being the standard for practically every website today, no longer the exception reserved for banks and shops.
If a CA itself is compromised (e.g. hacked, or fraudulently issues a certificate for someone else’s domain), browsers and operating systems, in serious cases, lose trust in the entire CA and remove it from their trusted root list — an incident that has, in the past, already effectively driven whole CAs out of business several times, because suddenly no browser accepted their certificates any more.
How CAs work financially
Before Let’s Encrypt, certificate authorities financed themselves almost exclusively through direct fees for issued certificates, tiered by depth of verification — a simple domain-validation certificate cost considerably less than an elaborately verified extended-validation certificate for a bank. Let’s Encrypt, by contrast, finances itself as a non-profit organisation through donations from large technology companies (Mozilla, Google and Cisco, among others, were early supporters), who have a shared interest in an encrypted web accessible to everyone. Commercial CAs continue to exist in parallel and today mainly differentiate themselves through additional services (support, warranty coverage for mis-issuance, higher verification levels such as extended validation), which remain relevant for companies with particular compliance requirements, even though the pure technical encryption provided by a free Let’s Encrypt certificate would be just as strong.
Revoking a certificate
If a certificate has to be invalidated before its regular validity period expires (e.g. because the associated private key was stolen), CAs have two mechanisms available: certificate revocation lists (CRLs) are regularly updated lists of revoked certificates that clients can download and check against. OCSP (Online Certificate Status Protocol) instead allows a live query directly to the CA about whether a particular certificate is still valid. Both methods have practical weaknesses — CRLs can become outdated in the time between updates, OCSP queries slow down every connection setup and theoretically give the CA insight into which websites a user visits — modern browsers therefore increasingly rely on “OCSP stapling”, where the server itself directly supplies the current OCSP status, without the client having to contact the CA separately.
See also: Certificate, Authenticity