TLS and certificates, demystified

The s in HTTPS is TLS — the encryption that makes the padlock appear and keeps traffic private. As a DevOps person you will obtain certificates, renew them, debug "your connection is not private" errors, and set up HTTPS on servers and load balancers. TLS has a reputation for being mysterious; it is not, once you have the mental model. This lesson demystifies TLS and certificates — what they do, how the trust works, and the failures you will actually meet.

What TLS gives you

When a connection uses TLS (so, HTTPS on port 443), it provides three things:

• Encryption — nobody between the client and server can read the traffic. On a shared network (a café Wi-Fi), without TLS, others can see everything you send; with TLS, they see scrambled bytes.
• Integrity — the traffic cannot be secretly altered in transit without detection.
• Authentication — the client can verify it is really talking to riztechacademy.com and not an impostor. This is the part that certificates handle, and the part that trips people up.

The first two (privacy, tamper-proofing) are why HTTPS is now mandatory for essentially all web traffic — and why browsers mark plain HTTP as "not secure". The third (proving identity) is what the whole certificate system exists for.

Certificates and the chain of trust

The problem authentication solves: when you connect to a server claiming to be riztechacademy.com, how do you know it really is, and not an attacker who intercepted you? The answer is a certificate — a signed document that says "this public key belongs to riztechacademy.com", issued by a Certificate Authority (CA) that your browser already trusts.

It works through public-key cryptography (the same idea as SSH keys):

• The server has a private key (secret) and a matching public key.
• A CA verifies the server operator controls the domain, then issues a certificate binding the domain name to that public key, signed by the CA.
• Your browser ships with a list of trusted CAs. When it connects, the server presents its certificate; the browser checks the CA's signature against its trusted list, confirms the certificate is for the domain it asked for and is not expired, and — using the key exchange — confirms the server holds the matching private key.

So trust chains: you trust the browser vendor, who trusts a set of CAs, who vouch for the server. If every link checks out, you get the padlock; if any link fails (unknown CA, wrong domain, expired), the browser refuses with a warning. You do not need the cryptographic detail — you need the chain: CA signs a cert binding a domain to a public key; the browser trusts the CA; therefore the browser trusts the server.

Getting certificates: Let's Encrypt changed everything

Certificates used to cost money and be a hassle. Let's Encrypt is a free, automated CA that issues certificates by an automated challenge (you prove you control the domain — via a DNS TXT record or a file served over HTTP — and it issues the cert). Tools like certbot, and most modern platforms and load balancers, do this automatically and renew before expiry.

The practical upshot for you:

• Certificates expire — typically every 90 days for Let's Encrypt. Automate renewal; a forgotten manual renewal is a classic outage ("the whole site went down at midnight" = a cert expired).
• Most platforms handle TLS for you — Vercel, cloud load balancers, managed ingress — you point a domain at them and they provision and renew the certificate. Know that this is happening so you can debug it.
• On your own server, certbot + a web server (nginx) is the standard setup, with a timer that renews automatically.

The TLS failures you will actually meet

You will spend more time on TLS errors than on TLS theory, so recognise the common ones:

• Expired certificate — the single most common: renewal failed or was never automated, the cert lapsed, and browsers reject it. Fix: renew; then fix the automation so it does not recur.
• Wrong domain / name mismatch — the cert is for example.com but you are visiting www.example.com and it is not covered. Certs list the exact names they cover (including wildcards like *.example.com).
• Untrusted / self-signed — a certificate not signed by a trusted CA (a self-signed one, common in internal/dev setups) triggers a warning; fine internally, never for public traffic.
• Incomplete chain — the server did not send the intermediate certificates, so some clients cannot build the chain to a trusted root. It "works in my browser" (which cached the intermediate) but fails elsewhere — a confusing one.

Check a certificate from the command line:

openssl s_client -connect riztechacademy.com:443 -servername riztechacademy.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
curl -vI https://riztechacademy.com    # curl -v shows the TLS handshake and cert details

The first prints the certificate's validity dates, who it is for, and who issued it — exactly what you need to diagnose "is it expired? is it for the right name? who signed it?". These turn a vague "your connection is not private" into a specific, fixable fact.

Check your work

TLS gives encryption (nobody in between can read it), integrity (no undetected tampering), and authentication (you are really talking to the claimed server). Privacy/integrity make HTTPS mandatory; authentication is what certificates provide.

Certificate + chain of trust: a CA verifies domain control and issues a certificate binding the domain to the server's public key, signed by the CA; browsers ship a trusted-CA list and verify the signature, the domain, and non-expiry (public-key crypto, like SSH keys). Trust chains: browser → CA → server.

Getting certs: Let's Encrypt = free, automated (prove domain control → cert), via certbot or the platform. Certs expire (~90 days) — automate renewal (a lapsed cert is a classic midnight outage); platforms/load balancers usually provision + renew for you.

Common failures: expired (most common — fix renewal), wrong-domain/name-mismatch (cert doesn't cover the name), untrusted/self-signed (fine internally, never public), incomplete chain (missing intermediates — works in one browser, fails elsewhere). Diagnose with openssl s_client / curl -v (dates, subject, issuer).

Practice

1. State the three things TLS provides and give a real consequence of lacking each.
2. Explain the chain of trust from your browser to a server in your own words, naming the CA's role.
3. Explain why Let's Encrypt's 90-day expiry makes automated renewal essential, with the failure it prevents.
4. Match each TLS error to its cause: expired, name mismatch, self-signed, incomplete chain.
5. Use openssl s_client ... | openssl x509 -noout -dates -issuer on a real site and read the expiry and issuer.
6. Explain the "works in my browser but fails elsewhere" incomplete-chain problem and why it is confusing.

Official documentation

• MDN — Transport Layer Security — What TLS does and how it works.
• Let's Encrypt — How it works — Automated, free certificates.
• Wikipedia — Public key certificate — Certificates, CAs and the chain of trust.

Next: debugging with curl, dig and traceroute.