Warning: Unnecessary HSTS header over HTTP
I solved the error in my litespeed based server by this method. Also works for apache. First add this code into your htaccess-
# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Then add this code-
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" env=HTTPS
</IfModule>
Try removing the always
attribute. So do this:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
Instead of this:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
The other option is to only set this in the HTTPS VirtualHost's rather than in the main top level config:
Do this:
<VirtualHost *:443>
(All other virtual host config)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>
Instead of this:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
<VirtualHost *:443>
(All other virtual host config)
</VirtualHost>
This has the disadvantage (or advantage depending how you look at it!) of having to be added to each VirtualHost to take effect, whereas the first option would automatically be applied to all HTTPS virtual hosts.
And please, please, please be very careful with preload. It is not easily reversible! I would strongly recommend you run for a few months with good (i.e. error-free) config - which it appears you have not been doing - before submitting to preload list.
To give one example where preload can cause you problems: Supposing you run https://www.example.com, and this also responds to http://example.com and redirects you to https://example.com and then https://www.example.com (as the preload submissions require and as your config is set up to do). Then your website is lovely and secure. However, for companies that reuse their domain internally (which is quite common) this can cause problems - especially when you preload. For example, if you run a non-secure site which is not publicly available at http://intranet.example.com, or perhaps a non-secure development version of your site at http://dev.example.com, then you may not realise that this site must now also be served over HTTPS (as it is a subdomain of example.com). This rarely takes effect (as most people don't visit http://example.com or https://example.com so never see this HSTS header on top level domain) so you might never notice this potential problem during all your testing. However as soon as the preload takes effect, your browser will then know about the HSTS at top level domain even without visiting that and you instantly lose access to those HTTP-only sites, and cannot easily reverse this! Lots of companies still have lots of internal sites and tools served over HTTP only and upgrading them all to HTTPS (which should be done anyway btw!) at short notice would not be easy.
To get around this, either use a different domain internally, or you can only set this without includeSubDomain on the top level domain:
<VirtualHost *:443>
ServerName example.com
(All other virtual host config)
#Set HSTS at top level without includeSubDomain
Header always set Strict-Transport-Security "max-age=31536000"
</VirtualHost>
<VirtualHost *:443>
ServerName www.example.com
(All other virtual host config)
#Set HSTS at subdomain level
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>
This is not quite as secure (as someone can set up other subdomains over HTTP like http://wwww.example.com (note the four Ws) or http://fake.subdomain.com) but at least it doesn't break those HTTP-only sites. This setup will not be allowed through the preload list as it demands the more secure includeSubDomains even on the top level domain.
If you do want to use includeSubDomains even on the top level domain then I strongly recommend including a resource from the top level domain in your HTML (even if it redirects to the www version as HSTS is still set for 301s/302s). This way you are making sure visitors load the HSTS config at top level even before you preload. For example you could replace your logo to a call to the top level domain instead:
<img source="https://example.com/logo.png">
Run with that, and a small expiry, and no preload tag for a bit. Then increase the expiry. Then, if that all works, add the preload tag back and submit to the preload list.
This might all sound a bit painful, and perhaps you've thought of all this, but preloading can be incredibly dangerous if not thought through, due to the fact it is not easily reversible. In my opinion preloading HSTS is overkill for most sites though I agree it is the most secure option.