SSL & HTTPS Guides

Understanding TLS Versions and Why SSLv3 Is Insecure

Learn the difference between SSL and TLS versions, why SSLv3 and old TLS versions are insecure, and what modern HTTPS servers should support.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Advanced

Introduction

TLS is the modern protocol used to secure HTTPS connections. Older names such as “SSL certificate” are still common, but modern websites should use TLS, not old SSL protocols.

SSLv2, SSLv3, TLS 1.0 and TLS 1.1 are obsolete and should generally be disabled on public websites. Modern servers should support TLS 1.2 and TLS 1.3 where possible. This helps improve security, compatibility with modern browsers and results in cleaner security scans.

Quick answer

Quick answer

SSLv3 is insecure and should not be enabled on public websites. Modern HTTPS should use TLS 1.2 and TLS 1.3. If old protocols such as TLS 1.0 or TLS 1.1 are still enabled, the server may fail security checks or expose users to avoidable risks.

TLS versions

TLS versions define which protocol a browser and server can use to create a secure HTTPS connection.

SSLv2

Obsolete and insecure.

SSLv3

Obsolete and insecure.

TLS 1.0

Old and deprecated.

TLS 1.1

Old and deprecated.

TLS 1.2

Widely supported modern baseline.

TLS 1.3

Newest major version with stronger design and better performance.

When people say “SSL,” they often mean HTTPS certificates, but the secure connection itself should use modern TLS.

SSL vs TLS

SSL was the older protocol family. TLS replaced SSL and is what modern HTTPS uses.

  • “SSL certificate” usually means the certificate used for HTTPS
  • “TLS” is the modern protocol that secures the connection
  • “HTTPS” is HTTP running over TLS

The goal is not to use old SSL protocols. The goal is to use a valid certificate with modern TLS versions.

Why SSLv3 is insecure

SSLv3 is an obsolete protocol with known security weaknesses. It should not be enabled on public HTTPS servers.

  • Weak protocol design
  • Exposure to known attacks
  • Security scan failures
  • Poor compliance posture
  • Unnecessary support for obsolete clients

There is almost never a good reason to keep SSLv3 enabled on a modern public website.

TLS 1.0 and 1.1

TLS 1.0 and TLS 1.1 are newer than SSLv3, but they are still old and deprecated for modern public websites.

  • Old server configurations
  • Legacy hosting setups
  • Outdated control panels
  • Old load balancers
  • Old CDN settings
  • Old enterprise systems

For most public websites, TLS 1.0 and TLS 1.1 should be disabled after confirming no required legacy clients depend on them.

TLS 1.2 and 1.3

TLS 1.2 is the common modern baseline for HTTPS compatibility. TLS 1.3 is newer and can improve security and performance when supported by the server, CDN and clients.

Recommended practical setup 
Enable:
TLS 1.2
TLS 1.3

Disable:
SSLv2
SSLv3
TLS 1.0
TLS 1.1

Exact settings depend on hosting provider, web server, CDN, load balancer and client requirements.

Why this matters

Why this matters

TLS versions matter because they decide which security protocol protects the connection between browser and server. Even with a valid certificate, a server can still be poorly configured if it allows obsolete SSL/TLS protocols.

Old protocol support can trigger browser warnings, security scan failures, compliance issues or vulnerability reports.

How to check TLS

Use SSL Checker to inspect which SSL/TLS protocol versions your server supports.

When checking TLS versions, review

These six checks help confirm TLS is configured correctly.

Enabled protocols

Confirm whether SSLv2, SSLv3, TLS 1.0 or TLS 1.1 are still enabled.

Modern protocol support

Confirm TLS 1.2 and TLS 1.3 support where possible.

CDN or proxy behavior

Check the public hostname, not only the origin server.

Cipher compatibility

Review whether weak ciphers are enabled.

Legacy client needs

Confirm whether any required old systems still depend on old protocols.

Security scan results

Check whether old protocols cause warnings or failures.

Check TLS configuration

Use SSL Checker to review supported TLS versions, certificate status and HTTPS configuration.

Run SSL Check →

Common problems

SSLv3 enabled

High

SSLv3 is obsolete and insecure.

Next step: Disable SSLv3 in the web server, CDN, proxy or load balancer configuration.

TLS 1.0 enabled

Medium

TLS 1.0 is deprecated and may fail security checks.

Next step: Disable TLS 1.0 after confirming legacy clients are not required.

TLS 1.1 enabled

Medium

TLS 1.1 is deprecated and should not be needed for modern public websites.

Next step: Disable TLS 1.1 where possible.

TLS 1.2 disabled

High

Modern clients expect TLS 1.2 support as a practical baseline.

Next step: Enable TLS 1.2 in server, hosting or CDN settings.

TLS 1.3 not supported

Low

TLS 1.3 is recommended where available, but TLS 1.2 can still be acceptable.

Next step: Enable TLS 1.3 if supported by your stack.

CDN and origin differ

Medium

