2.2 TLS 1.3 and Certificate Automation: From Handshake to Rotation
TLS establishes session keys, authenticates the server or both peers according to the selected mode, and protects subsequent records. It's not simply "using a certificate public key to encrypt HTTP": in TLS 1.3, shared secrets are typically derived from ephemeral (EC)DHE key exchanges, and the certificate private key is used solely to sign the handshake context.
TLS 1.3 Handshake Binding of Negotiated Results
This simplified full handshake uses certificate authentication, without a client certificate, HelloRetryRequest, or early data. PSK resumption uses a different message sequence:
ClientHello
supported_versions, cipher_suites, key_share, SNI, ALPN
↓
ServerHello + key_share
↓ Derive handshake keys jointly
EncryptedExtensions
Certificate
CertificateVerify ← Server signs handshake transcript with its certificate private key
Finished ← Proves handshake keys and transcript are intact
↓ Client validates the server
Client Finished ← Client confirms the handshake transcript
↓
Subsequent records use application traffic keysThe certificate validation answers whether this public key is trusted for the target service name, CertificateVerify confirms whether the peer holds the corresponding private key, Finished binds the previously negotiated parameters and derived keys together. These are the responsibilities in this certificate-authenticated flow. A PSK handshake may omit certificates and authenticate through an established PSK trust relationship.
TLS 1.3 cipher suites only include AEAD and hash algorithms; key exchange and signature algorithms are negotiated separately in extensions. This differs from TLS 1.2's suite naming, making old string-based checks insufficient to determine full security properties.
SNI and ALPN in Service Selection
SNI informs the server on a shared IP address of the hostname the client is attempting to reach, allowing the server to select the appropriate certificate and virtual host. ALPN negotiation determines the application protocol (such as HTTP/2 or HTTP/1.1) used for the connection. Misconfigurations in either can result in serving the wrong certificate, routing to the wrong tenant, or protocol downgrade.
SNI is typically present in the traditional TLS 1.3 ClientHello message, where TLS itself does not obscure the accessed hostname. When protecting this metadata, attention must be paid to the actual client capabilities of ECH, DNS, and server ecosystem support, even with successful ECH, destination IPs, traffic sizes, and timing may remain visible. Sending SNI selects a certificate; it does not prove the client has checked the hostname.
0-RTT Trades Replay Risk for Latency
When restoring a session, TLS 1.3 allows the client to send early data before completing the full handshake. However, 0-RTT does not provide standard replay protection, meaning an attacker could cause the server to receive the same request multiple times.
As a result, operations such as fund transfers, order creation, permission modifications, or credential issuance should not accept 0-RTT. Even if a GET request is designed to be idempotent, it must be verified that it does not have replay effects such as duplicate charges, one-time token consumption, or unacceptable audit load. Ordinary repeated access logging does not itself violate HTTP idempotency. Replay protection must be co-designed between the application and the TLS termination layer, it cannot rely solely on a library toggle.
mTLS Authenticates the Certificate Subject, Not Business Authorization
In mutual TLS, the server requests a client certificate, validates its chain and identity, and checks the client’s CertificateVerify proof of key possession. This approach is well-suited for controlled devices, service-to-service identity, and high-integrity management interfaces. However, it must be carefully mapped through the following chain:
validated certificate identity
→ workload / device principal
→ authorization policy
→ permitted resource and actionA blanket rule like "any certificate from a trusted CA" is typically too permissive. Instead, validation must include checks for SAN/URI identity, extended key usage (EKU), certificate hierarchy, environment context, and revocation status. It's essential to restrict which certificate issuers are allowed to issue certificates for specific namespaces. Additionally, when certificates rotate, connection pools and long-lived connections may keep an earlier session without automatically revalidating identity when files on disk change. Connection lifetime limits, reauthentication, or active closure may be needed within the revocation window.
ACME Turns Domain Control Verification into a Protocol
The core object relationships in ACME:
Account → Order → Authorization → Challenge → Finalize CSR → CertificateHTTP-01 and DNS-01 prove the applicant can satisfy the corresponding domain-control check. They do not establish that the website operator is trustworthy, lawful, or serving benign content. DNS-01 is well-suited for wildcard domains and services that don't expose HTTP directly, but DNS API credentials often carry broad permissions. These should be restricted to specific zones or records, short-lived credentials should be used, and the certificate issuance controller should be isolated.
Certificate automation is not a cron job:
- Proactively renew certificates with randomized jitter to avoid a storm of simultaneous renewals;
- Publish a matching certificate and private key as one version, for example by preparing a new directory and switching a version pointer; replacing two files separately is not atomic;
- Allow the process to reload or hot-swap, and verify that the actual listener has loaded the new serial;
- Maintain a brief overlap period to support ongoing connections and multi-replica rolling updates;
- Use external probes to validate the certificate chain, SANs, protocols, and remaining validity;
- Alert separately for issuance failures, challenge failures, reload errors, and handshake issues.
Monitoring only the expiration date stored on disk for .pem will miss cases where a load balancer continues serving the old certificate.
Check the Live Listener
This command requires an existing TLS service and uses roots.pem to specify the test’s trusted roots. Substitute the actual test address. When connecting directly to a backend IP, retain the service name to be verified.
openssl s_client -connect api.example.com:443 \
-servername api.example.com -verify_hostname api.example.com \
-verify_return_error -CAfile roots.pem -tls1_3 \
-alpn h2,http/1.1 </dev/null-servername sends SNI, -verify_hostname checks the expected identity, and -verify_return_error makes verification errors terminate the handshake; each has a separate role. Check the protocol, negotiated ALPN, and verification result. Save the returned PEM certificate as served-leaf.pem and run openssl x509 -in served-leaf.pem -noout -serial -dates to inspect its serial and validity. Then use an incorrect hostname and confirm handshake failure. Forcing -tls1_3 proves support in this test, not that older protocols are disabled.
Limit the Impact of Private PKI Failures
Service meshes or workload identity platforms often issue short-lived certificates lasting hours to days. While short lifetimes reduce the risk of long-term static credential exposure, they shift availability dependencies onto the issuer, identity attestation, clock synchronization, and certificate rotation agents.
Root keys should be offline or strictly protected, with intermediate CAs isolated by environment, region, or use case. Rotating a CA requires a phased overlap where the trust bundle first includes the new root, then migrates issuers and leaf certificates, and removes the old root after old credentials and sessions have retired, direct replacement would sever the entire cluster.
TLS Production Baseline
- Prioritize TLS 1.3; when TLS 1.2 compatibility is required, adhere to BCP 195 restrictions on protocols and cipher suites.
- Disable the default continuation path when certificate validation fails.
- Use key exchange mechanisms that provide forward secrecy and securely manage session ticket keys.
- Clearly define whether 0-RTT is enabled and which requests are acceptable.
- Validate complete certificate chains, reference identities, and intended usage for both external and internal services.
- Automate the issuance, renewal, deployment, reload, and external validation process to ensure a verifiable end-to-end workflow.
- Monitor handshake failure rates, protocol versions, certificate expiration dates, and anomalies related to new certificate issuance.
Continue with User Authentication and Sessions, followed by OAuth/OIDC and authorization policies.