Public key infrastructure and certificates

Lesson 5 ended with a puzzle. Asymmetric encryption lets anyone send Rosa a secret message using her public key, but how does the sender know the public key really belongs to Rosa? If an attacker can trick Theo's browser into using the attacker's public key instead of the online shop's, the attacker can read everything, however strong the encryption. The answer is public key infrastructure, or PKI: the system of certificates, certificate authorities and trust that binds public keys to identities. Every padlock in a browser address bar depends on it.

This lesson explains what a certificate contains, how certificate authorities and the chain of trust work, what happens during a secure web connection, and the practical tasks that fall to IT staff: watching expiry dates, handling warnings and keeping private keys private.

What a certificate is

A digital certificate is a small data file that says, in effect, this public key belongs to this name, and it is signed by an organization that vouches for the claim. The most common kind is an X.509 certificate used for TLS, the protocol behind HTTPS. Its main fields are the subject (who the certificate is for, such as shop.ridgelinecoffee.example), the subject alternative names (the full list of host names the certificate covers), the public key, the issuer (the certificate authority that signed it), the validity period (not before and not after dates), a serial number, the permitted uses of the key, and the issuer's digital signature over all of it.

Because the certificate is signed, nobody can change any field without breaking the signature. And because the signature is made with the issuer's private key, anyone with the issuer's public key can check it. The certificate does not need to be kept secret; the server sends it to every visitor. What must be kept secret is the matching private key, which never leaves the server.

Certificate authorities and the chain of trust

A certificate authority (CA) is an organization trusted to check that a certificate request is genuine and then to sign the certificate. For a public website, the CA must verify that the requester controls the domain name, usually by asking them to place a specific value in a DNS record or on the website. This domain validation is enough for the padlock. Organization validation and extended validation certificates add checks on the legal identity of the organization, though modern browsers no longer display that extra detail prominently.

Browsers and operating systems ship with a trust store: a list of root CA certificates they trust completely. Root CAs keep their private keys offline in highly protected facilities and rarely use them directly. Instead, a root signs one or more intermediate CA certificates, and the intermediates sign the certificates for websites. When Theo's browser receives the shop's certificate, it follows the chain: the shop's certificate is signed by the intermediate, the intermediate is signed by the root, and the root is in the trust store. If every signature checks out, every certificate is within its validity dates and the name matches, the browser trusts the connection.

A common misconfiguration is a server that sends only its own certificate and not the intermediate. Some browsers can fetch the missing intermediate and connect; others, and many apps and devices, report an error. When a site works on one computer and fails on another with a certificate error, a missing intermediate is a prime suspect.

certs = {
    "shop.ridgelinecoffee.example": {"issuer": "Example Intermediate CA"},
    "Example Intermediate CA": {"issuer": "Example Root CA"},
    "Example Root CA": {"issuer": "Example Root CA"},
    "evil.example": {"issuer": "Homemade Root"},
    "Homemade Root": {"issuer": "Homemade Root"},
}
trusted_roots = {"Example Root CA"}

def chain_to_root(name, certs, trusted_roots):
    chain = [name]
    # follow issuers until you reach a root (issuer == subject)
    return chain

print(chain_to_root("shop.ridgelinecoffee.example", certs, trusted_roots))
print(chain_to_root("evil.example", certs, trusted_roots))

What happens in a TLS connection

When a browser connects to an HTTPS site, the TLS handshake sets up the secure session in a few round trips. The browser says which versions and ciphers it supports. The server replies with its choices and its certificate chain, and proves it holds the private key matching the certificate. The two sides use a key-agreement method to create a fresh symmetric session key that is never sent across the network, so even someone recording all the traffic cannot work it out. From then on, everything is encrypted and protected against tampering with that session key. TLS 1.3 is the current version; TLS 1.2 is still widely accepted, while earlier versions and the old SSL protocols are obsolete and should be disabled.

The padlock means the connection is encrypted and the server proved it owns the name in the address bar. It does not mean the site is honest. The phishing site Anita nearly used had a valid certificate for its own look-alike name, because criminals can obtain domain-validated certificates just as easily as anyone else. Staff need to check the name, not just the padlock.