The CDN edge may support different TLS versions than the origin server.

Next step: Check both public CDN endpoint and origin configuration.

Weak ciphers enabled

Medium

Protocol version may be modern, but weak cipher suites can still reduce security.

Next step: Update cipher configuration or use a modern hosting/CDN profile.

Legacy client compatibility issue

Medium

Disabling old TLS versions may break very old systems or embedded clients.

Next step: Review client requirements before changing production settings.

How to update TLS

  1. Step 1: Check current protocol support

    Run an SSL/TLS scan against the public hostname.

  2. Step 2: Identify where TLS is configured

    Check whether TLS is controlled by hosting, Nginx, Apache, LiteSpeed, CDN, reverse proxy or load balancer.

  3. Step 3: Disable obsolete protocols

    Remove SSLv2, SSLv3, TLS 1.0 and TLS 1.1 where possible.

  4. Step 4: Enable modern protocols

    Enable TLS 1.2 and TLS 1.3 if supported.

  5. Step 5: Review cipher settings

    Use a modern recommended cipher profile from your hosting, CDN or server stack.

  6. Step 6: Test important clients

    Confirm browsers, APIs, payment providers, mobile apps and integrations still connect.

  7. Step 7: Re-scan externally

    Use SSL Checker to confirm the public hostname now shows the intended protocol support.

Before changes

Document and review the current setup before changing TLS settings.

Current TLS versions are documented

Know what is enabled today.

Public hostname is tested

Scan the URL visitors actually use.

CDN/proxy settings are reviewed

Edge TLS may differ from origin.

Origin server settings are reviewed

Check hosting or server config.

Required legacy clients are identified

List integrations that may break.

Rollback plan exists

Know how to revert if needed.

After changes

Verify the update succeeded from outside the server.

TLS 1.2 works

Modern baseline is available.

TLS 1.3 works if supported

Enable where your stack allows.

SSLv3 is disabled

Obsolete protocol is removed.

TLS 1.0 and 1.1 are disabled

Deprecated protocols removed where possible.

Important integrations still work

APIs, payments and apps connect.

Security scan is clean

No old-protocol warnings remain.

Monitoring is active

Watch for handshake or connection errors.

Server and CDN settings

TLS settings may be controlled in different places depending on your architecture.

  • Hosting control panel
  • Nginx configuration
  • Apache SSL configuration
  • LiteSpeed settings
  • CDN SSL/TLS settings
  • Load balancer
  • Reverse proxy
  • Managed platform dashboard

If a CDN is active, visitors see the CDN edge TLS configuration. The origin server may have separate TLS settings.

Compatibility

Most modern browsers and devices support TLS 1.2. TLS 1.3 support is also common on modern systems. Problems usually appear with old operating systems, old embedded devices, outdated Java clients, legacy payment terminals or old enterprise software.

  • Business-critical integrations
  • Old mobile apps
  • API clients
  • Payment gateways
  • Enterprise systems
  • Server-to-server connections
  • Regional user device profile

For normal public websites, old SSL/TLS protocols should not remain enabled only for theoretical legacy users.

TLS examples

Check TLS connection 
openssl s_client -connect example.com:443 -servername example.com -tls1_2
Check TLS 1.3 
openssl s_client -connect example.com:443 -servername example.com -tls1_3
Check old TLS 1.0 
openssl s_client -connect example.com:443 -servername example.com -tls1
Check HTTPS headers 
curl -I https://example.com
Example modern goal 
Enable: TLS 1.2, TLS 1.3
Disable: SSLv2, SSLv3, TLS 1.0, TLS 1.1

These examples are illustrative. Replace example.com with your real hostname and test changes before applying them in production.

Frequently asked questions

Is SSLv3 still safe?

No. SSLv3 is obsolete and should not be enabled on public websites.

Should TLS 1.0 and TLS 1.1 be disabled?

For most public websites, yes. They are old and deprecated.

Which TLS versions should a modern website support?

A modern website should generally support TLS 1.2 and TLS 1.3 where possible.

Does a valid SSL certificate mean TLS is configured correctly?

No. Certificate validity and TLS protocol configuration are separate checks.

Can disabling old TLS versions break users?

It can affect very old clients or legacy integrations, so test business-critical systems first.

Where do I change TLS versions?

It depends on your setup: hosting panel, Nginx, Apache, LiteSpeed, CDN, proxy or load balancer.

Does a CDN change TLS behavior?

Yes. Visitors may connect to the CDN edge, which can have different TLS settings than the origin server.

Use these free tools to verify your configuration after applying changes.

SSL Checker HTTP Header Checker Website Status Checker DNS Lookup Domain Health Checker
What Is SSL/TLS and How Does It Protect Your Site 8 min read How to Check Your SSL Certificate 8 min read Using a CDN with HTTPS 8 min read HSTS Explained: Strict Transport Security for Browsers 8 min read Troubleshooting SSL Handshake Failures 9 min read
Browse all SSL & HTTPS guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.