Search code examples
apache.htaccesshttp-redirectsubdomainhsts

htaccess HSTS prevents redirection from www.subdomain.domain.com to subdomain.domain.com


I have a website where the user can make unlimited subdomains for that website.
One of our customers wants us to have HSTS enabled on the header so I added the following rule to my .htaccess:

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains"

We have a wildcard certificate *.domain.com to secure all the subdomains, because we don't want to make for every subdomain a seperate certificate.

The problem is when someone is going to www.subdomain.domain.com they need to be redirected to subdomain.domain.com.
But Chrome is blocking the redirect because there is no valid certificate on a *.*.domain.com level and the HSTS rules makes Chrome block the redirect completely with a NET::ERR_CERT_COMMON_NAME_INVALID error.

Part of the .htaccess that matters:

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [R=301,QSA,NC,L]

RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,QSA,R=301,L]

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set Cache-Control "no-store, no-cache, must-revalidate"

I was expecting that the www to non-www redirect would go first because it is higher in the .htaccess file.


Solution

  • If you don't want to enable HSTS on the www sub-subdomain, you need to put an <If> statement around the header and not use includeSubDomains in your HSTS rule.

    Without <If "%{HTTP_HOST} != 'www.sub.example.com'> around the Header directive for HSTS, that header will be sent for that subdomain, regardless of the order of the rules in your .htaccess file.

    When you use includeSubDomains in your HSTS rule, HSTS for www.sub.example.com will be enabled when you visit sub.example.com or even example.com.

    Now that you have enabled HSTS for that www subdomain, there is no way for you to revoke it for browsers that have already visited your site. At this point, your best course of action is to get a certificate that covers the www subdomain. You can probably add at to your existing certificate as a Subject Alternative Name (SAN).