# HSTS preloading **URL:** \ **Category:** Server\ **Created:** [December 30, 2018, 7:14pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241 "2018-12-30T19:14:59Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [December 30, 2018, 6:45pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/1 "2018-12-30T18:45:09Z")
> [@Nextcloudpi automatic certificate renewal failed](https://community.letsencrypt.org/t/nextcloudpi-automatic-certificate-renewal-failed/81227/12): > > [hopto.org](http://hopto.org) is a public suffix, so if you send preload, another user may add your site to the Google preload list. Note: This doesn't have to do with being a public suffix or not. Any site that sends the `preload` flag on an HSTS header may be added to the Google or Mozilla preload list at any time by any person. > [@](#): > > did you add a firewall? An open port 80 is required, as @Osiris wrote. But your site doesn’t answer connecting port 80. Ah, this might be due to the latest version of Certbot using the `http-01` challenge. It's possible that this domain name never accepted port 80 requests, but that wasn't previously an issue because Certbot would use the `tls-sni-01` challenge on port 443. That might explain why nextcloudpi failed to renew recently, if it was updating its Certbot install. @verduron, can you tell us more about what nextcloudpi uses under the hood? And when you regain access, can you share some logs of the latest renewal attempt? ---
**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\ **Post date:** [December 30, 2018, 7:14pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/2 "2018-12-30T19:14:59Z")
> [@Nextcloudpi automatic certificate renewal failed](https://community.letsencrypt.org/t/nextcloudpi-automatic-certificate-renewal-failed/81227/13): > > Any site that sends the `preload` flag on an HSTS header may be added to the Google or Mozilla preload list at any time by any person. Really? Try it: [https://hstspreload.org/?domain=community.letsencrypt.org](https://hstspreload.org/?domain=community.letsencrypt.org) > Error: Subdomain `community.letsencrypt.org` is a subdomain. Please preload `letsencrypt.org` instead. (Due to the size of the preload list and the behaviour of cookies across subdomains, we only accept automated preload list submissions of whole registered domains.) ---
**Author:** ![stevenzhu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/stevenzhu/32/18864_2.png) [@stevenzhu](https://community.letsencrypt.org/u/stevenzhu)\ **Post date:** [December 30, 2018, 8:46pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/3 "2018-12-30T20:46:04Z")
> [@JuergenAuer](#): > > Error: Subdomain `community.letsencrypt.org` is a subdomain. Please preload `letsencrypt.org` instead. (Due to the size of the preload list and the behaviour of cookies across subdomains, we only accept automated preload list submissions of whole registered domains.) That means you could only submit the domain itself to preload list... (Which always would include its subdomain or any other nested subdomains) ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [December 30, 2018, 8:48pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/4 "2018-12-30T20:48:30Z")
> [@JuergenAuer](#): > > Error: Subdomain `community.letsencrypt.org` is a subdomain. Please preload `letsencrypt.org` instead I think this is a separate issue. To summarize: - Only registered domains (i.e. effective TLS plus one label) may be added to the preload list. - If such a domain sends the `preload` parameter, it can be added to the preload list by any person, regardless of PSL status. But maybe what you are saying is that for subdomains of registered domains (`www.example.com`), they cannot be added to the preload list even if they send the `preload` parameter? ---
**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\ **Post date:** [December 30, 2018, 8:55pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/5 "2018-12-30T20:55:39Z")
It's the context of the question. Seeing `thibmus.hopto.org` my first idea: "Oh, it's a subdomain, so sending "preload" isn't a security problem. Then I checked the domain - "oh, [hopto.org](http://hopto.org) is a public suffix, so `thibmus.hopto.org` is a domain, not a subdomain". Then comes the problem: > [@jsha](#): > > If such a domain sends the `preload` parameter, it can be added to the preload list by any person, regardless of PSL status. Now I see this sometimes: Domains, starting with certificates. But there are some errors, certificate renew doesn't work. But HSTS is set with the preload directive. HSTS + preload is a wonderful feature. But certificate renewing should work. If not, a preloaded domain is a problem. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [December 30, 2018, 9:09pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/6 "2018-12-30T21:09:25Z")
I think we are in agreement there. A lot of beginning advice suggests enabling HSTS, but it’s usually too big a risk unless you have experience operating an HTTPS website for a good amount of time. ---
**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\ **Post date:** [December 30, 2018, 9:28pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/7 "2018-12-30T21:28:49Z")
> [@jsha](#): > > A lot of beginning advice suggests enabling HSTS, but it’s usually too big a risk unless you have experience operating an HTTPS website for a good amount of time. Yep, this is the point! Thanks. If someone starts new, he shouldn't add HSTS or preload. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [December 30, 2018, 9:31pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/8 "2018-12-30T21:31:43Z")
It also goes bad when people copy and paste `includeSubdomains` without knowing what it means. 😬 ---
**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\ **Post date:** [January 29, 2019, 9:31pm UTC](https://community.letsencrypt.org/t/hsts-preloading/81241/9 "2019-01-29T21:31:45Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.