Quick answer
TLS (Transport Layer Security) is the protocol that encrypts traffic between a client and a server and lets the client verify it is talking to the right server. It is what puts the S in HTTPS. SSL was its predecessor and every version of it is now broken and deprecated — but the name stuck, so "SSL certificate" almost always means a TLS certificate. TLS provides three things: confidentiality so nobody in between can read the traffic, integrity so nobody can alter it undetected, and authentication so you know the server is genuine.
SSL or TLS?
SSL 2.0 and 3.0 were Netscape's original protocols. TLS 1.0 succeeded SSL 3.0 in 1999, and the versions in use today are TLS 1.2 and TLS 1.3. Every SSL version is deprecated and considered insecure.
The industry never updated its vocabulary, so "SSL certificate", "SSL termination" and "SSL/TLS" all persist. They refer to TLS. If a product genuinely offers SSL 3.0, that is a warning sign rather than a feature.
| Version | Year | Status |
|---|---|---|
| SSL 2.0 / 3.0 | 1995 / 1996 | Broken, disabled everywhere |
| TLS 1.0 / 1.1 | 1999 / 2006 | Deprecated in 2021, should be off |
| TLS 1.2 | 2008 | Widely used, secure when configured well |
| TLS 1.3 | 2018 | Current, faster, fewer ways to misconfigure |
What the handshake does
Before any data moves, client and server negotiate. The client announces which TLS versions and cipher suites it supports; the server picks from that list, presents its certificate, and the two derive a shared secret that only they know.
The clever part is that the shared secret is derived rather than transmitted. With modern key exchange, someone recording the whole conversation still cannot decrypt it later even if the server's private key is stolen afterwards — a property called forward secrecy.
TLS 1.3 cut this from two round trips to one, which is why it is measurably faster, and removed the older options that made 1.2 easy to misconfigure.
client → ClientHello versions, cipher suites, key share
server → ServerHello chosen suite, key share
Certificate proof of identity
Finished handshake authenticated
client → Finished encrypted from here on
one round trip, then application data flows encryptedWhat a certificate actually proves
A certificate binds a public key to a domain name, signed by a certificate authority your browser already trusts. When the server presents it, the browser checks the signature chain, that the name matches, and that it has not expired or been revoked.
It is worth being precise about what that proves: control of the domain at the time of issue. Nothing more. A valid certificate does not mean the site is honest, safe or run by a real company — a phishing site can obtain one in minutes, and routinely does.
TLS termination and re-encryption
When a proxy or CDN sits in front of your server, it usually terminates TLS: the encrypted connection ends there, the request is inspected, and a second connection is made to your origin. This is what makes a WAF possible at all — you cannot inspect what you cannot read.
The second leg should also be encrypted. If a provider terminates TLS at the edge and then talks to your origin in plain text, everything between them and you is readable by anyone on that path. Full end-to-end encryption should be the default, not an upgrade.
- Edge termination — required for caching, inspection and compression
- Re-encryption to the origin — should always be on
- Automatic certificate issuance and renewal, so nothing expires silently
- Certificates issued by DNS validation, so the origin never has to be publicly reachable
Configuring it well
- Disable everything below TLS 1.2 — TLS 1.0 and 1.1 are deprecated
- Prefer TLS 1.3 where clients support it
- Enable HSTS so browsers refuse to fall back to plain HTTP
- Automate renewal; the most common outage is a certificate nobody remembered
- Serve the full chain, not just the leaf certificate — a missing intermediate breaks some clients and not others, which is a miserable bug to chase
Frequently asked questions
Last updated