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.

CodePudding user response：

...and the HSTS rules makes Chrome block the redirect completely with a NET::ERR_CERT_COMMON_NAME_INVALID error

That's nothing to do with HSTS. That error is "because there is no valid certificate on a *.*.domain.com level". You would have had the same error before trying to implement HSTS. (Unless you only ever tested the www sub-subdomain over HTTP only?!)

There is no shortcut. If you need the www sub-subdomain to be accessible over HTTPS then you need a valid security cert that covers that hostname.

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

The NET::ERR_CERT_COMMON_NAME_INVALID is a browser error that occurs during the SSL handshake. This all happens before .htaccess is even processed (before any data is transmitted).

Aside: Although do you really need a www sub-subdomain?

CodePudding user response：

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).