I recently started serving the 'strict-transport-security' header on one of my websites. A problem I hadn't anticipated is that my SSL certificate only covers mydomain.com and so if a user visits www.mydomain.com, rather than being redirected (as would previously happen), they are seeing a security error presented by their browser due to the fact that the new header is disallowing all non-https communication.
For various reasons I'm using a multi-domain certificate so cannot simply buy a new cert with 'www' added to it.
I understand why this is expected behaviour however I'm wondering if there is anyway for me to redirect www to non-www despite www not having a valid certificate on the www domain?
If it makes any difference, my server is running Ubuntu.
As mentioned in the comments if you have includeSubDomains in your HSTS header then this will cause you problems as browsers who have this header will try to visit https://my.yourdomain.com (i.e. over HTTPS) which will give a cert error.
To be honest best practice is to include both mydomain.com and www.domain.com if any certificates and most CAs will include these two domains for the same price. This does not work for multi domain or wildcard certificates, but is still best practice so should be done where at all possible.
You could of course drop the includeSubDomains part of your HSTS header, as suggested in the comments, and this will solve the issue (once any cache responses as given by maxage time - which looks to be one year from your example) however there are other risks here. For example someone could set up wwww.mydomain.com (with 4 w's) or secure.mydomain.com or any other legitimate looking subdomain and serve it over http instead of https and visitors might not notice. Additionally subdomains may get access to, or be able to set, cookies for domains they are part of using the path attribute. These are edge cases and having HSTS even without includeSubDomains is still offering massive protection so still it's better to include this even without includeSubDomains, but if going to the effort of turning on HSTS then it would be better to be able to turn it on fully.
Anyway at the end of the day, no matter what the risks are, it's still advised to both 1) serve the www subdomains over HTTPS as some people or pieces of software will try this domain and avoids any issues - whether using HSTS or not, and 2) use HSTS, ideally with includeSubDomains where possible.