How to debug a non working https setup that uses Amazon S3, route53, Cloudfront?

Question

I am setting up a static site with the following:

• content hosted on S3 (central Europe region)
• with a custom domain
• Cloudfront with https
• route53 for DNS setup
• redirect http to https
• redirect www to naked domain.

I have acquired a SSL certificate through Amazon.

Current status:

• the www to naked redirect works.
• http:// my-domain.com access works
• https:// my-domain.com does not work

Accessing through https simply timeout and the browser will tell that the site could not be reached.

I have followed multiple articles that all say the same thing. (I list some of them at the end)

But I can't find the issue.

The only odd thing I have seen is that in the screenshots of the Cloudfront distribution options of these articles, they all have a origin SSL protocols settings available. I don't have these.

So, not being an expert on this, how can I debug? following all these articles, there is no troubleshooting section.

Some of the articles: - https://www.lambrospetrou.com/articles/migrate-to-aws-static-website/ - https://simonecarletti.com/blog/2016/08/redirect-domain-https-amazon-cloudfront/ - https://simonecarletti.com/blog/2016/08/redirect-domain-http-https-www-cloudfront/

Answer 1

You unfortunately do not provide the name involved so people can not really troubleshoot things except by throwing guesses.

Here is my generic (not exhaustive and not all possible corner cases) quick but logical list of steps to execute in order to check for timeouts, and you should complete, in that order, each step successfully before going to the next one:

1. "The obvious": never forget to have a look at your webserver logfiles and make sure there are no errors in it. Pay attention to them while you are at step 5. and later below. Also make sure to do your tests from other points too, as you may see a problem when others accessing the server could see everything ok (if you did provide the URL you would already have this information for free here from people trying to help)
2. "domain level": is the domain name correctly configured DNS wise? You can try online tools such as DNSviz or Zonemaster. Pay attention in whois that your domain is not in some kind of clientHoldstatus that would forbid its correct resolution. Make also sure that you do not have DNSSEC related errors. These two last points should appear if you use the previous online diagnostic tools
3. "IP level": what IP address do you get when you query the hostname involved in your URL? You should use a tool like dig and first check the authoritative nameservers of your domain, then some cache ones (yours, 8.8.8.8, 9.9.9.9). Do you get the IP you are supposed to get? Take care of IPv4 and IPv6, and use both in later steps.
4. "TCP level": use a tool like tcptraceroute with the IP found at previous step, and towards port 80 for http queries or 443 for https (or any other port specified in the URL). Do the trace complete without errors (no * or !Xor stuff like that at the last line)? Do not use traceroute nor pingfor this stuff as the results will not be relevant, you really need to test the TCP level
5. "TLS level" (only for https:// URLs of course): try to connect with openssl s_client or equivalent (do not forget about SNI, so for openssl you need to add flag -servername with the proper hostname) to see if you get back at least the beginning of the TLS handshake and hopefully up to the server certificate. Make sure it is the correct certificate. You can also try with other command line tools with proper switches to get more debug data, like HEAD (from Perl libwww module) or wget or curl. Have a look at OCSP stuff inside the certificate.
6. "Application level": if you get back nothing at all, or just HTTP headers you may have a problem with the web application, you will need to check your server logfiles. Start to investigate them more closely (and try to increase logging). Keep using low levels tools like wget/curl to eliminate browsers complex behaviors.

If all this fails, you will need to go below and start running network sniffers, both in front of your webserver to see what it receives, and after your own client, to see what you send. But this could be another post just by itself, and is not necessary if you did not already remove all previous steps.

Also, since you are using commercial entities to handle your infrastructure, you may try asking them as I am sure you are also paying for some kind of support, and they should have troubleshooting tools and skills to help you for your specific case.