How do you disable legacy TLS protocols in an HTTPS-compliant configuration?

A common way to configure HTTPS compliance is to disable legacy TLS versions by turning off TLS 1.0, TLS 1.1, and earlier SSL protocols, retaining TLS 1.2, and enabling TLS 1.3 when supported by the server. However, whether the configuration meets requirements also depends on the applicable security baseline, cipher suites, certificates, and the actual scope of enforcement; protocol versions alone are not enough to determine compliance.

Before making changes, first confirm where the browser’s TLS connection terminates. If the website uses a CDN, WAF, or load balancer, changing only the origin server configuration may leave the public-facing endpoint accepting legacy protocols.

Identify all HTTPS endpoints that need to be updated

Corporate websites for international trade, cross-border stores, and advertising landing pages often use an access path such as “visitor—CDN/WAF—load balancer—origin server.” Each independently established TLS connection has its own protocol settings. If an intermediary only passes traffic through, the component that actually terminates TLS on the backend controls the settings.

We recommend mapping endpoints by domain name and listening port, rather than checking only by server count:

• Public-facing endpoints: primary domains, www subdomains, multilingual sites, stores, APIs, and advertising landing pages.
• Origin connections: HTTPS connections from the CDN to the load balancer, and from the reverse proxy to the application service.
• Alternative access points: directly accessible origin server addresses, backup domains, management endpoints, and other HTTPS ports.

The CDN’s “minimum TLS version” setting typically controls visitor connections; the protocol for origin connections must be configured separately. If the origin connection still uses HTTP, passing a public-facing test does not mean the entire connection path is encrypted.

Specify which protocols are allowed in the configuration

Rather than disabling older versions one by one, it is clearer to explicitly list the protocols that are allowed. Before configuring them, confirm that the web server and its linked TLS library support the target versions. Adding TLS 1.3 to a configuration file does not mean the current environment can provide it.

Nginx configuration example

Set the following in the appropriate configuration context:

ssl_protocols TLSv1.2 TLSv1.3;

If all sites follow the same policy, manage it centrally at the http level and check whether any server blocks override the configuration. When multiple HTTPS virtual hosts share the same address and port, also check the default virtual host: protocol negotiation may be affected by the default server configuration, so it is not enough to modify only the configuration block for the target domain.

After saving, check the syntax before reloading the service:

nginx -t
nginx -s reload

Reload the service only after the syntax check succeeds. In containerized, clustered, or hosted environments, use the corresponding deployment mechanism to update the configuration and ensure that all instances use the same settings, so that some requests do not continue to reach outdated nodes.

Configuring Apache and hosted platforms

In Apache, the SSLProtocol directive can be used to restrict protocols. For example, in an environment that supports the relevant versions, use:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Also check global settings, virtual host configurations, and their inheritance relationships. When using a CDN, cloud load balancer, or SaaS website-building platform, adjust the minimum version in the console of the component that actually handles TLS, and verify visitor and origin connections separately.

In scenarios involving an integrated website-building and marketing service platform such as 易营宝, website pages, marketing domains, CDNs, and origin servers may be managed by different parties. Before implementation, clarify who is responsible for configuring each endpoint and how it will be verified. Do not assume that “the platform has deployed a certificate” means “legacy protocols have been disabled on all endpoints.”

Verification must confirm both that legacy versions are rejected and that newer versions work

Being able to open a website in a browser only shows that some protocol negotiation succeeded; it does not prove that older versions have been disabled. Initiate handshakes for specific versions against the same domain:

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Replace the example domain with the actual domain. The expected result is that TLS 1.0 and TLS 1.1 cannot complete a handshake, while TLS 1.2 works normally. If TLS 1.3 is intended to be available, verify that it succeeds as well. -servername supplies SNI to prevent the request from reaching the wrong virtual host.

An error during a legacy protocol test does not necessarily mean the server rejected the protocol. The local OpenSSL installation may already prohibit older protocols or may not have any compatible legacy cipher suites available. If the client fails before sending a handshake, the result cannot be used as evidence that the server has disabled the protocol. Check the error message and cross-validate using a TLS scanning tool with the appropriate probing capabilities.

Check public domains and origin servers separately. To connect directly to an origin server, replace -connect with the origin server IP while continuing to specify the domain with -servername. Also test IPv4, IPv6, backup endpoints, and different deployment nodes. Record the test time, target address, and negotiation results for acceptance and subsequent troubleshooting.

Confirm compatibility across the business workflow

Older operating systems, embedded devices, or API clients that have not been updated for a long time may be unable to connect after the change. Before deployment, identify dependencies using connection logs, a list of callers, and business testing. Pay particular attention to inquiry submissions, payment redirects, order callbacks, marketing data interfaces, and third-party synchronization tasks.

Where possible, resolve compatibility issues by upgrading the client, runtime environment, or interface component. If a transition period is genuinely necessary, consider an isolated, dedicated endpoint and restrict its access scope with a clearly defined retirement date. Do not reopen the entire main website just for one legacy caller. During the rollout, monitor handshake errors, callback failures, and key form results; being able to open a page does not mean that transaction or lead-generation workflows are working properly.

Disabling legacy TLS is not the entirety of HTTPS security work. Cipher suites under TLS 1.2 still need to be reviewed, and certificate chains, domain matching, expiration management, and mixed content must also be handled separately. HTTP redirects and HSTS serve distinct purposes and cannot replace protocol restrictions. At handoff, retain an endpoint inventory, the effective configuration, and verification records. Check against the same baseline whenever marketing domains are added or the CDN is migrated.