How TLS certificates actually work
Private keys, CSRs, certificate authorities, and the chain of trust. · 10 min
TLS (the modern name for what's still colloquially called SSL) uses public-key cryptography, structurally similar to the SSH key auth covered in Level 9: a private key that stays secret on the server, and a public key embedded in a certificate that's freely shared with anyone connecting. The certificate additionally binds that public key to an identity (a domain name) and is digitally signed by a Certificate Authority (CA) — a trusted third party whose job is specifically to verify that whoever requested the certificate actually controls the domain it's for, before signing it.
The process starts with generating a private key, then a Certificate Signing Request (CSR) — a file containing the public key and the requested domain identity, but not yet signed by anyone. You submit the CSR to a CA (or an automated service like Let's Encrypt), the CA verifies domain control and signs it, and you get back a signed certificate. The private key generated at the start never leaves your server and is never sent to the CA — only the public key, inside the CSR, is submitted.
A browser trusts a certificate by verifying a chain: your server's certificate is signed by an intermediate CA certificate, which is itself signed by a root CA certificate that's pre-installed and trusted by the browser/OS out of the box. This chain of signatures is why a server must typically present not just its own certificate but the intermediate certificate(s) too — a "certificate chain" — for a client to be able to verify the full path back to a root it already trusts; a missing intermediate certificate is one of the most common real-world "certificate not trusted" errors despite the server's own certificate being entirely valid.
| Command | Purpose | Example |
|---|---|---|
| openssl genrsa -out key.pem 2048 | Generate a 2048-bit RSA private key | — |
| openssl req -new -key key.pem -out request.csr | Generate a Certificate Signing Request from a private key | — |
| openssl x509 -in cert.pem -text -noout | Inspect a certificate's full details (issuer, validity dates, domain) | — |
| openssl s_client -connect host:443 | Connect to a server and inspect the certificate chain it actually presents | — |
- • PEM — a common text-based encoding format for keys and certificates (Base64, human-readable headers)
- • PFX / PKCS#12 — a binary format bundling a private key and certificate(s) together, common on Windows/IIS
- • CSR — the signing request, containing the public key + requested identity, not yet signed
- • Certificate chain — your cert + intermediate cert(s), needed for a client to verify trust back to a root CA
Hands-On Lab
Generate a key, a CSR, and inspect a certificate
Objectives
- ✓ Generate a private key
- ✓ Generate a CSR from it
- ✓ Inspect the CSR's contents
- ✓ Inspect a real, live certificate's chain from a public site
Instructions
- Generate a private key: `openssl genrsa -out mykey.pem 2048`.
- Generate a CSR from it: `openssl req -new -key mykey.pem -out myrequest.csr` — answer the prompted fields (Common Name should match the domain you'd actually be requesting for).
- Inspect the CSR's contents (without submitting it anywhere): `openssl req -in myrequest.csr -text -noout`.
- Inspect a real certificate from a live site: `openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -text -noout` — note the issuer, validity dates, and Subject Alternative Names.
Hints (1)
- You never actually submit the CSR from this lab anywhere — this is a safe, offline exercise in understanding the file, not obtaining a real certificate.
Quick Check
What does a Certificate Signing Request (CSR) contain that gets sent to a Certificate Authority?
Takeaway: The private key never leaves the server it was generated on — only the CSR (public key + identity) goes to the CA, which is exactly why losing a private key means generating a new one, not "recovering" the old one from anywhere.