A TLS endpoint can have a valid certificate and still use a poor security configuration. The certificate identifies the server, but the handshake also decides how the connection establishes secrets and protects application data. Certificate renewal, cipher selection, and negotiation policy solve different parts of the problem.
I find it useful to treat these as separate engineering decisions. This makes configuration easier to review and helps explain failures that otherwise appear as a generic “TLS handshake error.”
Start by separating the keys
In a typical certificate-authenticated TLS 1.3 connection, the server’s certificate key signs handshake data to prove possession of the private key. An ephemeral key exchange establishes a shared secret, from which TLS derives symmetric traffic keys.
These keys have different lifetimes. Replacing a certificate does not update the traffic keys of an existing connection. TLS 1.3 provides KeyUpdate for that purpose, but it does not renew the certificate or authenticate the peer again.
Ephemeral key exchange also provides forward secrecy: later theft of the certificate’s private key should not reveal previously recorded sessions, assuming the ephemeral secrets were erased. TLS 1.3 resumption needs some care here because PSK-only resumption does not provide the same forward-secrecy property as resumption combined with a fresh Diffie-Hellman exchange. These distinctions come from the TLS 1.3 specification.
Operationally, this means “rotate the TLS keys” is too vague. Specify whether you mean the certificate key pair, connection traffic keys, or secrets used for session resumption.
Choose cipher suites with the protocol version in mind
TLS 1.2 and TLS 1.3 use cipher suite names differently.
A TLS 1.2 suite such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 describes ephemeral key exchange, RSA authentication, and authenticated encryption. In TLS 1.3, TLS_AES_128_GCM_SHA256 selects the record protection algorithm and key-derivation hash. Key exchange groups and signature algorithms are negotiated separately. An RSA certificate therefore does not require a TLS 1.3 suite with “RSA” in its name. RFC 8446 explains this change.
For a general web service, I would start with TLS 1.3 and retain TLS 1.2 where client compatibility requires it. RFC 9325 says implementations must not negotiate TLS 1.0 or TLS 1.1. For TLS 1.2, use forward-secret ECDHE suites with authenticated encryption, such as AES-GCM, and exclude static RSA key exchange. RFC 9325 provides the deployment guidance.
AES-GCM and ChaCha20-Poly1305 are practical choices. AES hardware acceleration can make AES-GCM attractive, while ChaCha20-Poly1305 can perform well without it. Measure on the hardware you support before imposing a performance-driven preference. A longer key size alone does not establish which configuration is appropriate.
Avoid copying a long cipher string without checking your library’s settings. TLS 1.2 and TLS 1.3 often have separate configuration controls.
Make certificate lifetime an operational decision
Certificate validity limits how long a credential remains acceptable. It does not specify how frequently connection traffic keys change, and renewing with the same private key does not rotate that key.
As of November 2, 2026, the CA/Browser Forum requirements cap publicly trusted subscriber certificates issued from March 15, 2026 through March 14, 2027 at 200 days. The scheduled maximum becomes 100 days on March 15, 2027, and 47 days on March 15, 2029. These limits concern public server certificates; internal PKI has a different policy boundary. Providers can also choose shorter lifetimes. See the current Baseline Requirements, section 6.3.2.
Shorter lifetimes reduce how long an expired or compromised credential can remain usable without replacement. They also make renewal reliability more important. A shorter lifetime is a poor operational choice if renewal depends on someone remembering a calendar event.
Use automated issuance and renewal where possible. ACME standardizes interactions between certificate clients and certificate authorities, including authorization and issuance. Deployment still needs its own verification: successfully obtaining a certificate does not prove that every load balancer has loaded it.
I would monitor the certificate actually served by each endpoint, renew with enough time for retries, and alert when deployment stalls. Generate a fresh certificate key pair on a defined schedule, preferably during automated renewal where supported. Protect private keys through restricted access or a managed key service appropriate to the deployment.
If a key is compromised, replace it and revoke the affected certificate. Waiting for expiration is not an incident response plan.
Define what negotiation is allowed to accept
The client advertises capabilities, and the server chooses a compatible combination. A handshake can fail even when both sides support AES-GCM because they lack a compatible signature algorithm, key exchange group, or certificate.
Set an explicit protocol minimum and an allowed algorithm policy. If no acceptable combination exists, let the connection fail. Do not add application retry logic that progressively enables older protocols to make the error disappear.
Authentication also requires checking the intended server identity. A certificate chain trusted by the client does not, by itself, prove that the certificate belongs to the requested hostname. Clients need identity matching against the appropriate subject alternative name, following RFC 9525. Disabling hostname verification turns a deployment problem into an authentication weakness.
For a typical API, I would leave TLS 1.3 early data, or 0-RTT, disabled unless the application explicitly handles replay. Requests that create orders or trigger payments need more consideration than ordinary read requests. RFC 9325 discusses this limitation.
Verify the endpoint clients actually reach
A focused OpenSSL probe can check one allowed TLS 1.3 combination:
openssl s_client \
-connect api.example.com:443 \
-servername api.example.com \
-verify_hostname api.example.com \
-verify_return_error \
-tls1_3 \
-ciphersuites TLS_AES_128_GCM_SHA256 \
-brief </dev/nullReplace the hostname with your endpoint and use an appropriate local trust store. -servername sends SNI; -verify_hostname checks identity. -verify_return_error makes certificate verification errors abort the handshake. These options are documented in OpenSSL’s client reference.
One successful probe proves only that this combination works from that client. Test your supported clients, confirm prohibited versions fail, and check every TLS termination point, including a CDN or load balancer.
A maintainable TLS policy connects cryptographic choices with reliable operations. Choose compatible modern algorithms, automate certificate replacement, and define negotiation rules clearly enough that both successful connections and rejected connections are expected behavior.
