You are designing an SSUTLS solution that requires HTTPS clients to be authenticated by the Web server using
client certificate authentication. The solution must be resilient.
Which of the following options would you consider for configuring the web server infrastructure? (Choose 2
answers)
A.
Configure ELB with TCP listeners on TCP/4d3. And place the Web servers behind it.
B.
Configure your Web servers with EIPS Place the Web servers in a Route53 Record Set and configure health
checks against all Web servers.
C.
Configure ELB with HTTPS listeners, and place the Web servers behind it.
D.
Configure your web servers as the origins for a CloudFront distribution. Use custom SSL certificates on your
CloudFront distribution.
Explanation:
A and D
I can’t understand the difference between A and C.
Refer to
kirrim
November 9, 2016 at 3:18 pm post below for your explanation regarding difference between A and C
A is not correct , since you can’t assign client certificate for TCP listeners in ELB.
C is correct , Because you will have option to assign certification when you choose https listeners.
D also have option to choose custom certificate/Default CloudFront Certificate for your web servers.
A and D
sorry A and C
C and D
.In the option a front end listener is TCP .not mentioned about SSL.But in question mentioned HTTPs clients .So SSL (X.509) certificate is must for HTTPS. so C and D are correct.
A – will work since the SSL authentication will be handled by the end instance.
I’m wondering why B wouldn’t work? It might not be practical but would get the job done.
C – is not correct since you can’t do client certificate authentication in ELB. https://forums.aws.amazon.com/thread.jspa?threadID=58561&start=0&tstart=0
D – Can anyone confirm that Cloudfront supports client certificate validation?
this was in 2011
Just found this.
D – not correct since Cloudfront does not support client side SSL authentication http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomClientSideSslAuth
A is 100% not the answer.
Because TCP/443 or HTTPS listener either way you can configure, but you can only upload ssl certificate on HTTPS listener.
And we already know B also can’t be the answer.
So, C and D are only left.
A and C, no one said the SSL was terminating at the ELB. The webservers auth the client cert which passes through the elb.
A & B
client cert is the key.
if you use elb then it must be a simple tcp443 to pass the flow to the server so A.
as bad as B is for a design, I think it is the only other option that can do client auth.
BTW, I hate this question.
C & D.
Explanation:
http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html
HTTPS/SSL Listeners
You can create an HTTPS load balancer with the following security features.
SSL Server Certificates
If you use HTTPS or SSL for your front-end listener, you must deploy an X.509 certificate (SSL server certificate) on your load balancer. The load balancer decrypts requests from clients before sending them to the back-end instances (known as SSL termination). For more information, see SSL/TLS Certificates for Classic Load Balancers.
https://aws.amazon.com/cloudfront/custom-ssl-domains/
Custom SSL Options for Amazon CloudFront
Custom SSL certificate support lets you deliver content over HTTPS using your own domain name and your own SSL certificate. This gives visitors to your website the security benefits of CloudFront over an SSL connection that uses your own domain name in addition to lower latency and higher reliability.
This question is regarding “two-way” SSL authentication.
Currently, ELBs cannot support authentication for the client side SSL/TLS cert required for two-way SSL authentication to succeed. Therefore, you only have two options:
A. Configure the ELB with a TCP/443 listener. This is effectively TLS “pass through” mode, where the TLS connection does not terminate on the ELB, it is passed through and decrypted on the back-end servers. This will cause quite a bit of CPU overhead on the back-end instances, due to the lack of TLS offload that cannot happen on the ELB, so an auto-scaling group which monitors the web server CPU metrics would be essential here. (Not that you probably wouldn’t have it anyway, just saying!)
B. Don’t use an ELB. Just have the web servers act as the endpoint for the traffic, and let Route53 DNS serve in the place of the ELB by load balancing client DNS queries across the web servers.
C and D are not options here, since neither are supported by AWS.
Correct explanation.
Kirrim could you solve some questions for me private?
A and B are right answers, kirrim gave perfect explanation.
This quite a hectic question, I would go for A and B. Both are possible. C is wrong, because then you terminating your SSL on the ELB and not on the instances themselves. D i think is wrong because cloudfront doesnt support client authentication with client side SSL Certs.