Topic 7.4
HTTPS, Certificates & mTLS
In one line
HTTPS is HTTP inside TLS. TLS encrypts traffic and proves the server's identity with a certificate signed by a trusted Certificate Authority. Operationally, the main jobs are issuing, trusting, and renewing certificates before they expire.
Think of it like this
A certificate is like a passport. It states who you are (the domain name), carries your public key (a photo anyone can compare), and is stamped by an issuing authority everyone trusts (the CA). A browser trusts a site because a trusted authority vouched for it, not because the site says so.
Key ideas
- 01
KEYS: the server has a PRIVATE key (kept secret) and a matching PUBLIC key (inside the certificate). Data protected with one can only be verified or opened with the other, which is how the server proves it owns the certificate without revealing the private key.
- 02
CERTIFICATE CHAIN: the server's (LEAF) certificate is signed by an INTERMEDIATE CA, which is signed by a ROOT CA already built into operating systems and browsers (the trust store). Servers must send the leaf AND the intermediates; a missing intermediate causes 'unable to verify' errors in some clients even though browsers may cope.
- 03
THE HANDSHAKE, conceptually (TLS 1.3): the client says hello with supported versions and ciphers and the hostname it wants (SNI, which lets one IP serve many certificates); the server replies with its certificate chain and key-exchange data; both derive shared session keys; from then on everything is encrypted. The client checks that the certificate is unexpired, chains to a trusted root, and matches the hostname. TLS 1.3 needs one round trip (vs two in TLS 1.2).
- 04
EXPIRY: public certificates are short-lived (Let's Encrypt: 90 days, with the industry moving towards even shorter lifetimes), so renewal MUST be automated: cert-manager in Kubernetes (Platform course, Mission 0.2), AWS Certificate Manager for ALB/CloudFront (renews automatically), or certbot on VMs. Monitor days-until-expiry and alert at 14 days, because expired certificates are one of the most common avoidable outages.
- 05
Where TLS terminates: at the CDN or load balancer (most common; the LB holds the certificate), at the ingress/gateway in the cluster, or end-to-end to the pod. Internal hops may be re-encrypted depending on compliance needs.
- 06
mTLS (mutual TLS): the CLIENT also presents a certificate, so both sides prove identity. Used for service-to-service zero-trust inside meshes (Istio, Linkerd issue and rotate workload certificates automatically; DevOps guide, advanced Kubernetes ecosystem), for partner APIs, and for IoT devices.
Code & diagrams
The lines to look at: the TLS version, the certificate subject and issuer, the expiry date, and the verify result.
$ curl -sv https://shop.example.com/ -o /dev/null 2>&1 | grep -E 'SSL connection|subject:|issuer:|expire date|verify'
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* subject: CN=shop.example.com
* expire date: Dec 19 08:14:02 2026 GMT
* issuer: C=US; O=Let's Encrypt; CN=R11
* SSL certificate verify ok.Explain it without notes
Why must a server send its intermediate certificate?
What does the client check before trusting a certificate?
Practice
Monday morning, the partner integration fails with 'certificate has expired' although your website works in browsers. Where do you look?
Trade-offs
- ↔
Terminating TLS at the edge simplifies certificates and enables caching and WAF inspection; end-to-end encryption protects internal hops at the cost of more certificates to manage (which meshes automate).
Done when you can
Every public certificate renews automatically
Expiry is monitored with alerts well before the date
I can read the TLS version, issuer, and expiry from
curl -v