SSL/TLS Solution for Webserver Infrastructure | AWS Certified Solutions Architect - Professional

Answers - A and B.

This scenario requires you to set up the web servers so that the HTTPS clients must be authenticated by the client-side certificate (not the server-side certificate)

There are two ways of architecting this - with ELB and without ELB.

(a) With ELB, if you use HTTPS listeners, you have to deploy the server-side certificate - which is not desired.

So, you need to use the TCP listener so that the HTTPS client requests do not terminate at the ELB.

They pass through ELB and terminate at the webserver instances.

(b) Alternatively, without ELB, you can directly use the webserver to communicate with the clients or set up a Route53 Record Set with the public IP address of the webserver(s) such that the client requests would be directly routed to the webserver(s).

Option A is CORRECT because it uses TCP (443) listener that relays requests to the backend instances as-is.

This terminates the client certificate on the webserver instances rather than the ELB.Option B is CORRECT because it uses Route53 Record Set with the public IP address of the webserver(s) such that the client requests would be directly routed to the webserver(s).

Option C is INCORRECT because if you use HTTPS listeners, it does not support client certificates.

Option D is incorrect because this setting should be an "origin" and not a "target"

The phrase should be "Configure your web servers as the origins for a CloudFront distribution"

Please check below AWS docs for more details.

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ssl-server-cert.html https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html#create-https-lb-console

Please refer to the following link to TCP to pass through traffic to the ELB "as-is"

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/https-tcp-passthrough.html

To configure an SSL/TLS solution that requires HTTPS clients to be authenticated by a web server using client certificate authentication, there are several options to consider for configuring the web server infrastructure.

A. Configure ELB with TCP listeners on TCP/443 and place the web servers behind it.

This option involves using the Elastic Load Balancer (ELB) to distribute incoming traffic across multiple web servers. With this approach, the web servers would sit behind the ELB, and the ELB would be configured with TCP listeners on TCP/443. This approach is useful if you don't need to terminate SSL/TLS at the load balancer level and prefer to keep it at the web server level. However, if you need to terminate SSL/TLS at the load balancer level, this approach may not be suitable.

B. Configure your web servers with EIPs. Place the web servers' IPs as endpoints of Route53 Record Sets and configure health checks against all web servers.

This option involves configuring your web servers with Elastic IP addresses (EIPs) and placing the web servers' IPs as endpoints of Route53 Record Sets. You would then configure health checks against all web servers to ensure that traffic is only routed to healthy web servers. This approach is useful if you need to have more control over the web server infrastructure and prefer not to use a load balancer. However, this approach can be more challenging to manage and scale as the infrastructure grows.

C. Configure ELB with HTTPS listeners, and place the web servers behind it.

This option involves using the ELB to terminate SSL/TLS and distribute incoming traffic across multiple web servers. With this approach, the ELB would be configured with HTTPS listeners, and the web servers would sit behind the ELB. The ELB would then handle SSL/TLS termination and forward the decrypted traffic to the web servers. This approach is useful if you need to terminate SSL/TLS at the load balancer level and want to have more control over the web server infrastructure.

D. Configure your web servers as the targets for a CloudFront distribution. Use custom SSL certificates on your CloudFront distribution.

This option involves using Amazon CloudFront to distribute incoming traffic across multiple web servers. With this approach, the web servers would be configured as targets for a CloudFront distribution, and custom SSL certificates would be used on the CloudFront distribution. This approach is useful if you need to distribute traffic globally and want to take advantage of CloudFront's caching and edge locations. However, this approach can be more complex to set up and manage.

In summary, option C is the most suitable option for configuring an SSL/TLS solution that requires HTTPS clients to be authenticated by a web server using client certificate authentication. However, the best option would depend on your specific requirements and constraints.