Could the Let’s Encrypt client enable HSTS by default? It seems like it could be another option in the process.
Hi, even if this is an good feature i think the client should only take care about certificates.
And should not change server configuration without question.
And another point is the client is an security part so i like such parts as simple as possible
this make it more easy to check for malicious code.
This sounds like a really bad idea that risks locking people out of the website if something is misconfigured. Better to do HSTS manually after testing things.
indeed HSTS should be something folks decide for themselves
If it’s a matter of testing the SSL setup, couldn’t the client do that in some way?
SSL without HSTS is…incomplete. It seems like if the client is going to go as far as helping redirect HTTP to HTTPS (if the user chooses to go that route) that it should also offer to add the HSTS header (again, if the user chooses to have it do that).
You could even keep the max-age low initially to further reduce the risk of prolonged issues and prompt the developer to up the age after they’ve had a look. Some HSTS seems better than no HSTS.
Am I oversimplifying? I’m far from an expert on this, so it’s entirely possible I may be missing some complexity in the testing here that makes this too complicated for automation.
If I am missing something, could there be some other feature to help prompt the developer to setup HSTS (a reminder? a note at the end of the process?)? It seems like this fits under the “Secure” principle of Let’s Encrypt:
Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
Well most common issue i see is folks enabling https and HSTS and then realising some part of their web app script and/or their advertisers do not support https and break their site or see dramatic drop in advertising revenues. Then they want to go back to non-https but are stuck in HSTS redirect cycle for max-age time. Clear browsers’s cache for HSTS for one self is easy, trying to explain it to a mass of site visitors who maybe technically illiterate is another.
We have an example in our community just now: Lost formatting after cert issued/installed (solved)
No offence to the user of the topic above, but HSTS would only aggrevate such server and web app configuration problems.
You can enable HSTS with the
--hsts flag to the client. The client won’t add it by default because, as others have pointed out on this thread, there is a risk of breaking your website.
Oh—this is perfect! I never wanted HSTS to just happen without any say from the user, but rather to have it exposed as an option (re-reading my original post, it’s easy to see where I failed to make that clear—sorry). I didn’t see this in the documentation and it’s also not exposed in the GUI, so I didn’t think it existed.
I enabled HSTS on my domain and now every subdomain is redirecting to HTTPS and gives an error. I removed HSTS config but still see this on chrome. is there some sort of cache that remembers HSTS?
Yes, HSTS is cached for the duration of the ‘max-age’ directive, which is measured in seconds. The browser will cache and apply the policy for this length of time even if the header is removed. It will also apply to all of your sub domains if the ‘IncludeSubDomains’ directive is present in the policy.
Browsers remember your setting according to the duration you’ve put in the header yourself.
You can put in a duration of zero to remove any cache as far as I know, but of course, clients will have to surf to the site to get this new duration…
It might also be worth adding that you can only deliver the header over HTTPS and browsers will ignore it if it is delivered over HTTP.
The client-side caching of HSTS records is the whole point of the exercise. There is literally no other point to it.
Please people, know what you’re doing.
Hi this is not exactly true. It is always possible to add any head to the response.
But the browser only recognize and process the hsts header if it is delivered via
https page. Maybe it is an good idea that the client will print an explanation what
the hsts flag does and that it is not possible the revert the effect by simple remove
the setting from the server after the client had contact with the server.