How to check supported TLS versions

Ask for TLS 1.3 explicitly

Suppose you want to verify TLS 1.3 after a hosting change. This OpenSSL 3 command offers only TLS 1.3 to the hostname on port 443. Replace example.com in all three positions. SNI selects the intended virtual host; hostname and certificate verification remain enabled.

This is an interactive diagnostic command. Read the negotiated protocol and verification summary before ending it. A successful handshake with TLS 1.3 demonstrates support at the endpoint reached; a connection or certificate error needs separate interpretation. A TCP connection alone is not a completed TLS test.

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -verify_return_error -tls1_3 -brief

1. Run openssl version first and use an OpenSSL 3 binary; the system command may be another implementation.
2. Run the command and record the protocol, verification result and any error. Do not treat a partial connection as success.
3. Press Ctrl+C after recording the completed handshake, then run the separate TLS 1.2 test below. An unresponsive attempt remains inconclusive.

Reference: OpenSSL 3: version-specific TLS client tests

Read support separately from certificate trust

New CheckSSL scans attempt limited probes of TLS 1.0 through 1.3 after obtaining certificate details. The negotiated version from the initial handshake already demonstrates support. Other versions are tested against the same connected IP, with the original hostname used for SNI. Scan budgets can prevent completion.

These compatibility probes are diagnostic and do not independently establish certificate trust. Supported can therefore appear alongside a failed trust finding. Read the connection, hostname and validity findings separately. The negotiated cipher is one selected suite; the scan does not enumerate every cipher the server accepts.

Test TLS 1.2 and classify failures

This counterpart offers only TLS 1.2. Run it separately and end it after the handshake summary. The exact-version flags are different from disabling one version: excluding TLS 1.3 alone would not establish which other version was selected.

An unrecognized option, unavailable protocol or local cipher-policy failure says something about your client. It does not prove the server rejects that TLS version. A generic handshake failure can also involve cipher overlap, client authentication or a network device. Keep the full error and compare it with server logs.

If certificate verification fails, retain verification and fix the certificate or trusted CA configuration appropriate to your environment. The command uses your local OpenSSL trust store, which can differ from a browser’s. Do not describe that failure as evidence that TLS 1.2 is disabled. Likewise, an unknown legacy-version probe is not a confirmed rejection.

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -verify_return_error -tls1_2 -brief

Reference: OpenSSL 3: exact TLS version options

Apply the policy where public TLS terminates

If a CDN terminates visitor TLS, change its visitor-facing protocol policy. Changing an origin behind it does not automatically change public support. For a direct Nginx endpoint, the fragment below belongs inside the existing http block when TLS 1.2 and 1.3 are the intended shared policy. Preserve the rest of the configuration.

Check the installed Nginx and linked OpenSSL capabilities, plus existing server-level overrides. Protocol selection can use the default server’s settings before SNI selection, so review all virtual hosts on the listener. Test with nginx -t, deploy through the normal reload process and verify the public result.

# Inside the existing http { ... } block:
ssl_protocols TLSv1.2 TLSv1.3;

Reference: Nginx: ssl_protocols and default-server selection

Verify the change without overstating coverage

TLS 1.0 and 1.1 are deprecated; confirmed support needs a configuration review. TLS 1.2 support is not itself a failure, and a TLS 1.3 result alone is not a complete security assessment. Cipher configuration, certificates and supported clients still matter.

Record the hostname, time, connected endpoint and intended policy before and after the change. A single scan does not cover every CDN region, load-balancer node or address family. An unknown result remains unknown even when the intended configuration looks correct.

1. Create a fresh CheckSSL scan and repeat the explicit TLS 1.2 and TLS 1.3 tests required by your policy.
2. Check whether legacy-version results are confirmed rejections or still inconclusive.
3. Verify other public hostnames and relevant endpoints, then test the browsers and API clients you support.
4. Confirm certificate trust still passes and retain the previous configuration for a controlled rollback if needed.

Reference: RFC 9325: current TLS protocol recommendations