We are using AWS Elastic Beanstalk with Application type Load Balancer to deploy a .NET applications.

In the beginning we had a wildcard cert that we used on the load balancer level. The actual EC instance and the IIS on there did not handle TLS traffic since the load balancer stripped connection down to non-TLS. Everything was fine. However, later we needed to install an SSO (service provider) tool on the instance and this tool requires TLS. We ended up, in addition to the cert on the load balancer creating a Lets Encrypt cert on the EC instance level.

What ended up happening after this, is AWS keeps flagging all our instances as having health of Red because load balancer keeps trying to request http://localhost:443 (or http://IP:443) and these are not coming back.

I tried using a self signed cert bound to localhost on the EC instance, but this did not work because (i think) LB has to trust this cert before it will receive a 200 back.

How to handle a situation like this?


You need to configure your Health Check to use the HTTPS protocol. When viewing your Target Groups (i.e. for us-east-1, browse to this URL, or modify it for your region: https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#TargetGroups:sort=targetGroupName), select the intended Target Group and choose Actions > Edit health check. For the Health Check, set the Protocol to HTTPS and then click Save.

enter image description here

Since your ELB is listening on 443, you can leave the Port option set to traffic port.

This should deliver the health check requests to https://ip.of.your.ec2:443.

UPDATE 1: After posing further questions in the comments, I did more digging into this setup. Here are my findings.

If the backend target and the ALB node is in the same VPC then at the wire level, all customer packets are wrapped within a proprietary VPC encapsulation protocol. This encapsulation protocol identifies various SDN parameters, including the source and destination Elastic Network Interfaces. These parameters are authenticated in both directions, on both the sender and the receiver side, for every packet. Additionally the meta-data for the parameters is securely provided by the internal EC2 control planes as part of launching instances, and integrated directly in secure hardware. This overall design is to ensure that there is no risk of unauthorized packets being sent or received within the VPC network, and that there is no risk of packets being intercepted by intermediaries.

Reference: https://forums.aws.amazon.com/thread.jspa?threadID=263914

The above reference then has a link to this official AWS documentation for adding back-end instance authentication to a Classic Load Balancer. However, neither the CLI or API documentation mention this only works for Classic Load Balancer. Thus, I would assume this will work for an Application Load Balancer.

Going back to the quote from above, it would seem that manually specifying the certificate to use via create-load-balancer-policy should not be required, unless you're ALB and EC2 targets are not in the same VPC.

So, you can try adding a Load Balancer policy with your Lets Encrypt certificate.

But wait, there's more! I question why you had to make the actual servers serve content over HTTPS in order to implement your SSO SP. Is it performing SSO between two applications running on the same server? Or is simply allowing your application to be a SP to your external IdP? If the latter, are all of your EC2 instances configured as if they are the same SP, or do they have their own unique config? If unique, how are you delivering the response to the correct target? Due to this limitation, I have to assume they're all configured the same. So, why then is the TLS connection established with your ALB not sufficient? Are you using the Lets Encrypt certificate to encrypt a SAML Assertion, and also using that same certificate to serve HTTPS traffic directly from your instance? If so, then I believe that can be rebuilt to not need HTTPS configured on the instances. The assertion would be encrypted on the server, using your configured certificate, prior to sending the data back to the end user. The IdP would need to know the public key for that certificate so that it could decrypt the assertion and verify it came from a valid source. None of that setup would require the actual EC2 to be listening on 443.

  • It looks like I have 2 targets, one for 80 and one for 443. The 443 target group has health check using HTTPS. AWS support mentioned that the load balancer calls https: //localhost:443 or https: //local_IP on my instance, however since its 443 they cannot get to it, correct? I have a cert for that instance and if load balancer used the proper domain name it would work, but I dont think you can setup the load balancer to call health check using proper URL. – User20909 Dec 27 '19 at 21:40
  • Maybe I am missing something, but you cannot just access https:// ip.of.your.ec2:443 without any certs, you still need a cert registered for your IP, correct? – User20909 Dec 30 '19 at 14:10
  • Have you verified that your Protocol is set to HTTPS and not TCP? In hindsight, my original answer is a bit incorrect. While the ELB would deliver the health check to https://ip.of.your.ec2:443, I suspect the connection may be rejected because you cannot serve a valid cert to an IP address; it must have a domain. So, I did some digging about this. Please see my updated answer. – Aaron St. Clair Dec 31 '19 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.