jd five

TLS Certificates & PKI

Learning goals

By the end of this chapter you should be able to:

  • Explain what a TLS certificate proves and what it does not prove
  • Walk through a certificate chain from leaf to root CA
  • Describe Subject Alternative Names (SAN) and why they matter for modern sites
  • Spot expiry problems before they take production down
  • Give a one-minute explanation of mTLS (mutual TLS) and when teams use it

This chapter builds on the HTTPS story: TCP opens the pipe, TLS encrypts and authenticates, HTTP flows inside. Here we zoom in on the identity paperwork TLS relies on — the Public Key Infrastructure (PKI).

Plain English: what a certificate is

When your browser connects to https://example.com, TLS does two big jobs:

  1. Encryption — strangers on the path cannot read your HTTP bytes.
  2. Authentication — you are talking to a server that is allowed to claim it represents example.com, not a random laptop in the coffee shop pretending to be the bank.

The server’s certificate is that claim in a standard format (X.509). It contains:

  • Who the certificate is for (domain names, org info)
  • The server’s public key (used during the TLS handshake)
  • Who vouched for it — a Certificate Authority (CA) signature
  • When it is valid (not before / not after dates)

Your browser (or OS) ships a list of trusted root CAs. During the handshake it checks: “Was this certificate signed by someone I trust, or by an intermediate I can chain back to a root I trust?”

Precise terms: the server presents a leaf certificate (also end-entity certificate). The client validates the chain of trust up to a root certificate in its trust store.

Certificate chain: leaf → intermediate → root

Real deployments rarely sign leaf certs directly with the root key (roots stay offline and guarded). Typical chain:

Leaf cert       →  signed by Intermediate CA
Intermediate CA →  signed by Root CA
Root CA         →  self-signed; pre-installed in trust store

During TLS, the server often sends multiple certificates in one message: leaf plus one or more intermediates. The client already has roots; it links signatures until it reaches a trusted root.

Common failure modes:

  • Missing intermediate — server sends only the leaf; some clients cannot build the chain → handshake errors in older Android, Java, or curl.
  • Wrong intermediate — chain does not verify even though the leaf looks fine.
  • Untrusted root — private CA or corporate proxy; you must install their root manually.

Interview one-liner: “The browser verifies the leaf cert’s signature against intermediates until it hits a root it already trusts.”

Certificate Authority (CA): who gets to sign?

A CA is an organization (or internal team) that follows rules (WebTrust, browser programs) and uses its private key to sign Certificate Signing Requests (CSRs).

Flow when you deploy a site:

  1. You generate a key pair on the server (keep private key secret).
  2. You create a CSR containing your public key and the names you want.
  3. A public CA (Let’s Encrypt, DigiCert, etc.) validates you control the domain (HTTP challenge, DNS TXT, etc.).
  4. CA returns a signed leaf certificate; you configure it with your private key.

Let’s Encrypt and ACME automated much of this — certs are often 90-day lifetimes with auto-renewal. Long-lived certs still exist but short lifetimes reduce damage if a key leaks.

Subject Alternative Name (SAN): the names that actually matter

Historically people talked about the certificate Common Name (CN) field. Modern TLS checks the SAN extension — a list of DNS names (and sometimes IPs) the cert is valid for.

Cert SAN list Works for
example.com, www.example.com both hostnames
*.example.com one label wildcard: api.example.com, not a.b.example.com
missing api.example.com TLS error even if CN says example.com

Wildcard gotcha: *.example.com does not cover the bare apex example.com unless listed separately.

Multi-tenant SaaS often uses SAN-heavy certs or per-tenant certs depending on scale and isolation needs.

Expiry: the outage you can calendar

Certificates expire. When they do, clients refuse the connection — users see scary browser errors; API clients fail with certificate verify errors.

Why expiry exists: limits blast radius if a key is compromised; forces rotation.

Operational habits:

  • Monitor days until expiry (metrics, uptime checks).
  • Automate renewal (ACME, cert-manager in Kubernetes, cloud load balancer managed certs).
  • Staged rollout: renew before the old cert dies; keep overlap during deploys.

Clock skew: if a client’s clock is wrong, a valid cert can look “not yet valid.” Support tickets love this one.

What certificates do not guarantee

A valid cert for example.com means:

  • The CA believed someone controlling that name requested it at issuance time.
  • The connection is encrypted to whoever holds the private key.

It does not mean:

  • The site is safe (phishing sites get certs too).
  • The application code has no bugs.
  • The data on the server is honest.

TLS authenticates the channel and name; your app still needs authz, input validation, and patching.

mTLS: both sides show ID (brief)

Normal HTTPS: only the server presents a certificate; the client proves nothing cryptographic (maybe cookies later in HTTP).

Mutual TLS (mTLS): the client also presents a certificate. The server verifies the client cert against its trust policy — common in service-to-service meshes, some B2B APIs, and zero-trust internal networks.

Flow: TCP + TLS as usual → server cert validated → server requests client certificate → client proves key possession → server checks against allowed CAs → HTTP proceeds.

When you hear it: service meshes, B2B APIs, internal gRPC. Rare for browser users; common for machine-to-machine.

Common mistakes

  1. Serving only the leaf cert without intermediate chain — intermittent failures on strict clients.
  2. Cert matches load balancer, not backend — TLS terminates at LB; backend may use different cert or plain HTTP internally (know your hop).
  3. Wildcard cert on wrong tier — *.prod.example.com on a staging hostname confuses people and audits.
  4. Ignoring auto-renew failures — ACME HTTP-01 breaks when traffic routing changes.
  5. Assuming HTTPS icon means “trusted business” — users and junior engineers both fall for this.

Practice checkpoint

  1. What three things does a typical server TLS certificate contain? Answer: identity/names (incl. SAN), public key, and CA signature binding them; plus validity dates.

  2. Why does the browser need intermediate certificates from the server? Answer: to build a chain from leaf to a root already in the trust store; it usually does not have intermediates preinstalled.

  3. *.example.com cert — valid for www.example.com? Answer: yes (one label). Not valid for example.com unless SAN lists it. Not valid for deep.www.example.com if only one wildcard level.

  4. What happens on expiry day if renewal failed? Answer: TLS handshake fails; browsers show certificate errors; programmatic clients error on verify.

  5. mTLS vs normal HTTPS — who presents a client cert? Answer: mTLS requires the client to present and prove a certificate; normal HTTPS only the server cert is required.

Interview angles

  • Chain of trust: leaf → intermediate → root; signature verification at each step.
  • SAN vs CN: always mention SAN for hostname validation today.
  • Public vs private CA: public for the Internet; private CA for internal services (install root on clients).
  • Cert pinning (mention carefully): hard-coding expected keys/certs — powerful, brittle on rotation; more common in mobile than browsers now.
  • TLS termination: LB holds cert; backend may be HTTP — certificate the client sees is the LB’s.

Next: /networking/learn/systems/load-balancers-and-proxies/