Once HSTS has been enabled on your server, it’s incredibly hard to disable it. HSTS is an essential part of SSL, making it difficult for an attacker to intercept traffic (AKA the MITM attack). Normally, the recommendation is to enable HSTS and forget about it.
But this is difficult if you’re running multiple subdomains, (for development, for example), and you don’t want an SSL certificate for each one, (as great and easy as Let’s Encrypt may be). Our scenario was the following:
- Multiple NodeJS sites running under NGinX and deployed with PM2
- Main site, (ridwanstudios.com) on SSL (Let’s Encrypt)
- Subdomains (a.ridwanstudios.com, b.ridwanstudios.com, etc) running without SSL
With HSTS enabled, our users were receiving a security warning on all subdomains. Depending on what browser they’re using, (Chrome, I’m looking at you), it would prevent them from accessing the subdomain in question.
With our particular requirements, we needed a way to keep SSL on main site strictly enforced, while keeping the subdomains non-SSL, because who wants to go through the trouble of generated a new certificate for each subdomain?
So how to get around this? After a lot of research, the only solution we could find was the to add the below line to the server block of the main website:
add_header Strict-Transport-Security "max-age=0; includeSubDomains" always;
This means that browsers will re-evaluate your HSTS at each server request, instead of keeping the HSTS policy cached. The end result is that it will prevent the common issue of your users getting a security warning when visiting one of your subdomains.
Of course, if your site is preloaded by Google as an HSTS site, it’s going to be a long and painful process to get it removed. If you need to get it removed, you can submit your site to the removal form here: https://hstspreload.org/removal/