I've created a new subdomain for staging on aws. On the browser I can not get to https://staging.mysite.co. I can get to http://staging.mysite.co but none of the assets are served (as its all served via https). My regular production app works fine via HTTPs on the same load balancer and via route 53
Here's how things are set up;
- DNS is via Route 53.
- I have a single load balancer managing production at mysite.co and staging at staging.mysite.com.
- There are two elastic beanstalk environments (one for staging, one for production), each with the same security groups and their own target group.
More details ROUTE 53
- There are three A records; mysite.co, www.mysite.co (both routed to production EB environemnt) and staging.mysite.co (routed to staging EB environment)
- I already had one certificate from Amazon Certificate Manager for mysite.co and www.mysite.co
- I created a new certificate for *.mysite.co
Load Balancer
- There are two listeners on the load balancer, one for port 80/Http and one for port 443/HTTPS
- The port 443 listener has two rules; -- one that looks for HTTP Host Header is staging.mysite.co and routes it to the staging target group. -- the default rule (applied last) that routes everything to production target group
- The default certificate for the listener is the mysite.co / www.mysite.co one. The listener also has a listener certificate for SNI which is the new staging.mysite.co one.
Here's what I've tried
- dig https://mysite.co / www.mysite.co / staging.mysite.co. Im not sure what I can deduce from these but they all looked very close to identical. Example below with some data redacted
; <<>> DiG 9.10.6 <<>> https://www.-------.co
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13597
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;https://www.------.co. IN A
;; AUTHORITY SECTION:
------.co. 900 IN SOA ns-1960.awsdns-53.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 50 msec
;; SERVER: 192.168.86.1#53(192.168.86.1)
;; WHEN: Thu Dec 14 16:57:17 PST 2023
;; MSG SIZE rcvd: 135
Did a test on sslabs. Response in image below SSLLAbs screenshot
Set up an S3 bucket to capture the load balancer logs. Again, I'm not really sure what to look for here but here's a snippet showing an unmappedconnectionerror which i think is relevant.
2023-12-15T01:16:16.711764Z 98.210.29.111 54026 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.103 "-" - - Success
2023-12-15T01:19:33.796535Z 66.160.133.230 43039 443 TLSv1.1 ECDHE-RSA-AES128-SHA - "-" - - Failed:UnmappedConnectionError
Could it be any of these issues?
- The load balancer 443 listener isnt able to use the correct certificate? I know it works for the production environment (using the default mysite.co certificate) but maybe its not using the *.mysite.co certificate for the staging.mysite.co environment.
- There's a conflict between the certificates? *.mysite.co and mysite.co/www.mysite.co?
Let me know if I can provide more info!
EDIT
- This video suggests that if the load balancer sees that a target group is unhealthy (fails a heartbeat test) then the target group will be ignored. Both target groups were unhealthy so i fixed the hearbeat. Both are now healthy but I still cant get to
https://staging.mysite.co
I seem to have found the answer (and learnt a lot along the way!)
The Route 53 A records were not pointing to the load balancer, rather they were pointing directly to the elastic beanstalk environment. In other words, the load balancer wasn't being used and presumably the https certificate wasnt getting associated to the request.
Once I changed the staging A record to point to the load balancer I was able to get to
https://staging.mysite.co