After finally passing on various web site creation tools I figured I would do the simple thing: post a static web site.
AWS allows you to use an S3 storage bucket as a static web site. Sweet! What could be simpler? I have a tool that allows me to map an S3 bucket into a Windows folder, so all I would have to do is update the folder to publish changes. Even better, you can put Cloudfront in front of it which ensures HTTPS as well as HTTP requests are handled.
Sounds good ... but
- The instructions (at least at that time) left out the key fact that your bucket has to have the same name as your domain.
- My file uploader wasn't setting the metadata correctly. That was fixable.
- It's a bit confusing to pick the right kind of certificate for HTTPS (wildcard or root only).
- "index.html" is only returned by default for the root bucket; so, for instance, https://www.above-the-garage.com/piano doesn't work - you have to specify https://www.above-the-garage.com/piano/index.html ; this broke some existing links out in the wild.
- DNS
Now let's see if I can explain this.
In the beginning, web sites tended to have "www." in front, like this:
"www." specified the protocol - world wide web. You could have file transfer ("ftp.") or actually any prefix you wanted.
Unfortunately, one of those doesn't work! It's #2. And the reason is the certificate doesn't match.
And it turns out it can't match.
Here is an email from April 2019 from
Pair Domains, my DNS provider, that explains things:
We are contacting you because there is a problem with DNS records for your
There is currently a CNAME record for @. DNS rules prohibit other records
from sharing the same host name with a CNAME record. With a record for @,
this means that MX records would not work and there could be e-mail
delivery problems for the domain.
We recently changed our DNS software, and the new software is more strict
about DNS rules. Before, CNAME records and MX records could coexist, but
not everyone would be able to actually deliver the e-mail. The new
software does not allow this, so if there is a CNAME for @, e-mail won't
work on the domain.
Well, I also use above-the-garage.com for email, and I want that to work, so I had to drop the CNAME which allowed www.above-the-garage.com to point to above-the-garage.com; and my cert was for above-the-garage.com (without the www.).
So what to do ... change DNS providers? No, it looks like they are implementing the standard. Aha! Make the cert for the www version; and redirect any hits to the homepage to the https://www.above-the-garage.com name; the cert matches, and everything is great. Except, sadly, case #2 above, where browsers see the https: label, and really want the cert to match the exact domain name. It doesn't, so the redirect doesn't happen, and people get an error after it times out. In general, this is probably not a big deal; but in the long run, people and browsers might enforce going to https://above-the-garage.com . Maybe I can put a second cert on there and all is well.
The most important thing is what happens when you just type in "above-the-garage.com" to your browser address bar: works in Chrome and Edge!
So, static web site mostly works. w00t.
[Update 2024-05-06] What could go wrong with a static web site served out of an S3 bucket?
Answer:
Oh, and since the bucket name had to match the web site name ... my bucket name was effectively public.
So rather than worry about that potential nightmare (AWS says they are working on a fix - that's good) I quickly copied everything out of the bucket into a small AWS Graviton instance and fired up nginx. One and a half hours later I was moved over. I still have the same DNS problem. Ugh!]
[Update 2024-05-07 DNS issue fixed! Did I really need CloudFront in front of my never visited web site? NO! Dropping CloudFront from the mix removed all the CNAME records and I can use A records and MX records together. w00t!]
