Resilient SSL/TLS Solution for Client Certificate Authentication

Answer - A and B.

The AWS Documentation mentions the following.

You can create a load balancer that uses the SSL/TLS protocol for encrypted connections (also known as SSL offload)

This feature enables traffic encryption between your load balancer and the clients that initiate HTTPS sessions, and for connections between your load balancer and your EC2 instances.

Amazon CloudFront is a global content delivery network (CDN) service that accelerates delivery of your websites, APIs, video content or other web assets.

It integrates with other Amazon Web Services products to give developers and businesses an easy way to accelerate content to end users with no minimum usage commitments.

Currently, ELBs cannot support authentication for the client side.

SSL/TLS certificate is required for two-way SSL authentication to succeed.

The second way is to configure the webservers with Elastic IP address and have the web servers act as the endpoint for the traffic.

Let Route53 DNS server send requests to these webservers in a round-robin fashion.

For more information on AWS ELB listeners, please visit the below URL:

http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-https-load-balancers.html

For more information on Cloudfront, please visit the below URL:

https://aws.amazon.com/cloudfront/

Option C is incorrect.

The question is asking for a resilient solution.

Therefore configuring Rourte53 record set and the corresponding health checks would be the correct answer instead of directly placing the web servers behind the ELB.Option D is incorrect.

CloudFront does not support client authentication with client-side SSL certificates.

If an origin requests a client-side certificate, CloudFront drops the request.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomClientSideSslAuth

You can use API Gateway to generate an SSL certificate and use its public key in the backend to verify that HTTP requests to your backend system are from API Gateway.

This allows your HTTP backend to control and accept only requests originating from Amazon API Gateway, even if the backend is publicly accessible.

https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html

An ELB Classic Load Balancer cannot validate a client side certificate, so it must be passed through as standard TCP on port 443 to let the EC2 instance handle the validation.

?

Proxy Protocol is an Internet protocol used to carry connection information from the source requesting the connection to the destination for which the connection was requested.By default, when you use Transmission Control Protocol (TCP) for both front-end and back-end connections, your Classic Load Balancer forwards requests to the instances without modifying the request headers.

So in this configuration Client side certificate can be used for authentication by the back end server.

So.

Option A seems to be correct.

To design an SSL/TLS solution that requires HTTPS clients to be authenticated by the web server using client certificate authentication, the following two options can be considered for configuring the web server infrastructure:

Option A: Configure ELB with TCP listeners on TCP/443 and place the web servers behind it. In this option, the Elastic Load Balancer (ELB) is configured with TCP listeners on TCP/443, which is the standard HTTPS port. The ELB then distributes incoming traffic to the web servers behind it. This option is resilient because the ELB can detect and automatically recover from failed web servers. By placing the web servers behind the ELB, the servers are shielded from direct exposure to the internet, increasing security.

Option C: Configure ELB with HTTPS listeners, and place the web servers behind it. This option is similar to Option A, but instead of TCP listeners, HTTPS listeners are used on the ELB. This allows the ELB to terminate SSL/TLS connections, reducing the computational burden on the web servers. The ELB then passes on the decrypted traffic to the web servers. Like Option A, the ELB can detect and automatically recover from failed web servers, increasing resilience.

Option B: Configure your web servers with EIPs, place the web servers in a Route53 Record Set, and configure health checks against all web servers. This option involves assigning Elastic IPs (EIPs) to the web servers and placing them in a Route53 Record Set, which is a DNS service provided by AWS. Health checks are then configured against all web servers, allowing the system to detect and automatically recover from failed servers. However, this option does not provide the same level of load balancing and traffic management capabilities as the ELB options.

Option D: Configure your web servers as the origins for a CloudFront distribution. Use custom SSL certificates on your CloudFront distribution. This option involves using CloudFront, a content delivery network (CDN) service provided by AWS, as a front-end to the web servers. CloudFront uses custom SSL certificates to secure the connection between the client and the CDN, and between the CDN and the web servers. However, this option does not provide the same level of client certificate authentication capabilities as the ELB options.

In conclusion, Options A and C, which both involve using ELB, are the best options for configuring the web server infrastructure in a resilient SSL/TLS solution that requires client certificate authentication.