Which approach will meet these requirements while protecting the external certificate during a breach?
Use a Network Load Balancer (NLB) to pass through traffic on port 443 from the internet to port 443 on the instances.
Purchase an external certificate, and upload it to the AWS Certificate Manager (for use with the ELB) and to the instances. Have the ELB decrypt traffic, and route and re-encrypt with the same certificate.
Generate an internal self-signed certificate and apply it to the instances. Use AWS Certificate Manager to generate a new external certificate for the ELB. Have the ELB decrypt traffic, and route and re-encrypt with the internal certificate.
Upload a new external certificate to the load balancer. Have the ELB decrypt the traffic and forward it on port 80 to the instances.
Explanations:
A Network Load Balancer (NLB) operates at the transport layer and does not handle SSL/TLS termination, meaning it cannot decrypt the traffic. This would expose the application instances to potential vulnerabilities as the certificate and decryption key would be directly on the instances.
Uploading the same external certificate to both the ELB and the instances would expose the private key on the instances, defeating the purpose of securing the private key. The certificate should only be on the load balancer to avoid this risk.
Using an internal self-signed certificate on the instances ensures that the private key is not exposed in case of an application breach. The ELB decrypts incoming HTTPS traffic using the external certificate and re-encrypts it using the internal certificate, ensuring that data remains encrypted while preventing key exposure on the instances.
Decrypting HTTPS traffic at the ELB and forwarding it as HTTP (port 80) to the instances would result in data being transmitted unencrypted between the load balancer and the instances, violating the requirement for encryption in transit.