How to Disable TLS 1.0 and 1.1: Apache, Nginx & IIS Configuration

Why This Still Needs to Be Done Manually

TLS 1.0 and 1.1 have been formally deprecated for years — major browsers stopped supporting them, PCI DSS requires their removal for payment-handling systems, and the IETF officially deprecated both in RFC 8996. None of that automatically changes what your server actually accepts. Unless a server's TLS configuration is explicitly updated, many still happily negotiate TLS 1.0 or 1.1 with any client that asks for it, especially on systems that have been running the same configuration for years without a full rebuild.

The three most common web servers each store this setting in a completely different place, using different syntax, which is the main reason this task trips people up — not the concept, but finding and correctly editing the right file or registry key.

Confirming What's Currently Enabled

Before changing anything, confirm what your server currently accepts, so you have a clear before-and-after comparison. The SSL Certificate Checker generates ready-to-run openssl commands for exactly this — one command per TLS version, showing which ones your server currently accepts or rejects. Run that check first, make your configuration change, then run it again afterward to confirm the change actually took effect.

Disabling TLS 1.0 and 1.1 on Apache

Apache's TLS version control lives in mod_ssl, via the SSLProtocol directive, typically set in the virtual host block or a global SSL config file (commonly /etc/apache2/mods-available/ssl.conf or /etc/httpd/conf.d/ssl.conf depending on distribution).

The -all disables every protocol version first, and the + entries re-enable only the ones you want — an explicit allowlist is safer than trying to individually disable just TLS 1.0 and 1.1, since it won't silently re-allow some future deprecated version by omission. After saving, reload or restart Apache (apachectl configtest first to catch syntax errors, then systemctl restart apache2 or httpd depending on your distribution).

Disabling TLS 1.0 and 1.1 on Nginx

Nginx uses the ssl_protocols directive, set inside the server block or a shared SSL config include (commonly under /etc/nginx/sites-available/ or a dedicated ssl-params.conf snippet).

Unlike Apache's allow/deny syntax, Nginx's ssl_protocols is a simple allowlist — only the versions listed are accepted, so TLS 1.0 and 1.1 are disabled by omission. Test the configuration syntax with nginx -t before reloading, then apply with systemctl reload nginx (a reload rather than a full restart is usually sufficient for Nginx and avoids dropping active connections).

Disabling TLS 1.0 and 1.1 on IIS

IIS doesn't use a web-server-level config file for this — the setting lives in the Windows registry, under the SCHANNEL provider's protocol keys, and applies at the operating system level rather than per-site.

A full server restart is required afterward, since SCHANNEL protocol settings are read at boot, not dynamically — a service restart alone is not sufficient on IIS the way a config reload is on Apache or Nginx. Because these keys live under SecurityProviders rather than under IIS's own configuration, the same registry change also affects any other Windows service using SCHANNEL for TLS on that machine, not just IIS itself — worth keeping in mind on a server running more than one TLS-terminating service.

Apache vs Nginx vs IIS: Where the Setting Lives

Verifying the Change Actually Took Effect

The only reliable verification is attempting an actual connection using each specific protocol version and confirming the handshake fails for TLS 1.0 and 1.1 while still succeeding for TLS 1.2 and 1.3:

A failed handshake typically shows a handshake failure or connection reset message rather than a certificate chain — that failure is the expected, correct outcome for the disabled versions.

Common Reasons TLS 1.0 Still Shows Enabled After the Change

When a fix genuinely doesn't seem to take effect, it's worth checking each of these in order rather than re-editing the same file repeatedly — re-editing a file that isn't actually the one in effect changes nothing no matter how many times it's repeated, and the wasted cycles usually trace back to one of these three causes rather than a mistake in the directive syntax itself.

Will Disabling TLS 1.0 and 1.1 Break Anything?

For a typical public website with general consumer traffic in 2026, the population of visitors still using clients unable to negotiate TLS 1.2 is negligible — modern browsers have supported TLS 1.2 for years. The population worth actually checking before disabling is internal or B2B: older internal tools, legacy payment terminals, embedded devices, or integration partners running outdated software stacks that haven't been updated. For those systems, confirm the specific client's TLS capability before rolling out the change broadly, since an internal tool failing silently can go unnoticed far longer than a public-facing outage would.

Real-World Scenarios

Rollout Checklist

1. Confirm current TLS version support with a live check before making any change.
2. Identify every config file or included snippet that could set the protocol version, not just the first one found.
3. Apply the change on one server first, test connections with actual protocol version flags, then roll out further.
4. Restart or reload appropriately — Apache and Nginx accept a reload, IIS requires a full restart.
5. Re-verify with the same live check used at the start, confirming TLS 1.0/1.1 now fail and TLS 1.2/1.3 still succeed.
6. If any legacy internal system depends on the old versions, coordinate its upgrade before disabling broadly rather than after something breaks.

Summary

Disabling TLS 1.0 and 1.1 is conceptually simple but operationally scattered — Apache's SSLProtocol, Nginx's ssl_protocols, and IIS's SCHANNEL registry keys are three unrelated mechanisms doing the same job, each with its own syntax and its own restart requirement. The actual risk in this task isn't the disabling itself; it's a second config file, a front-end load balancer, or a missed restart silently leaving the old versions enabled despite the change looking correct on paper — which is exactly why verifying with a live protocol-specific connection test, before and after, matters more than the edit itself.

Frequently Asked Questions