A public Application Load Balancer for a patient portal listens only on HTTP. A certificate for the portal name is already issued in AWS Certificate Manager. How should inbound traffic be encrypted?
Select an answer to reveal the explanation.
Short Explanation
HTTP is a postcard, and anyone on the path can read it. You add an HTTPS listener that uses your ACM certificate and send people to that listener. Sticky sessions do not encrypt the portal, and leaving the listener on HTTP keeps the postcard.
Full Explanation
An Application Load Balancer encrypts client traffic on an HTTPS listener, and that listener can use a certificate that is already in ACM. Adding the HTTPS listener and sending clients to it, by pointing them at HTTPS and redirecting the existing HTTP listener, takes the portal off cleartext. Copying a certificate file onto the instances and leaving the load balancer on HTTP means the hop clients use is still unencrypted. Sticky sessions pin a client to a target. They do not turn HTTP into HTTPS. Access logs write request records to a bucket. That bucket is not a certificate and cannot be attached to a listener as one. Caveat: the certificate has to cover the name clients use, and the load balancer security group has to allow the HTTPS port, or the new listener will not complete the handshake. The instances behind the load balancer do not need their own copy of this certificate for the client hop. Operational check: request the portal name over HTTPS and confirm the certificate presented is the ACM certificate, and confirm plain HTTP requests redirect to HTTPS.