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.
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
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.
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.