Protect every encrypted connection—and plan renewal

A customer request does not travel through one long encrypted tunnel. It crosses separate connections: client to CloudFront, CloudFront to the load balancer, load balancer to the application, and application to the database. TLS on one connection says nothing about the next.

Draw each connection as its own row. Record both endpoints, the hostname the client checks, where TLS ends, and whether another TLS connection begins. If policy says every hop is encrypted, every row needs a passing answer.

Now add the lifecycle owner. For each certificate, record who requests it, proves control of the domain, renews it, deploys it, monitors it, and can roll back a bad replacement. “ACM manages it” is incomplete when DNS validation records or the service attachment disappear.

Keep transport encryption separate from encryption at rest. TLS protects bytes moving across one connection. A KMS key protects supported stored data through a different authorization and lifecycle path.

Before choosing a service, test one failure: expire a test certificate, break validation, or remove the next-hop TLS configuration. The failed connection should be named precisely rather than reported as a vague application outage.

AWS Certificate Manager can issue and renew public certificates for supported AWS integrations. The certificate still has to exist in the Region required by the service that presents it.

A CloudFront viewer certificate from ACM must be in us-east-1. A Regional Application Load Balancer uses an ACM certificate in the load balancer's Region. These are two different TLS connections and may need two certificates.

The origin connection has its own rules. If CloudFront connects to an HTTPS origin, the origin presents a certificate whose name and trust chain must satisfy that connection. Encrypting the viewer connection does not automatically encrypt CloudFront to the origin.

Managed renewal reduces routine work only while its prerequisites remain valid. Preserve domain validation, keep the certificate attached to a supported service, and monitor renewal state before expiry. Imported certificates remain a customer renewal job.

During replacement, keep enough overlap for deployment and rollback. Test the intended hostname, certificate chain, protocol, and representative clients. A certificate can be valid yet still fail because it is in the wrong Region, attached to the wrong listener, or untrusted by an older private client.

Certificate renewal, KMS key rotation, and re-encryption solve different lifecycle problems. Start by naming what must change: a TLS credential, the backing material of a logical KMS key, or the trust path protecting existing ciphertext.

Renewal gives future TLS handshakes a new certificate. It does not rewrite stored data. Eligible KMS rotation changes backing key material while keeping the same logical KMS key, and KMS retains the material needed to decrypt older ciphertext.

Routine KMS rotation therefore does not re-encrypt existing records. It also does not repair data encrypted with a compromised data key. When compromise changes the trust boundary, create a new trusted key path and move producers and consumers deliberately.

Re-encryption reads data through the old authorized path and writes it through the new one. Keep the old key available until migration coverage and restore tests prove that no required ciphertext still depends on it. Deleting first can make durable data permanently unreadable.

Test the two lifecycles separately. An HTTPS test should prove certificate placement, hostname, trust, and renewal. A data test should decrypt an old record, write a new record, and restore through the intended KMS policy after rotation or migration.

Use the least disruptive operation that solves the stated problem: renew an expiring certificate, rotate eligible key material for routine policy, and re-encrypt only when the data must move to a different trust path.