SSL vs TLS
SSL and TLS do the same job, encrypting the link between a browser and a server, but SSL is retired and TLS is what every HTTPS site now uses. Servers should enable only TLS 1.2 and TLS 1.3. A certificate sold as an SSL certificate works over TLS; the server, not the certificate, picks the version.
For site owners and administrators who want to know what changed between SSL and TLS and which protocol versions their server should allow.
knowledge
- Read time
- 6 min
- Sections
- 8
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
What is the difference between SSL and TLS?
SSL (Secure Sockets Layer) and TLS (Transport Layer Security) do the same job — encrypting the link between a browser and a server — but SSL is the retired predecessor and TLS is the protocol every HTTPS site actually uses today. A certificate sold as "SSL" is a TLS certificate: the server chooses the protocol version, not the certificate.
| Attribute | SSL 3.0 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|
| Published | 1996, Netscape | 2008, RFC 5246 | 2018, RFC 8446 |
| Status | Retired (RFC 7568); browsers refuse it | Valid, widely used fallback | Current default |
| Full handshake | 2 round trips | 2 round trips | 1 round trip; 0-RTT on resumption |
| Key exchange | RSA, static DH | RSA, DHE or ECDHE | Ephemeral (EC)DHE only |
| Ciphers | RC4, 3DES, CBC | CBC or AES-GCM | AEAD only: AES-GCM, ChaCha20-Poly1305 |
| Certificate in transit | Sent in clear | Sent in clear | Encrypted |
TLS is effectively SSL version 4: the protocol was renamed when the IETF standardised it in 1999, and every later fix shipped under the TLS name.
Which SSL and TLS versions are still allowed?
Only TLS 1.2 and TLS 1.3 are acceptable today; SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 are all formally retired and rejected by current browsers. A server offering just 1.2 and 1.3 is missing nothing a visitor needs.
| Version | Year | Status |
|---|---|---|
| SSL 2.0 | 1995 | Prohibited by RFC 6176 (2011) |
| SSL 3.0 | 1996 | Broken by POODLE (2014); deprecated by RFC 7568 (2015) |
| TLS 1.0 | 1999 (RFC 2246) | Deprecated by RFC 8996 (March 2021) |
| TLS 1.1 | 2006 (RFC 4346) | Deprecated by RFC 8996 (March 2021) |
| TLS 1.2 | 2008 (RFC 5246) | Allowed; keep as fallback |
| TLS 1.3 | 2018 (RFC 8446) | Current; supported by all major browsers |
POODLE is why SSL 3.0 disappeared so quickly: an attacker could force a connection down to SSL 3.0 and then recover encrypted data, and the only real fix was to stop speaking SSL.
How is the TLS 1.3 handshake faster than older versions?
TLS 1.3 needs one round trip instead of two because the browser sends its key share in the very first message, so encryption can start as soon as the server replies. On high-latency mobile connections, that saved round trip is noticeable.
- The browser sends ClientHello with supported versions, a key share for a likely (EC)DHE group, and its cipher suites.
- The server answers with ServerHello and its own key share; both sides derive the handshake keys.
- Everything after that is encrypted, including the certificate and the server's signature.
- The browser verifies the chain, sends Finished, and its first HTTP request goes out in the same flight.
Returning visitors can resume with a pre-shared key and send data immediately (0-RTT). One detail is often overstated: the hostname the browser asks for (SNI) is still visible in the ClientHello unless the server and browser use Encrypted Client Hello (ECH), so TLS 1.3 alone does not hide which site is being visited.
What security does TLS 1.3 add over SSL and TLS 1.2?
TLS 1.3 makes forward secrecy mandatory and removes every weak option — RC4, 3DES, CBC suites, MD5, SHA-1 and static RSA key exchange — leaving only five cipher suites. With fewer choices, there is far less room for a bad server default.
- Forward secrecy: each session key comes from an ephemeral exchange, so a stolen server key cannot decrypt traffic recorded earlier.
- AEAD encryption only: AES-GCM and ChaCha20-Poly1305 protect both privacy and integrity.
- Encrypted certificate: passive observers cannot read the certificate chain.
- Downgrade protection: built-in signals stop attackers forcing an older version.
None of that helps if the server still accepts TLS 1.0, so check the negotiated versions before tuning anything else.
Why are certificates still called "SSL certificates"?
Because buyers search for "SSL" and certificate authorities kept the familiar product name; the certificate itself works with any TLS version. It binds a domain name to a public key and is signed by a certificate authority — nothing in it selects SSL or TLS.
What you actually choose when buying is validation level (DV, OV, EV) and coverage (single name, wildcard, multi-domain); types of SSL certificates explains each. "Upgrading your SSL certificate to TLS" is therefore not a product: the protocol upgrade is a free change in the web server configuration. Replace a certificate only when it expires, its names change, or you need higher validation.
Which TLS versions should a server enable, and how?
Enable TLS 1.2 and TLS 1.3 and disable SSL 3.0, TLS 1.0 and TLS 1.1. Keep 1.2 as a fallback: older Android devices, some card terminals and a few payment APIs still top out at 1.2, so TLS 1.3 alone can lock out real customers.
| Platform | Setting |
|---|---|
| Apache httpd | SSLProtocol -all +TLSv1.2 +TLSv1.3 |
| Nginx | ssl_protocols TLSv1.2 TLSv1.3; |
| WHM (cPanel server) | Apache Configuration → SSL/TLS protocols: allow only TLSv1.2 and TLSv1.3, then rebuild and restart Apache |
| IIS | SCHANNEL registry keys per protocol; TLS 1.3 requires Windows Server 2022 or later |
| Shared hosting | Set by the host; ask support if an old version is still enabled |
Do not put SSLProtocol in .htaccess: Apache does not allow it there and returns a 500 error. For certificate installation steps, see installing SSL on Apache or installing SSL on IIS.
How do you check which TLS version a site uses?
Run openssl s_client once forcing TLS 1.3 and once forcing TLS 1.1: the first should connect and print the protocol, the second should fail. These commands work on Linux, macOS and WSL.
# Should connect and show "Protocol : TLSv1.3" (or "New, TLSv1.3")
openssl s_client -connect example.com:443 -tls1_3 </dev/null
# Should FAIL if retired versions are switched off
openssl s_client -connect example.com:443 -tls1_1 </dev/nullIn Chrome, open DevTools (F12) → Security panel to see the negotiated protocol and cipher. For a full report, run the domain through the WebJi® SSL checker or an SSL Labs-style scanner. If TLS 1.1 still connects after a change, the setting went to the wrong virtual host or the web server was not reloaded. Note that newer OpenSSL builds may refuse -tls1_1 on the client side regardless of the server, which also shows as a failure.
What does an SSL/TLS certificate cost at WebJi®?
Let's Encrypt certificates are included free with every WebJi® hosting plan; paid Sectigo certificates cost ₹1,800 a year for Positive SSL and ₹7,500 a year for a Positive SSL Wildcard, before 18% GST. Both work over TLS 1.2 and 1.3 equally.
Choose paid only when you need organisation validation, a warranty or a specific CA; free vs paid SSL covers that decision, and the SSL certificate page lists all options.
Frequently asked questions
Is SSL still used today?
No. SSL 2.0 and 3.0 are retired, and current browsers refuse them. The word survives as a product name; every secure connection now runs on TLS 1.2 or TLS 1.3.
Do I need a new certificate to use TLS 1.3?
No. Your existing certificate works with TLS 1.3 as long as the web server and its OpenSSL (or Windows) version support it. Enabling 1.3 is a server configuration change.
Will disabling TLS 1.0 and 1.1 break my site for anyone?
Only very old clients, such as Android 4.4 and older or Internet Explorer on outdated Windows. Modern browsers, phones and payment gateways all support TLS 1.2 or newer, and most gateways require it.
Can I disable TLS 1.0 on shared hosting myself?
No. The setting is server-wide and cannot go in .htaccess. Email support@webji.services with the domain and the test result; support answers 24/7 in Hindi and English with an average first reply under 60 minutes.
Protocol dates checked against the IETF RFCs cited · Reviewed by the WebJi® team, Jaipur, 15 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.