Chapter 3

TLS & Certificates

Public keys, CAs, chain of trust, SANs.

Learning objectives

  • Explain public-key cryptography at a practical level
  • Read a certificate’s subject, SANs, issuer, and expiry
  • Understand certificate chains and why intermediates matter

What a certificate proves

A TLS certificate binds a public key to one or more hostnames. When a browser connects to Workshop Co., it checks:

  • The certificate is signed by a trusted Certificate Authority (CA)
  • The hostname matches (www.workshopco.ca is in the SAN list)
  • The certificate has not expired
  • The chain links to a root CA in the browser’s trust store

Chain of trust

Root CA (built into browser/OS)
    └── Intermediate CA
          └── Leaf certificate (workshopco.ca, www.workshopco.ca)
                └── Private key (stays on server — never share)

The server sends the leaf plus any intermediate certificates. The browser already trusts the root. If intermediates are missing, users see “unable to get local issuer certificate.”

Private keys

The private key file (privkey.pem) must stay on the server with permissions 600. Anyone with the private key can impersonate your site. Never commit keys to Git or paste them in support tickets.

Reading a certificate

A typical Let’s Encrypt certificate for Workshop Co. includes:

FieldExampleWhy it matters
Subject CNworkshopco.caLegacy display name; SANs are authoritative now
SANsworkshopco.ca, www.workshopco.caEvery hostname the cert covers
IssuerLet’s Encrypt R3Who signed the cert
Valid from / to90-day windowRenew before expiry

Worked example — SAN mismatch

Workshop Co. obtains a cert covering only www.workshopco.ca. A visitor goes to https://workshopco.ca (apex). The browser shows certificate name mismatch because the apex is not in the SAN list.

Fix: Re-issue with both names, or redirect apex to www after obtaining a cert that includes both. Let’s Encrypt allows multiple SANs in one certificate.

Wildcard certs

A wildcard *.workshopco.ca covers any single label (staging, api) but not the apex. For Workshop Co., a cert with explicit SANs for apex + www + staging is often simpler than wildcards.

Try it yourself — plan SANs

Workshop Co. needs HTTPS on production (www and apex) and staging (staging.workshopco.ca). List the SANs for one certificate vs two separate certificates.

Answer

One cert: workshopco.ca, www.workshopco.ca, staging.workshopco.ca

Two certs: (1) prod: apex + www; (2) staging only. Separate certs isolate staging renewals and reduce blast radius if staging config breaks ACME validation.

Spot the mistake

An admin copies only fullchain.pem and privkey.pem to Nginx but users report chain errors on Android devices. What is likely missing?

Answer

fullchain.pem should include leaf + intermediates. If they used cert.pem (leaf only) instead of fullchain.pem, some clients cannot build the chain. Always point Nginx ssl_certificate at the full chain file.

Quick quiz

  1. What does SAN stand for and why is it used instead of CN alone?
  2. Where must the private key live?
  3. Does a wildcard cert cover the apex domain?
Answers
  1. Subject Alternative Name — lists all hostnames the cert is valid for; modern browsers require SAN match.
  2. On the web server only, readable by the TLS process, never published.
  3. No — *.workshopco.ca does not match workshopco.ca.