Getting a Certificate
The theory is done — now the practical question: how do you actually obtain a certificate for a domain you own? This chapter covers the request itself (the CSR), how a CA proves you control the domain (validation), and how Let's Encrypt automated the whole thing into a single command via the ACME protocol — the reason HTTPS is now free and ubiquitous.
Step Zero: The Key Pair Never Leaves Your Server
Before anything else, one principle that surprises beginners: you generate your own private key, and it never leaves your server. The CA never sees it. You only send the CA your public key (inside a CSR) plus proof you control the domain; the CA signs a certificate binding that public key to your domain and sends the certificate back. The secret half stays with you the entire time.
The CSR — Certificate Signing Request
A CSR is the formal application you send to a CA. It bundles your public key with the identity you're requesting (the domain), and is signed by your private key to prove you hold it. You can create one with openssl:
| The CSR contains | The CSR does NOT contain |
|---|---|
| your public key | your private key (never!) |
| the requested domain(s) — CN & SAN | the validity dates (the CA sets those) |
| a self-signature proving key ownership | the CA's signature (added on issuance) |
Inspect a CSR with openssl req -in example.csr -text -noout — you'll see the same fields as a certificate (Chapter 4) minus the issuer and validity, because those are filled in only when a CA signs it.
Domain Validation: Proving You Control the Domain
A CA won't sign a cert for example.com until you prove you actually control that domain (Chapter 5's DV level). The proof is a challenge: the CA gives you something to place where only the domain's controller could put it, then checks for it.
| Challenge type | You prove control by… | Best for |
|---|---|---|
| HTTP-01 | serving a specific token file at http://domain/.well-known/acme-challenge/<token> | a single host you run a web server on |
| DNS-01 | creating a specific TXT record in the domain's DNS | wildcards (*.example.com) & servers not publicly reachable |
| TLS-ALPN-01 | presenting a special cert on a TLS connection | environments where only port 443 is usable |
The logic is identical across all three: only someone who genuinely controls the domain (its web root, its DNS, or its TLS endpoint) could satisfy the challenge. Wildcard certificates specifically require DNS-01, because proving control of one web page doesn't prove control of every possible subdomain — but control of the DNS zone does.
ACME — Automating the Whole Exchange
ACME (Automatic Certificate Management Environment) is the protocol Let's Encrypt introduced to turn that manual back-and-forth into an automated machine-to-machine conversation. A client (like certbot) runs the entire flow:
In practice this is one command. Certbot can even configure your web server for you:
Renewal: Set It and Forget It
Because Let's Encrypt certs last only 90 days, renewal must be automatic — and certbot installs a timer that does it for you. The renewal re-runs the same validation; nothing manual is required as long as the challenge can still be satisfied:
--test-cert / --staging) so failed experiments don't burn your weekly quota — staging certs aren't publicly trusted but exercise the full flow. Second, after a renewal your server is often still using the old cert in memory until it reloads — so a renewal deploy hook (e.g. --deploy-hook "systemctl reload nginx") is needed to pick up the new cert. A silently-not-reloaded server is a classic "why did my cert expire when certbot said it renewed?" bug.
When You'd Use a Commercial CA Instead
Let's Encrypt covers the overwhelming majority of needs, but not all. You'd pay a commercial CA when you need OV/EV validation (vetted organization identity, Chapter 5), longer support contracts, warranties, or certificate types Let's Encrypt doesn't issue. For ordinary "encrypt my website" purposes, though, free DV via ACME is the default choice — and the rest of this course assumes it.
Hands-On Exercises
Generate a private key and a CSR for a domain with both a CN and a SAN list, then inspect the CSR with openssl req -text -noout. Confirm it contains your public key and requested domains but NOT a private key, issuer, or validity dates — and explain why those three are absent.
Explain how the HTTP-01 and DNS-01 challenges each prove domain control, then state which one you MUST use to obtain a wildcard certificate for *.example.com and exactly why the other one can't work for a wildcard.
A site's certificate expired even though the admin "set up certbot." List the most likely causes (renewal timer not running, server never reloaded the renewed cert, validation challenge now failing) and describe how certbot renew --dry-run and a deploy hook would have prevented it.
Chapter 9 Quick Reference
- You generate your private key; it never leaves your server — the CA only ever sees your public key
- CSR = public key + requested domains (CN/SAN), self-signed to prove key ownership; no issuer/validity yet
- Domain validation (DV) proves control via a challenge: HTTP-01 (token file), DNS-01 (TXT record), or TLS-ALPN-01
- Wildcards require DNS-01 — only DNS-zone control proves authority over every subdomain
- ACME automates the order → challenge → validate → CSR → issue flow; certbot is the common client
- Let's Encrypt — free, automated, DV-only CA; the reason HTTPS became ubiquitous
- 90-day certs ⇒ auto-renewal (certbot timer); test with
certbot renew --dry-run - Gotchas: rate limits → use staging while testing; reload the server via a deploy hook after renewal
- Next chapter: configuring HTTPS on a server — nginx/Apache, redirects, HSTS, OCSP stapling, SSL Labs