As I mentioned, the top failure of HTTPS is failing to use it, and that’s particularly common in in-bound links sent via email, in newsletters, and the like.
Unfortunately, there’s another common case, whereby the user simply types your bare domain name (
example.com) in the browser’s address bar without specifying
For decades, many server operators simply had a HTTP listener sitting at that bare domain, redirecting
https://www.example.com, changing from insecure HTTP to secure HTTPS and redirecting from the apex (base) domain to the
However, providing HTTPS support on your
www subdomain isn’t really enough, you must also support HTTPS on your apex domain. Unfortunately, several major domains, including
royalcaribbean.com do not have HTTPS support for the apex domain, only the
www subdomain. This shortcoming causes two problems:
- It means you cannot meet the submission requirements to HSTS-Preload your domain. HSTS preloading ensures that non-secure requests are never sent, protecting your site from a variety of attacks.
- Users who try to visit your bare domain over HTTPS will have a poor experience.
This second problem is only getting more common.
Browsers are working hard to shift all traffic over to HTTPS, adding new features to default to HTTPS for user-typed URLs (or optionally even all URLs). For some sites, like
https://delta.com, the attempt to navigate to HTTPS on the apex domain will very slowly time out:
…while for other sites on CDNs like Akamai (who do not seem to support HTTPS for free), the user gets a baffling and scary error message because the CDN returns a generic certificate that does not match the target site:
It’s frustrating to me that Akamai even offers a “shoot self in foot” option for their customers when their competitors like Cloudflare give HTTPS away, even to sites on their free tier who don’t pay them anything.
Ideally, sites and CDNs will correct their misconfigurations, helping keep users secure and avoiding confusing errors.
On the browser developer side, it’s kinda fun to brainstorm what the browser might do here, although I haven’t seen any great ideas yet. For example, as I noted back in 2017, the browser used to include a “magic” feature whereby if user went to
https://www.example.com but the cert only contained
example.com, the user would be silently redirected to
https://example.com to avoid a certificate error. You could imagine that the browser could introduce a similar feature here, or we could ship with a list of broken sites like Delta and Royal Caribbean and help the user recover from the site’s configuration error. Unfortunately, most of these approaches don’t meet a cost/benefit bar, so they remain unimplemented.
Please ensure that your apex domain loads properly over HTTPS!