SSL/TLS Explained
Volume 2 — Networking Foundations
"SSL" and "TLS" are used interchangeably in casual conversation — SSL is the deprecated predecessor protocol; every modern HTTPS connection actually uses TLS. This chapter covers what TLS actually does, why certificates exist, and how to read the errors when it fails.
1. What TLS Actually Provides
TLS solves three separate problems at once for a connection:
| Property | What it means |
|---|---|
| Encryption | Data in transit can't be read by anyone intercepting it |
| Integrity | Data can't be silently modified in transit without detection |
| Authentication | You can verify you're actually talking to who you think you are (via the certificate) |
A connection can fail on any one of these independently — a certificate warning is specifically an authentication failure, not necessarily an encryption failure; the connection could still be fully encrypted while the browser correctly refuses to trust who's on the other end of it.
2. Public Key Infrastructure (PKI)
TLS relies on public/private key pairs, the same underlying concept as SSH keys (see the SSH & Key Management chapter), but used to establish trust between a server and anyone connecting to it rather than to authenticate a person.
The trust chain:
Your operating system and browser ship with a built-in list of trusted root Certificate Authorities. A certificate for your domain is trusted not because your domain is inherently special, but because a CA your OS already trusts signed it — directly or through an intermediate — vouching that they verified you actually control that domain.
3. The TLS Handshake
Two things worth internalizing from this:
- The handshake happens after the TCP three-way handshake, not instead of it — TLS sits on top of an already-established TCP connection. A TCP connection succeeding does not mean TLS will.
- Public-key cryptography is only used briefly, during the handshake, to safely agree on a shared symmetric key — the actual data afterward is encrypted with that (much faster) symmetric key, not the certificate's key pair directly.
4. What's Actually in a Certificate
openssl s_client -connect api.roundtrips.app:443 -servername api.roundtrips.app </dev/null 2>/dev/null | openssl x509 -noout -text
Key fields to know:
| Field | What it means |
|---|---|
| Subject / Common Name (CN) | The primary hostname the certificate is issued for |
| Subject Alternative Names (SAN) | Additional hostnames the same certificate covers — modern browsers actually validate against SAN, not CN, even for the primary name |
| Issuer | Which CA signed it |
| Valid From / Valid To | The certificate's validity window — this is the field behind every "certificate expired" error |
Wildcard (*.roundtrips.app) | Covers any single-level subdomain, but not the apex (roundtrips.app itself) and not multi-level (api.dev.roundtrips.app) |
5. Certificate Validation: What Actually Gets Checked
When a client connects, it checks all of the following — any single failure produces a certificate warning:
- Is the certificate's hostname (SAN) an actual match for the hostname being requested?
- Is today's date within the certificate's valid range?
- Does the certificate chain up to a CA the client actually trusts?
- Has the certificate been revoked (checked via OCSP or a CRL)?
Common ways each of these fails:
| Check | Common failure |
|---|---|
| Hostname match | Requesting www.roundtrips.app against a cert only covering roundtrips.app, or vice versa |
| Validity window | Certificate expired — automated renewal (Let's Encrypt, Azure managed certs) failed silently and nobody noticed until it lapsed |
| Trust chain | Self-signed certificate in a production context, or an intermediate certificate missing from the server's configuration |
| Revocation | Rare in practice, but a compromised certificate that was revoked will fail here even if otherwise valid |
6. Automated Certificate Issuance
Manually renewing certificates used to be a routine source of outages (an expired cert nobody caught in time). Modern platforms automate this entirely:
| Platform | How it handles certificates |
|---|---|
| Cloudflare Pages | Automatic HTTPS via Cloudflare's own managed certificates for any domain proxied through it |
| Azure App Service | Free managed certificates for custom domains, auto-renewed, or bring-your-own via Key Vault |
| Let's Encrypt | Free, automated CA — issues certificates via the ACME protocol, typically renewed automatically every 60–90 days by tooling like Certbot |
The underlying pattern across all three: a short validity window (60–90 days, versus the multi-year certificates common in the past) combined with fully automated renewal, so an expired certificate today is almost always a sign that automated renewal itself broke — not that someone forgot a manual step.
7. HSTS
Strict-Transport-Security is a response header telling browsers "always use HTTPS for this domain, never even attempt plain HTTP again, for the next N seconds" — it closes the small window where a first request over plain HTTP could be intercepted before a redirect to HTTPS happens.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Worth knowing before enabling it broadly: once a browser has cached an HSTS policy, it will refuse plain HTTP for that domain until the max-age expires — including for any subdomain if includeSubDomains is set — so it's not something to turn on casually on a domain still serving anything over plain HTTP.
8. Practical Developer Workflows
Check a certificate's expiration date directly:
echo | openssl s_client -connect api.roundtrips.app:443 -servername api.roundtrips.app 2>/dev/null | openssl x509 -noout -dates
Check the full chain the server is actually presenting (a common misconfiguration is a valid leaf certificate with a missing intermediate — some clients tolerate this, others don't):
openssl s_client -connect api.roundtrips.app:443 -servername api.roundtrips.app -showcerts </dev/null
Verify from the browser directly: click the padlock icon → certificate details — shows the exact chain, validity window, and SANs the browser actually evaluated.
9. Troubleshooting Playbook
| Symptom | Likely cause | What to check |
|---|---|---|
NET::ERR_CERT_DATE_INVALID / "certificate expired" | Automated renewal failed silently | Check the renewal mechanism (Let's Encrypt cron/Certbot logs, Azure managed cert status) directly, not just the symptom |
NET::ERR_CERT_COMMON_NAME_INVALID | Requesting a hostname not covered by the certificate's SANs | openssl x509 -noout -text and check the SAN list against the exact hostname requested |
| Certificate trusted in browser but not from a script/CLI tool | Missing intermediate certificate in the chain the server presents — browsers sometimes fetch missing intermediates automatically, CLI tools often don't | openssl s_client -showcerts to see exactly what the server sends, compare against the full expected chain |
| Self-signed certificate warning in production | A dev/staging certificate accidentally left on a production endpoint | Confirm the certificate's issuer; replace with a properly-issued cert |
| Works over HTTP, TLS handshake fails over HTTPS | Server not actually listening for TLS on that port, or a firewall/NSG blocking 443 specifically | Confirm with nc -zv host 443; check the service is actually configured to terminate TLS there |
| Intermittent certificate errors after a deploy | Load balancer routing to a mix of old/new instances during a rolling deploy, with inconsistent certificate configuration | Confirm all backend instances present the same certificate configuration before/during the rollout |
| Mixed content warnings in the browser | Page loaded over HTTPS is pulling some resources over plain HTTP | Update the offending resource URLs to HTTPS explicitly |
10. Quick Reference
| Category | Command / Concept | Purpose |
|---|---|---|
| Inspect | openssl s_client -connect host:443 -servername host | Open a raw TLS connection for inspection |
| Inspect | ... | openssl x509 -noout -dates | Show certificate validity window |
| Inspect | ... | openssl x509 -noout -text | Show full certificate details |
| Inspect | -showcerts | Show the full chain the server presents |
| Concept | SAN | The actual hostnames a certificate is valid for (checked over CN) |
| Concept | Trust chain | Leaf → intermediate → root, root must be trusted by the client |
| Concept | HSTS | Forces HTTPS-only for a domain once cached by the browser |
| Automation | Let's Encrypt / ACME | Free, automated 60–90 day certificates |
| Azure | App Service managed certificate | Free, auto-renewed cert for a custom domain |
Part of the Traxs Engineering Handbook — Volume 2: Networking Foundations. Companion chapters in this volume: TCP/IP Fundamentals, DNS Deep Dive, VPN Fundamentals, Network Troubleshooting, Load Balancers & Reverse Proxies.