TLS Configuration Checker
Provides a live first-pass view of protocols, certificate matching, SNI, ALPN, HSTS, and coarse cipher quality.
Web SecurityHardening TLS Without Guessing at Client Compatibility
A strong TLS policy is not the newest configuration fragment you can paste into a load balancer. It is the narrowest protocol surface your measured clients can use reliably, with explicit exceptions, observable handshakes, and a retirement date for every concession to legacy.
Define the client population before the baseline
For a public browser site, TLS 1.2 and TLS 1.3 are the sensible baseline. TLS 1.0 and 1.1 are obsolete, fail common security baselines, and usually survive only because nobody has proved they can be disabled. That does not mean every endpoint has the same audience. Payment terminals, embedded controllers, warehouse scanners, Java runtimes, and partner integrations can outlive browser assumptions by a decade. Blocking them blindly is not hardening; it is an outage with a security label.
Segment first. Give modern public traffic a modern endpoint, and isolate genuinely necessary legacy clients on a separate hostname, listener, network path, or gateway with narrower access and a removal plan. Never weaken the main site because one unidentified device “might” depend on it. Probe the named public endpoint with the TLS Configuration Checker for protocol acceptance, certificate-name matching, SNI, ALPN, HSTS evidence, and coarse cipher findings. It is a first-pass observation from one vantage point, not a full compliance scan.
Protocol versions remove whole families of mistakes
Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1 unless a documented exception has current evidence and an owner. TLS 1.3 is not merely “TLS 1.2 with newer ciphers”: it removes obsolete negotiation choices, encrypts more of the handshake, and limits cipher suites to modern AEAD constructions. Keep TLS 1.2 for broad compatibility, but constrain it deliberately. Version floors should be configured at every terminating layer — CDN, ingress, appliance, service mesh, and origin — because an overlooked alternate listener still counts as exposure.
Test SNI and ALPN as part of protocol behavior. Connecting by IP can show the default virtual host and wrong certificate, while real clients send a hostname. Missing ALPN does not normally break HTTPS; it silently prevents HTTP/2 negotiation and leaves traffic on HTTP/1.1. Also test IPv4 and IPv6, regional edges, resumed connections, and non-443 services where applicable. “The browser worked from my desk” proves one path and one handshake, nothing more.
Cipher policy matters mostly where TLS 1.2 remains
For TLS 1.3, implementations expose a short standardized family of AEAD suites and key exchange is configured separately. Long copied cipher strings largely concern TLS 1.2 and older. There, prefer ECDHE key exchange with AES-GCM or ChaCha20-Poly1305, retain both ECDSA and RSA authentication only if your certificate and client population require them, and remove static RSA key exchange, RC4, 3DES, export suites, anonymous suites, and non-AEAD leftovers. The exact spelling is library-specific; the security property is not.
Server cipher preference can make sense on TLS 1.2 when old clients offer weak and strong choices in poor order. But “strongest first” is not a universal performance rule: hardware AES acceleration favors AES-GCM, while mobile devices without it may perform better with ChaCha20. TLS 1.3 generally lets the endpoints negotiate among a compact strong set. Keep the policy readable. A 200-character cipher incantation inherited from an old blog is hard to review and may contain exclusions that changed meaning across OpenSSL versions.
Forward secrecy is a key-exchange property
Forward secrecy means compromise of the certificate's long-term private key does not retrospectively decrypt previously recorded sessions. Ephemeral Diffie–Hellman provides it: ECDHE is the normal choice, and TLS 1.3 uses ephemeral exchange in its standard full handshake. Static RSA key exchange does not. An RSA certificate can still participate in an ECDHE suite — the certificate signs the exchange; it does not dictate that key exchange be static RSA.
Use supported curves such as X25519 and secp256r1 according to your platform and client evidence, and let maintained library defaults carry most of the burden. Custom finite-field DH parameters need appropriate size and operational care; weak or reused parameters can defeat an otherwise respectable suite list. Protect long-term keys in a controlled keystore or HSM where risk warrants it, rotate them through tested automation, and inspect what is deployed with the SSL Certificate Decoder. It reports certificate names, validity, algorithms, fingerprints, SPKI hashes, extensions, and presented chain, but does not claim trust-store or revocation validation.
Resumption is valuable state with a security lifetime
Session IDs and session tickets reduce latency and CPU by resuming an earlier security context. They also create key material whose lifetime and distribution matter. A ticket-encryption key shared indefinitely across a fleet weakens forward-secrecy goals and widens the blast radius of one stolen key. Rotate ticket keys, limit ticket lifetime, control which nodes receive them, and understand what happens during rolling deploys. If you cannot manage shared ticket keys safely, accepting fewer resumptions may be the honest trade.
TLS 1.3 zero-round-trip data is a separate decision. 0-RTT reduces latency for returning clients, but early data can be replayed by an attacker even though it remains encrypted in transit. Use it only for operations that are safe to repeat and do not cause state changes: never treat a request as replay-safe merely because it uses GET. Authentication transitions, purchases, counters, signed URLs, and rate-limit consumption can all have side effects. Many ordinary sites should leave 0-RTT disabled; one saved round trip is not automatically worth a new application-level replay model.
Measure, change one boundary, and watch failures
Start with handshake telemetry: negotiated TLS version, cipher, SNI, ALPN, client family where privacy policy permits, failure reason, and endpoint. Separate client incompatibility from certificate errors, routing failures, and application resets. Run a time-bounded observation window, identify actual legacy use, contact owners, and test a canary endpoint before changing the floor. Synthetic probes catch configuration drift; real traffic tells you which compatibility you are buying.
After rollout, watch handshake failure rate, business transaction rate, support signals, and regional differences. Preserve a fast rollback, but do not let rollback become permanent policy by accident. Every exception needs an owner, a constrained endpoint, compensating controls, and an expiry date. If the service uses DNSSEC-authenticated TLSA policy, the DANE Validator can assess owner-name construction, TLSA syntax, DNSSEC context, and an optional certificate comparison; remember that a certificate or key rollover can break validating clients even when ordinary PKI remains happy. Hardening succeeds when the measured attack surface shrinks and the dependency map becomes clearer.