3

We're having a problem where we can't access our site over HTTPS when using a valid certificate.

We have a domain, registered in Route53, and a certificate.

We have a load balancer:

our-production-elb-1234567.eu-west-2.elb.amazonaws.com

We have two target groups, with targets managed by ECS:

our-production-target-group-https
our-production-target-group-http

We have two listeners on the load balancer:

HTTP : 80, forwarding to our-production-target-group-http
HTTPS : 443, forwarding to our-production-target-group-https

We have a certificate applied to the https listener:

ouractualdomain.com
*.ouractualdomain.com

I have run logs on the actual instance, http requests get through fine whereas https requests don't show at all.

When I use the real certificate for the https listener, I get a 502 error. If I use a self-signed certificate it works fine with a security warning in chrome.

Does anyone have any ideas what could be happening?

Thanks!

userqwert
  • 145
  • 1
  • 5

2 Answers2

1

Cloud Front If the domain names don't match, the SSL/TLS handshake fails, and CloudFront returns an HTTP status code 502 (Bad Gateway) and sets the X-Cache header to Error from CloudFront.

To determine whether domain names in the certificate match the Origin Domain Name in the distribution or the Host header, you can use an online SSL checker or OpenSSL. If the domain names don't match, you have two options:

  1. Get a new SSL/TLS certificate that includes the applicable domain names.
  2. Change the distribution configuration so CloudFront no longer tries to use SSL to connect with your origin.

Load balancer HTTP 502 (bad gateway) errors can occur for one of the following reasons:

  1. The web server or associated backend application servers running on EC2 instances return a message that can't be parsed by your Classic Load Balancer.

  2. The web server or associated backend application servers return a 502 error message of their own.

To find the source of these 502 errors:

  1. Enable ELB access logs on your Classic Load Balancer to see the backend and Elastic Load Balancing (ELB) response code for each request. An access log entry contains two fields: an elb_status_code and a backend_status_code. Use these codes to determine the source of the 502 error.
  2. View the load balancer CloudWatch metrics to see backend-generated 502 errors, which appear under the HTTPCode_Backend_5XX metric. ELB-generated 502 errors appear under the HTTPCode_ELB_5XX metric.

If the backend response is the source of the ELB 502 error, the issue might be caused by:

  1. A response containing more than one CRLF between each header.
  2. A response containing a Content-Length header that contains a non-integer.
  3. A response has more bytes in the body than the Content-Length header value.
KayD
  • 126
  • 2
  • 1
    Ah sorry I should have mentioned in my post - I'm using an application load balancer. Does that make any difference to the possibilities? Am setting up logging on the ALB now. Thanks so much for your answer it is helpful. – userqwert Jul 15 '20 at 22:08
  • 1
    *"If the domain names don't match, you have two options."* "1" is not applicable, since you can't get a cert for an amazonaws.com hostname (the balancer) and "2" encourages unsafe behavior. The correct answer is that you can't use the balancer hostname as the Origin Domain Name in CloudFront configuration **unless** you whitelist the `Host` header in the Cache Distribution settings. With the `Host` header whitelisted, CloudFront expects/requires the origin to offer a certificate matching the `Host` header sent by the browser on the front side of CloudFront. – Michael - sqlbot Jul 16 '20 at 13:55
0

I couldn't get this to work at all, so I set the load balancer https listener to point at the http target group, over port 80. Then on my old application I set this meta tag in the header of my site to automatically upgrade any http requests to https.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
userqwert
  • 145
  • 1
  • 5