We’ve covered why trust is hard, how identity works, and the cryptography underneath it all. Now we put the pieces together. Digital certificates are the mechanism that lets your browser trust your bank’s website, that lets your phone verify an app update is genuine, and that lets two servers communicate securely without ever having met. They’re the connective tissue of internet trust, and understanding how they work reveals just how fragile that trust can be.
The problem certificates solve
You connect to your bank’s website. You need two things to happen: the connection needs to be encrypted (so nobody can read your account details) and you need to be sure you’re actually talking to your bank (not an impostor). Encryption without authentication is worse than useless, it gives you the feeling of security while potentially sending all your data to an attacker.
As we saw in How Encryption Works, public-key cryptography lets you encrypt data with someone’s public key. But how do you know that the public key you’re using actually belongs to your bank? Anyone can generate a key pair and claim to be “Commonwealth Bank” or “Barclays.” The key itself carries no identity information. It’s just a number.
This is the binding problem: associating a public key with a real-world identity. Certificates solve it by introducing a trusted third party who vouches for the binding.
What a certificate actually is
A digital certificate is a data structure, typically following the X.509 standard (first defined in 1988 by the ITU-T, now at version 3), that contains:
- The subject: who the certificate identifies (e.g., “www.example.com” or “Example Corporation Pty Ltd”)
- The public key: the subject’s public key
- The issuer: who signed the certificate (the certificate authority)
- The validity period: start date and expiry date
- A serial number: unique identifier
- Extensions: additional constraints and information
- The digital signature: the issuer’s signature over all of the above
The signature is the critical part. It says: “I, the issuer, have verified that this public key belongs to this subject, and I stake my reputation on it.” Anyone who trusts the issuer can trust the certificate. The signature also provides integrity, if any field is altered after signing, the signature won’t validate.
If you want to look at a real certificate, your browser will show you. Navigate to any HTTPS site, click the padlock (or its equivalent, browsers keep redesigning this), and inspect the certificate. You’ll see the subject, the issuer, the validity period, the public key, and the signature algorithm. It’s surprisingly readable.
The chain of trust
Your browser doesn’t trust individual website certificates directly. It trusts root certificates, a small number of certificates from organisations called certificate authorities (CAs) that are pre-installed in your operating system or browser. As of early 2026, a typical browser trusts somewhere between 50 and 150 root CAs, maintained in what’s called a trust store.
But root CAs almost never sign website certificates directly. Instead, they sign intermediate certificates, and the intermediates sign the end-entity (website) certificates. This creates a chain of trust:
Root CA → Intermediate CA → Website certificate
When your browser connects to a website, the server sends its certificate and the intermediate certificate(s). Your browser validates the chain: it checks that the website certificate was signed by the intermediate CA, that the intermediate CA’s certificate was signed by the root CA, and that the root CA is in its trust store. If every link checks out, the padlock appears.
Why the indirection? Two reasons. First, security: the root CA’s private key is extraordinarily valuable. If it’s compromised, every certificate it has ever issued is suspect. Root CA keys are typically stored in hardware security modules (HSMs) kept in physically secured, air-gapped environments, some literally in underground vaults. Using intermediates means the root key is only used occasionally (to sign new intermediates), minimising its exposure. If an intermediate is compromised, the root can revoke it without replacing itself.
Second, operational flexibility: intermediates can have different policies, different lifetimes, and different purposes. A root CA might have one intermediate for web server certificates, another for email encryption, another for code signing. Each can be managed independently.
How certificate authorities verify identity
Not all certificates are created equal. The level of verification ranges from “almost none” to “extensive,” and the difference matters.
Domain Validation (DV) certificates require only proof that you control the domain. The CA sends a challenge, typically an email to admin@yourdomain.com, or a request to place a specific file at a specific URL, or a DNS TXT record, and if you respond correctly, you get a certificate. No human reviews anything. No identity is verified beyond domain control. This is what Let’s Encrypt issues, and it’s sufficient for encryption and basic authentication (you’re talking to whoever controls this domain). DV certificates are free and can be issued in seconds.
Organisation Validation (OV) certificates require the CA to verify that the requesting organisation exists and controls the domain. This involves checking business registries, phone verification, and sometimes physical mail. It takes days rather than seconds. The certificate includes the organisation’s verified name.
Extended Validation (EV) certificates require the most thorough verification: legal existence, operational existence, physical address, authority of the person requesting the certificate, and more. EV certificates were introduced in 2007 with the idea that browsers would display the organisation name prominently, the green address bar. The theory was that users would learn to look for the green bar when entering sensitive information.
In practice, EV certificates haven’t achieved their goal. Research by Google’s security team (2019) found that users overwhelmingly ignored the EV indicators. Chrome removed the green bar in 2019. Firefox followed. The visual distinction between DV and EV is now effectively gone from mainstream browsers. The security community largely considers EV a well-intentioned experiment that failed because it relied on user behaviour that didn’t materialise.
Let’s Encrypt and the encryption of everything
Before 2015, getting a TLS certificate meant paying money, waiting hours or days, and working through a manual process. The cheapest DV certificates cost $10-20 per year. The friction was real, and the result was that vast swaths of the web, particularly small sites, personal blogs, and sites in developing countries, were unencrypted. HTTP, not HTTPS.
Let’s Encrypt launched its public beta in December 2015 as a free, automated, open certificate authority, run by the nonprofit Internet Security Research Group (ISRG). Its ACME protocol (Automated Certificate Management Environment, RFC 8555) fully automates certificate issuance and renewal. A server proves domain control, receives a DV certificate, and installs it, all without human intervention, all in seconds, all free.
The impact was transformative. In November 2015, roughly 40% of web page loads in Firefox used HTTPS. By early 2026, that number exceeds 95%. Let’s Encrypt alone has issued over 4 billion certificates since launch. The project changed the economics of TLS: the cost dropped from “nonzero” to “zero,” and the effort dropped from “annoying” to “automatic.”
Let’s Encrypt certificates are valid for 90 days, deliberately short. The reasoning: shorter lifetimes limit the damage from a compromised key (the attacker’s window is 90 days, not a year), and force automation (you can’t manually renew every 90 days without losing your mind, so you automate it, which is more reliable than manual renewal anyway). The short lifetime was controversial at launch and is now widely considered a good design decision.
The trust chain for Let’s Encrypt is itself an interesting story. When it launched, Let’s Encrypt needed its certificates to be trusted by browsers. A new root CA isn’t in anyone’s trust store, so Let’s Encrypt initially cross-signed its intermediate certificate with an existing root CA (IdenTrust’s DST Root CA X3). This meant that even though Let’s Encrypt’s own root (ISRG Root X1) wasn’t yet widely trusted, its certificates chained up to IdenTrust’s root, which was. Over the following years, ISRG Root X1 was added to all major trust stores. In September 2021, the cross-sign from DST Root CA X3 expired, causing problems for older devices (particularly those running Android 7.0 or earlier) that didn’t have ISRG Root X1 in their trust store. Let’s Encrypt engineered a creative workaround using an unusual cross-sign from a certificate that was technically expired but still trusted by older Android devices, a hack that worked because Android doesn’t enforce expiry on root certificates in its trust store.
Certificate Transparency: watching the watchers
The CA system has a fundamental problem: you have to trust the CAs not to issue fraudulent certificates. And CAs have, repeatedly, failed that trust.
The DigiNotar disaster (2011) is the most dramatic example. DigiNotar, a Dutch CA, was compromised by attackers who issued fraudulent certificates for google.com, mozilla.org, and dozens of other domains. The fraudulent Google certificate was used to intercept the Gmail traffic of users in Iran, likely by the Iranian government. The breach wasn’t discovered by DigiNotar; it was discovered by a user who noticed a certificate warning in Chrome. DigiNotar was removed from all browser trust stores and went bankrupt within months.
Other incidents followed. In 2015, the Chinese CA CNNIC issued an intermediate certificate to a company called MCS Holdings, which used it to issue certificates for domains it didn’t own, effectively a man-in-the-middle proxy. Google and Mozilla revoked trust in CNNIC. In 2015-2016, Symantec (the world’s largest CA at the time) was found to have issued over 30,000 certificates without proper validation, including test certificates for domains like google.com. Google began a graduated distrust of all Symantec-issued certificates, eventually resulting in Symantec selling its CA business to DigiCert.
The response to these failures was Certificate Transparency (CT), proposed by Google engineers Ben Laurie and Adam Langley and formalised in RFC 6962 (2013). The idea is simple: every certificate issued by a CA must be logged in a public, append-only, cryptographically verifiable log. Anyone can monitor the logs. If a CA issues a certificate for your domain without your knowledge, you (or an automated monitor) can spot it in the log.
Since April 2018, Chrome has required all newly issued certificates to be logged in at least two independent CT logs. If a certificate isn’t logged, Chrome won’t trust it, regardless of the CA that signed it. This doesn’t prevent a CA from issuing a fraudulent certificate, but it ensures the fraud is publicly visible, which means it will be caught.
CT logs use Merkle trees, a data structure where each leaf is a hash of a certificate, and each internal node is a hash of its children. The root hash of the tree is a compact commitment to the entire contents of the log. You can prove that a specific certificate is in the log by providing a path from the leaf to the root (a Merkle proof), which is compact and efficiently verifiable. Tampering with any entry would change the root hash, making the alteration detectable.
Revocation: the unsolved problem
Certificates have expiry dates, but sometimes a certificate needs to be invalidated before it expires. The private key might be compromised. The organisation might cease to exist. The certificate might have been issued in error. For all of these, you need revocation, a way to tell the world “this certificate is no longer trustworthy.”
In theory, there are two mechanisms. In practice, neither works well.
Certificate Revocation Lists (CRLs) are lists of revoked certificate serial numbers, published by CAs and updated periodically. The problem: the lists are large, they must be downloaded in full, and they’re updated infrequently. By the time a CRL is published, hours or days may have passed since the revocation. During that window, the compromised certificate is still trusted.
Online Certificate Status Protocol (OCSP), defined in RFC 6960, is an improvement: instead of downloading a full list, your browser queries the CA’s OCSP server in real time to check whether a specific certificate has been revoked. The problem: OCSP adds latency to every connection (the browser has to wait for the OCSP response before proceeding), and it creates a privacy issue (the CA can see every site you visit, because your browser asks about every certificate). It’s also a reliability problem, if the OCSP server is down, what does the browser do? Treat the certificate as valid (insecure) or reject the connection (disruptive)?
In practice, most browsers have adopted a soft-fail approach: if the OCSP server is unreachable, they proceed as if the certificate is valid. This means an attacker who can block your OCSP queries can also use a revoked certificate without detection. It’s not great.
OCSP stapling improves things slightly: the web server itself queries the OCSP server periodically and “staples” the signed response to the TLS handshake. This eliminates the privacy issue (the CA doesn’t see your queries) and the latency (the response is bundled with the certificate). But it’s optional, not all servers implement it, and if the server doesn’t staple, the browser falls back to the old behaviour.
Chrome took a different approach entirely: it maintains its own revocation list, CRLSets, distributed via the browser update mechanism. CRLSets only cover high-value revocations (compromised CA intermediates, high-profile website keys) and are updated within hours. For the vast majority of certificates, Chrome simply doesn’t check revocation at all. Google’s position is that short-lived certificates (like Let’s Encrypt’s 90-day certificates) make revocation less critical, and that Certificate Transparency provides a better safety net.
Revocation remains the weakest link in the certificate system. There is no universally deployed mechanism that provides real-time, reliable revocation checking. This is one of those problems the security community knows about, writes papers about, and has not yet solved.
Certificate pinning: trust, but verify harder
If you don’t fully trust the CA system, and after DigiNotar and Symantec, reasonable people might not, you can bypass it partially with certificate pinning. The idea: your application hard-codes (or configures at first run) the specific certificate or public key it expects for a given server. Even if a CA issues a fraudulent certificate for that server, the pin won’t match, and the connection will be rejected.
HTTP Public Key Pinning (HPKP), defined in RFC 7469 (2015), let websites tell browsers to pin specific keys. It was powerful but dangerous: if you misconfigured your pins (pinned the wrong key, lost access to the pinned key, or forgot to update pins before they expired), your website became permanently unreachable for users who had cached the pins. Several high-profile sites, including Smashing Magazine, accidentally bricked themselves with HPKP. Chrome deprecated it in 2018, and it was formally abandoned. The cure was worse than the disease.
Certificate pinning survives in mobile apps, where the developer controls both the client and the server. Banking apps, for instance, commonly pin their server’s certificate or public key in the app binary. This protects against a compromised CA but creates an operational burden: when the server’s certificate is renewed, the app must be updated with the new pin. Miss that coordination, and the app breaks.
The TLS handshake: putting it all together
When you type “https://…” in your browser, all of the technologies in this series work together in a process called the TLS handshake. It happens in milliseconds, before a single byte of your actual request is sent.
In TLS 1.3 (the current version, RFC 8446, published 2018), the handshake is streamlined to a single round trip:
Step 1: Client Hello. Your browser sends a list of supported cipher suites and a key share (its half of a Diffie-Hellman exchange). It also sends the Server Name Indication (SNI), the hostname you’re connecting to, in plaintext. (This is a privacy leak: anyone watching can see which site you’re connecting to, even though they can’t see what you’re doing there. Encrypted Client Hello, or ECH, is the in-progress fix.)
Step 2: Server Hello. The server chooses a cipher suite, sends its key share (completing the Diffie-Hellman exchange), and sends its certificate chain. From this point, everything is encrypted with the freshly derived session keys.
Step 3: Verification. Your browser verifies the certificate chain (website cert → intermediate → root in trust store), checks Certificate Transparency, optionally checks revocation, and verifies the server’s signature on the handshake transcript (proving the server holds the private key corresponding to the certificate).
Step 4: Finished. Both sides derive symmetric session keys from the Diffie-Hellman shared secret. All subsequent communication uses AES (or another symmetric cipher) with these keys.
The entire handshake takes roughly 50-100 milliseconds on a modern connection. What you experience as a brief pause before a page loads is actually your browser performing a Diffie-Hellman key exchange, verifying a certificate chain, checking a Merkle tree, and deriving session keys. It’s one of the most complex security protocols in widespread use, and it happens billions of times a day without anyone noticing.
The human at the end of the chain
All of this technology. X.509 certificates, certificate authorities, Certificate Transparency, the TLS handshake, exists to answer a simple question: “Am I talking to who I think I’m talking to?” And it works, mostly. The vast majority of HTTPS connections are genuinely secure.
But the chain of trust terminates, ultimately, in human decisions. Someone at Mozilla decides which root CAs to trust. Someone at a CA decides whether a domain validation is sufficient. Someone at Google decides which revocations to include in CRLSets. Someone at Let’s Encrypt decides that 90-day lifetimes are the right trade-off.
These decisions are made by competent people working in good faith, but they are decisions, not theorems. The trust store in your browser is a list of organisations that your browser vendor believes are trustworthy. If one of those organisations is compromised, or negligent, or coerced by a government, the entire chain breaks, and the user at the end of the chain has no way to know, because the padlock looks the same either way.
The certificate system is the best large-scale trust mechanism we have for the internet. It works remarkably well for something that’s a hierarchy of promises made by organisations you’ve never heard of. But it’s worth understanding what the padlock actually means: not “this connection is safe,” but “a chain of organisations, each trusting the one below it, has vouched for the identity of this server, and the mathematics checks out.” That’s a lot. It’s also less than most people assume.
Next: How Reputation Systems Work, what happens when you can’t use certificates at all, and trust has to be built from behaviour, observation, and the messy reality of humans interacting at scale.