Certificate lifetimes and expiry

Every certificate has an end date, and an expired certificate causes browsers to show a full-page warning that drives customers away. Certificate lifetimes have been getting shorter, because short-lived certificates limit the damage if a private key is stolen and force organizations to automate renewal. Under rules agreed by the CA/Browser Forum, the industry body of certificate authorities and browser makers, the maximum lifetime of a publicly trusted TLS certificate fell to 200 days for certificates issued from 15 March 2026. It is scheduled to fall to 100 days in March 2027 and to 47 days in March 2029.

With lifetimes that short, manual renewal is no longer realistic. Automated certificate management, usually through the ACME protocol used by services such as Let's Encrypt and most hosting platforms, requests and installs new certificates on a schedule without anyone touching them. Ridgeline's hosted shop renews its certificate automatically, but the NAS, the router's admin page and any internal tools need checking. Jordan keeps a small list of every certificate Ridgeline relies on, with its expiry date, and a script that warns well in advance.

from datetime import date
certs = {
    "shop.ridgelinecoffee.example": date(2027, 3, 19),
    "nas.office.ridgeline.example": date(2026, 11, 30),
    "roastlog.ridgeline.example": date(2026, 10, 25),
}
today = date(2026, 10, 19)
for name, expires in sorted(certs.items(), key=lambda kv: kv[1]):
    days = (expires - today).days
    status = "RENEW NOW" if days <= 14 else "renew soon" if days <= 45 else "ok"
    print(f"{days:>4} days  {status:<10} {name}")

   6 days  RENEW NOW  roastlog.ridgeline.example
  42 days  renew soon nas.office.ridgeline.example
 151 days  ok         shop.ridgelinecoffee.example

from datetime import date

def status(expires, today):
    days = (expires - today).days
    return "ok"

today = date(2026, 10, 19)
for d in [date(2026, 10, 1), date(2026, 10, 25), date(2026, 11, 30), date(2027, 3, 19)]:
    print(d, status(d, today))

Names, wildcards and warnings

A certificate is valid only for the names listed in it. A wildcard certificate for *.ridgelinecoffee.example covers shop.ridgelinecoffee.example and www.ridgelinecoffee.example, but the wildcard covers exactly one label: it does not cover ridgelinecoffee.example itself or a deeper name such as admin.shop.ridgelinecoffee.example. When a name does not match, the browser warns. Other common warnings are expired certificates, certificates from an untrusted issuer, and a computer clock set so wrong that valid certificates appear expired or not yet valid.

The right response to a certificate warning depends on where it appears. On a public website such as the bank, a warning is a reason to stop, not click through, because it may indicate an on-path attack. On an internal device such as the NAS, which may use a self-signed certificate created by the device itself, the better fix is to replace it with a certificate from a trusted source, or from Ridgeline's own internal CA if it ever needs one, so that staff are never trained to ignore warnings.

def covers(pattern, host):
    pattern, host = pattern.lower(), host.lower()
    # handle exact names first, then patterns starting with *.
    return pattern == host

for h in ["shop.ridgelinecoffee.example", "ridgelinecoffee.example", "a.shop.ridgelinecoffee.example"]:
    print(h, covers("*.ridgelinecoffee.example", h))

Revocation and keeping private keys private

Sometimes a certificate must be withdrawn before it expires, for example if the server's private key is stolen. The CA then revokes it and publishes the fact, traditionally through certificate revocation lists or an online status check. In practice revocation checking has always been patchy, which is another reason the industry is moving to short lifetimes: a stolen key for a short-lived certificate is only useful for a short time. Public CAs also record every certificate they issue in Certificate Transparency logs, public records that let domain owners spot certificates issued for their names without permission.

Private keys are the crown jewels of PKI. They should be generated on the server or device that uses them, never emailed, stored with tight permissions, and backed up only where necessary. If a private key may have been exposed, the certificate must be revoked and replaced with one using a new key. The same principles apply beyond websites: code-signing keys, email signing keys and the keys of any internal CA all need the same care.