HTTP
TLS vs SSLVersions, what is obsolete and what a "SSL certificate" really is
TLS (Transport Layer Security) is the current name and version lineage of the protocol that began as SSL (Secure Sockets Layer). SSL 2.0 and 3.0 and TLS 1.0 and 1.1 are deprecated and should be disabled; TLS 1.2 and TLS 1.3 are the versions in use. A "SSL certificate" is simply an X.509 certificate used for TLS; the name is historical.
One protocol family, two names
Netscape created SSL in the mid-1990s. When the IETF standardised it in 1999 the name changed to TLS, and TLS 1.0 was essentially SSL 3.1. Every version since has been TLS. People still say "SSL" out of habit, which is harmless in conversation and misleading in configuration, where enabling actual SSL is a vulnerability.
| Version | Year | Status | Notes |
|---|---|---|---|
| SSL 1.0 | — | Never released | |
| SSL 2.0 | 1995 | Prohibited (RFC 6176) | Fundamentally broken |
| SSL 3.0 | 1996 | Prohibited (RFC 7568) | POODLE attack |
| TLS 1.0 | 1999 | Deprecated (RFC 8996) | BEAST; weak ciphers |
| TLS 1.1 | 2006 | Deprecated (RFC 8996) | Rarely used |
| TLS 1.2 | 2008 | Current | Safe with modern cipher suites |
| TLS 1.3 | 2018 | Current, preferred | Faster handshake, only strong ciphers, forward secrecy mandatory |
What TLS provides
- Encryption of everything after the handshake.
- Integrity through authenticated encryption; tampering is detected.
- Authentication of the server (and optionally the client) with X.509 certificates.
- Forward secrecy (TLS 1.3 always; TLS 1.2 with ECDHE): a stolen server key later does not decrypt recorded sessions.
The handshake, briefly
- Client sends ClientHello: supported versions, cipher suites, the server name (SNI), and in 1.3 its key share.
- Server replies with its choice, its certificate and its key share.
- Client verifies the certificate chain against trusted roots and checks the name matches.
- Both derive session keys; encrypted application data begins. TLS 1.3 does this in one round trip; 1.2 needs two.
The certificate does not change between versions. "SSL certificate", "TLS certificate" and "HTTPS certificate" are the same X.509 object. Certificate fingerprints are SHA-256 hashes of the DER encoding; see hashing explained.
Where TLS is used besides HTTPS
SMTP submission (STARTTLS) and SMTPS, IMAPS, POP3S, LDAPS, DNS over TLS, RDP, OpenVPN, MQTT, database connections, and Windows' own Schannel-based services.
Checking a server
curl -vI --tlsv1.3 https://example.com/ -o NUL
curl -vI --tls-max 1.1 https://example.com/ -o NULThe first should succeed and print SSL connection using TLSv1.3. The second should fail if the server correctly refuses TLS 1.1 and below. On Windows, protocol versions for the built-in stack are controlled by Schannel registry settings; recent Windows versions disable TLS 1.0/1.1 by default.
Common configuration mistakes
- Leaving TLS 1.0/1.1 enabled "for compatibility" years after clients stopped needing them.
- Serving a certificate chain without the intermediate, which works in some browsers (cached intermediates) and fails in others.
- Letting certificates expire; automate renewal.
- Using the same certificate and private key across unrelated systems.
Frequently asked questions
Should I buy an SSL certificate or a TLS certificate?
They are the same product. Vendors kept the SSL name for marketing. Any certificate sold as SSL works with TLS 1.2 and 1.3.
Is TLS 1.2 still safe?
Yes, with modern cipher suites (AEAD ciphers such as AES-GCM or ChaCha20-Poly1305, ECDHE key exchange). TLS 1.3 removes the weak options entirely and is faster, so prefer it where clients support it, and keep 1.2 for compatibility.
Why do old devices fail to connect to modern sites?
They only support TLS 1.0/1.1 or old cipher suites that servers have disabled. Windows 7 without updates, Android 4.x and many old embedded devices are affected. The fix is on the client side (update or replace).