2.2 TLS 1.3 and Certificate Automation: From Handshake to Rotation
TLS simultaneously establishes session keys, authenticates endpoints, and secures 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
Simplified flow:
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
↓
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. Any one of these components missing means the connection cannot be considered a secure channel to the intended service.
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 incorrect certificate issuance, 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, assumptions like "using HTTPS means all information is hidden" are invalid.
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 hidden side effects like billing charges, consumption of one-time tokens, or audit logging implications. 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 also requests and validates the client's certificate, CertificateVerify. 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, the timing for re-handshaking in connection pools and long-lived connections must be evaluated within the revocation window.
ACME Turns Domain Control Verification into a Protocol
The core object relationships in ACME:
Account → Order → Authorization → Challenge → Finalize CSR → CertificateChallenges like HTTP-01 and DNS-01 prove that the applicant controls the corresponding namespace. 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;
- Issue new certificates and private keys atomically to prevent mismatches;
- 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.
Private PKI Must Control Fault Radius
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 issues new leaf certificates, and finally removes the old root, 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.
The next chapter shifts focus from service identity to user and application identity: authentication factors, sessions, OAuth/OIDC, and authorization policies.