Enforcing TLS 1.3 Only in OpenSSL 3.0

If your server still accepts TLS 1.0 or TLS 1.1, you’re running protocols that are known to be vulnerable to attacks such as POODLE and BEAST. Supporting multiple protocol versions also makes your TLS configuration harder to audit and increases the attack surface.

Why enforcing TLS 1.3 only helps

Dropping legacy versions hardens the server, simplifies configuration, and aligns with modern best practices without sacrificing the performance that TLS 1.3 provides. OpenSSL 3.0 gives you direct API control over the protocol range, so you can lock everything into a single, modern version.

The enforcement tools in OpenSSL 3.0

OpenSSL 3.0 introduced SSL_CTX_set_min_proto_version and SSL_CTX_set_max_proto_version. These functions let you set a hard floor and ceiling for the TLS version your server will accept. Set both to the same value and you effectively enforce that version alone.

/* Create an SSL context */
SSL_CTX *ctx = SSL_CTX_new(TLS_server_method());
/* Lock the protocol to TLS 1.3 only */
SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);
SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION);
/* Load your certificate and private key */
SSL_CTX_use_certificate_file(ctx, "server.crt", SSL_FILETYPE_PEM);
SSL_CTX_use_private_key_file(ctx, "server.key", SSL_FILETYPE_PEM);

This snippet creates an SSL_CTX, sets the minimum and maximum protocol version to TLS 1.3, then loads a certificate file. The resulting context is ready for an SSL object to be created and bound to a socket.

Diagnosing the effect

After you apply the configuration, you can check what’s actually happening with a few open-source commands. Run them from any machine that has OpenSSL installed; no root access is needed for the diagnostic queries.

• openssl version – confirms you’re running OpenSSL 3.0.x or newer.
• openssl s_client -connect your-host:443 -tls1_3 – should succeed and show a TLS 1.3 handshake.
• openssl s_client -connect your-host:443 -tls1 – should fail or fall back, indicating the server rejected the legacy version.

If the first command returns a handshake key exchange and the second returns an error or “no shared cipher”, the enforcement is working as intended.

Trade‑offs and limitations

The main trade‑off is compatibility. Clients that only speak TLS 1.0 or TLS 1.1 will be unable to connect. If you need to support those clients, you’ll need to run a separate listener with a different protocol range, or maintain a fallback configuration. This adds operational overhead, which is why the enforcement is best suited for services that can mandate a modern client.

Next steps

Start by verifying your current OpenSSL version, then apply the protocol‑range settings in your server’s startup code or configuration management tool. After redeploying, run the openssl s_client checks above to confirm that TLS 1.3 works and older versions are rejected. If a legacy client reports a failure, coordinate a client‑update plan or set up a secondary port that still permits TLS 1.x.