SSL / HTTPS: What It Protects (and What It Doesn’t)
SSL is a common shorthand. Technically, modern sites use TLS (Transport Layer Security). What matters is the outcome: HTTPS encrypts traffic and helps users trust they’re talking to the real service.
This guide explains what HTTPS protects, where teams still get it wrong, and how SSL connects to domains and hosting.
What HTTPS protects
When HTTPS is correctly configured, it provides:
- Encryption: prevents casual interception of data in transit
- Integrity: reduces risk of traffic being modified in transit
- Authentication: proves the server controls the domain (via a certificate)
What HTTPS does not magically fix
HTTPS does not automatically:
- secure your application code
- prevent account takeover (you still need MFA and good auth flows)
- stop phishing (users can still be tricked)
- protect data at rest (you need storage/database controls)
Certificates: the practical view
Teams usually care about:
- Coverage: which names are included (root,
www, subdomains) - Renewal: automation is non-negotiable
- Validation: DV is typical; enterprise may require OV/EV (policy choice)
Certificates are tied to DNS names:
- Learn domain fundamentals: Domains & DNS
Image placeholder
Graphic: HTTPS trust chain (browser → certificate → CA → domain validation)
Replace with a real graphic later (SVG/PNG)
Hosting, VPS, and TLS termination
There are a few common patterns:
- Hosting platform terminates TLS (simplest)
- Reverse proxy terminates TLS (e.g., NGINX, Caddy)
- Edge/CDN terminates TLS (adds caching and DDoS protection)
If you’re on a VPS, you need clean DNS and careful config:
Avoiding the classic mistakes
Professionals check for:
- redirect HTTP → HTTPS
- secure ciphers and TLS versions
- HSTS when appropriate
- correct certificate chain
- renewals monitored and tested