I would appreciate immensely if you shed some light into what we might be missing or doing wrong. I am not completely in charge of the configuration, and I'm not an expert on the subject, but have been working with our systems team trying to resolve this issue to no avail:

  1. We have two sites, main.my-company.com and admin.my-company.com both of which we need to serve over HTTPS and be load-balanced.

  2. Each site has its own load-balancer, LB-Main and LB-Admin. Each of these load-balancers is already configured with our wildcard SSL certificate *.my-company.com on port :443

  3. Both sites need to be deployed to the same pair of servers. This is a business constraint.

  4. Our DNS is configured so that main.my-company.com points to LB-Main and admin.my-company.com points to LB-Admin

  5. LB-Main forwards traffic through https://main.my-company.com:443/ to port :4443 on the VMs. Our Main site on is configured on IIS with bindings {http:*:4443:} on each server.

  6. LB-Admin forwards traffic through https://admin.my-company.com:443/ to port :4444 on the VMs. Our Admin site on is configured on IIS with bindings {http:*:4444:} on each server.

  7. All ports are appropriately open on the servers. (:4443, :4444 and even :443 and :80, which are not used.)

  8. All health-check endpoints used by ELB return HTTP/1.x 200 OK

Our problem is that when actually trying https://main.my-company.com/ or https://main.my-company.com:443/ the request times out.

It's as if our dual SSL configuration for both load-balancers conflicts with one another, because when only one of the hosts uses SSL, the other works fine on port :80

What might we be missing or doing wrong?

  • when only one of the hosts uses SSL, the other works fine on port 80 I'm a little unclear on what this means. Connecting multiple ELBs to the same instance or instances is a valid configuration, though. I have one set of instances with 15 different ELBs attached to all of them. The ELB logs and the instance web server logs, and netstat, would be the places to look, as well as hitting the instances directly, using openssl s_client -connect .... – Michael - sqlbot May 20 '16 at 12:21
  • Do your EC2 instances' Security Groups allow connections from your ELBs to those 4443/4444 ports? Are there any on-instance firewalls that might be blocking connections from the ELBs to the 4443/4444 ports? Are your ELBs configured with HTTPS listeners on port 443 on the frontend? – Castaglia May 20 '16 at 23:35
  • Thanks for your responses guys. I'll answer in order: @Michael-sqlbot - basically what I mean is that if LB-Main receives traffic on :80 and forwards to :80 and LB-Admin receives traffic on :443 and forwards to :443 then everything is fine. It's our attempt to connect 2 ELBs to the instances over HTTPS at which we are not being successful. – Fernando Espinosa May 21 '16 at 1:46
  • 1
    I think both my suggestions and those of @Castaglia still stand. Verify that the security group of the instances allows access to those ports from the ELB. Verify that the instances are responding to direct requests on those ports using openssl s_client or curl from another machine. There's nothing intrinsically flawed or unsupported with what you are trying to do. – Michael - sqlbot May 21 '16 at 2:02
  • @Castaglia - Our SysAdmin was well aware of the security groups and there is no problem reaching the instances from the ELBs. As I said, we can see the health-check endpoints being successfully reached on the corresponding ports :4443 and :4444... And yeah, both our ELBs do listen to :443. – Fernando Espinosa May 21 '16 at 2:11

Your Answer

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

Browse other questions tagged or ask your own question.