📜 09-04: Certificates in Practice¶

📌 From Theory to the Address Bar¶

Module 07 covers the underlying theory of digital certificates and PKI in depth — see 07-08: Digital Certificates & PKI for how certificates are structured, signed, and chained to a trust root. This lesson focuses on the practical side: what actually happens when a real browser evaluates a real certificate, and the everyday certificate concepts you'll run into working with live websites.

✅ How a Browser Validates a Certificate Chain¶

When your browser connects to an HTTPS site, the server presents a certificate (and usually one or more intermediate certificates) during the TLS handshake (see 09-02: The TLS Handshake). The browser then performs a sequence of checks before it will treat the connection as trusted:

Build the chain — the browser links the server's certificate to an intermediate certificate, which is in turn linked to a root certificate. This chain-of-signatures logic (each certificate signed by the next one up) is the core PKI mechanism explained in 07-08: Digital Certificates & PKI.
Check the root is trusted — the browser (or the underlying OS) ships with a built-in list of trusted root Certificate Authorities (CAs). If the chain doesn't terminate at one of these trusted roots, validation fails.
Verify every signature in the chain — each certificate's signature must be verified using the public key of the certificate that signed it, all the way up the chain.
Check validity dates — every certificate in the chain must be within its "not before" / "not after" validity window. An expired certificate anywhere in the chain fails validation.
Check revocation status — the browser may check whether the certificate has been revoked before its expiration date (via mechanisms like OCSP — Online Certificate Status Protocol — or certificate revocation lists), since a certificate can become untrustworthy before it naturally expires (e.g., if the private key was stolen).
Verify the hostname matches — separately from all of the above, the browser checks that the hostname you're actually visiting matches the certificate's subject/SAN fields (more on this below). This is a distinct check from chain validation, and it's a common source of real-world bugs when developers forget to perform it in custom TLS client code.

💡 A certificate can pass every one of steps 1–5 perfectly — correctly signed, trusted root, not expired, not revoked — and still be the wrong certificate for the site you're visiting, if step 6 is skipped. Chain validation proves "this certificate is legitimately issued by a CA I trust." Hostname validation proves "this certificate was issued for the site I'm actually talking to." Both are required; neither substitutes for the other.

If any of these checks fail, a properly implemented browser shows a warning page rather than silently proceeding — because proceeding anyway would defeat the entire purpose of certificate-based authentication.

🔏 Self-Signed Certificates¶

A self-signed certificate is a certificate where the issuer and the subject are the same entity — in other words, instead of being signed by a trusted CA's private key, it's signed by its own private key. Anyone can generate one in seconds, for free, with no verification of identity by any third party at all.

Why browsers warn about self-signed certificates: the entire value of a certificate as an authentication mechanism comes from the fact that a trusted third party (the CA) verified something about the certificate holder before signing it. A self-signed certificate skips that verification step entirely — anyone, including an attacker, could generate a self-signed certificate claiming to be www.yourbank.com. Since the browser's trust model relies on chains rooted in known, vetted CAs, a self-signed certificate simply doesn't chain to anything the browser already trusts, and validation correctly fails.

💡 Self-signed certificates aren't inherently "broken" cryptographically — the encryption they enable works exactly the same way. The problem is purely about trust and identity verification: there's no independent assurance that the certificate actually belongs to who it claims to. This is why self-signed certificates are commonly used for internal testing, development environments, or systems where the two parties have exchanged trust out-of-band (similar in spirit to how WireGuard's public-key model works — see 08-04: Building a VPN Tunnel) — but they're inappropriate for public-facing production services where visitors have no other way to verify identity.

🌐 Subject Alternative Names (SANs) and Wildcard Certificates¶

Subject Alternative Names (SANs)¶

Modern certificates rarely protect just one exact hostname. A Subject Alternative Name (SAN) field lets a single certificate list multiple hostnames it's valid for — for example, one certificate covering example.com, www.example.com, and mail.example.com all at once.

This directly answers a common practical question: if a company wants to use the same certificate for several of its servers (www.example.com, mail.example.com, vpn.example.com), the SAN field is exactly the mechanism that makes this possible — all three hostnames get listed in one certificate's SAN field, and a browser visiting any of them will find a matching entry during hostname validation.

Wildcard Certificates¶

A wildcard certificate covers an entire pattern of subdomains using a single entry like *.example.com, matching www.example.com, mail.example.com, shop.example.com, and so on — any single-level subdomain of example.com.

	SAN List	Wildcard
Covers	An explicit, fixed list of hostnames	Any subdomain matching a pattern
Adding a new subdomain later	Requires reissuing the certificate with an updated list	Automatically covered if it matches the pattern
Typical use	A fixed set of known services	Large or frequently changing sets of subdomains
Depth of matching	Exact names only	Typically only one subdomain level (`.example.com` does not* match `a.b.example.com`)

💡 SANs and wildcards aren't mutually exclusive — a single certificate's SAN field can include a wildcard entry (*.example.com) alongside other exact names, combining both approaches.

🆓 Free Certificate Issuance: Let's Encrypt¶

Historically, obtaining a certificate from a trusted CA cost money and often involved a manual verification process, which was a real barrier to universal HTTPS adoption. Let's Encrypt is a nonprofit Certificate Authority that changed this by issuing certificates for free, using an automated domain-validation process (proving you control a domain, typically by placing a specific file at a known URL or DNS record, rather than a manual identity check).

Key practical characteristics:

Free and automated — certificates can be requested and renewed entirely via software (commonly the certbot tool or similar ACME-protocol clients), with no manual paperwork.
Short validity periods — Let's Encrypt certificates are typically valid for only about 90 days, which is deliberately short. This encourages automated renewal pipelines rather than the old habit of manually managing certificates that are valid (and easy to forget about) for a year or more.
Domain validation only — Let's Encrypt certificates prove you control the domain; they don't vouch for the organization's real-world identity the way a more expensive "Extended Validation" certificate historically claimed to. For the vast majority of websites, domain validation is entirely sufficient — the goal of "traffic to this domain is encrypted and really reaches this domain" is fully met.

💡 Let's Encrypt is a major reason HTTPS became the overwhelming default across the web rather than the exception — removing cost and manual process as barriers made "just enable HTTPS" achievable for essentially every site operator, which ties directly into the best-practices checklist in 09-06: TLS Best Practices & HTTPS.

📌 Key Takeaways¶

Browser certificate validation involves two distinct checks: validating the signature chain up to a trusted root, and separately validating that the hostname matches — both are required.
A self-signed certificate provides working encryption but no independent identity verification, which is why browsers warn about it; it's fine for testing/internal use, inappropriate for public production sites.
SAN (Subject Alternative Name) fields let one certificate cover multiple explicit hostnames — the standard answer to "we want one certificate for several of our servers."
Wildcard certificates (*.example.com) cover any matching subdomain automatically, trading precision for convenience as new subdomains are added.
Let's Encrypt provides free, automated, domain-validated certificates with short (~90 day) validity periods designed to encourage automated renewal.
Certificate validity checks include expiration dates and revocation status, not just signature correctness — a certificate can be correctly signed yet no longer trustworthy.
For the underlying PKI mechanics (how signing and chains of trust actually work), see 07-08: Digital Certificates & PKI.