Redirect www to non-www and SSL with HSTS

Hi all,

we are using many differnet types of SSL certificates without any issues, but I am running into the following problems with SAN/Multi-domain SSL certificates:

One of our clients just reported, that some of their customers complain about certificate errors on their websites. We installed a Comodo UCC/SAN/Multi-Domain SSL certificate for 4 sites, but when visitors enters instead of they get ERR_CERT_COMMON_NAME_INVALID or SSL_ERROR_BAD_CERT_DOMAIN (due to HSTS).

Commodo tells me that SAN/Multi-domain ssl certificate will secure exact match domain names only. This product will consider and as 2 separate domain names. And they recomend to purchase additional SAN licenses and reissue ssl certificate to add the www domain names.

Is there no better solution to this? 99% of website visitors will never type https:// but stil very many will type www. in front of every single URL - which is so 90ies :wink:

So wouldn’t it be possible to redirect www to non-www and then redirect from http to https afterwards somehow?


Hi Michael

I hope alls well

Hmmm strange as I thought most CA covered both as either could be used

A couple of quick thoughts though

Could the sites not use let’s encrypt and set ssl on all needed

If not, then you could put redirect rule in htaccess, which would redirect to https://domain.url from www and http

I hope that helps a little

Many thanks


Hi Michael

Actually the rewrite rule maybe better on vhost file for the siteworx domain needing it.

May work better and be cleaner then htaccess, as client may have access to htaccess file

Many thanks


Hi John,

these specific sites are ServerAliases and thus need a SAN/Multi-domain ssl certificate, so no other cert would help. The redirection is exactly what I was asking and naturally we do that in the vhost file.

HAHA, EDIT: The good thing about writing publicly on a forum and answering somebody else’s questions/suggestions, is that you have to verify everything you write in order not to look stupid. And doing so sometimes shows you your own errors better than anybody else could :wink:

I knew we have both redirects in the vhost file, http->https as well as www->non-www. But I placed the http->https way to high so that it was done first and then the www->non-www. I corrected that and now it works :wink:

John, thanks for listening and suggesting and putting me on the right path - again :smiley:


Hmm, too happy too soon. Seemed to work yesterday evening but today I get the same certificate error. If somebody wants to have a look:
As far as I can tell from reading many sources on the web there is no way around this problem, so the customer needs 4 more SANs.

Hi Michael
Sorry to hear that, so a quick thought which you may want to try
First, backup your vhost and then remove the rewrite rules you had to www and https
Edit redirects.conf from etc/httpd/conf.d (or create redirects.conf if it does not exist)
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?your-domain.alias$
RewriteRule ^(.*)$ https://your-domain.proper$1 [R=301] [L]
restart apache
Please change your-domain.alias to your server alias domain and your-domain.proper to your domain
I hope that helps a little
Many thanks

Hi Michael
I came accross this so hopefully help you, but sorry if you have alread seen it
Many thanks


HSTS (HTTP Strict Transport Security) is a web security measure that forces all communication between a web server (a specific domain) and a conforming client (e.g. a browser) to be sent over secure HTTPS connections.
This is achieved with the use of a response header field named Strict-Transport-Security:

Strict-Transport-Security: max-age=31536000

The above header tells the client (the web browser) that all subsequent communication for the next 31536000 seconds (~1 year) should happen over HTTPS. The next time you try to visit the site through HTTP (e.g. http://, your browser will automatically redirect you to the HTTPS version (e.g. https:// before your request even hits the web server. All links and references to http:// will be translated at the client side to https://
According to the RFC, the Strict-Transport-Security header must only be sent with secure HTTPS responses:

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.
This means that responses from http:// should not include the header.
At the time of writing HSTS is supported by all real browsers (IE 11 added support in an update in June 2015).
Redirecting HTTP to HTTPS at the server side
A common practice is to configure the web server to redirect http:// to https:// Then, as soon as your browser retrieves a response from https://, the HSTS header is sent and all subsequent references and requests to http:// are translated at the client side to https://
However, the initial redirect is still insecure as https:// has not yet sent the HSTS header. In order to circumvent the insecure redirect you can add your domain to the HSTS preload list maintained by Google. This is a list of HTTPS-only sites, and it’s hardcoded into Google Chrome and other major browsers. Browsers are instructed to go straight to the HTTPS-version of the sites listed, and translate all references to the sites to HTTPS.
Canonical redirects (www to non-www or vice versa)
Many web servers are configured to redirect traffic to a canonical URL, e.g. from to or vice versa.
It’s important to note that the HSTS policy only applies for the host (domain) that sends the Strict-Transport-Security header. If https:// sends the header, the policy applies only to, not to Thus access to will not result in a secure redirect to HTTPS; it will merely hit the server side redirect, if configured, which is not secure.
That is, https:// and https:// do not set HSTS for each other.
Let’s look at a scenario where the web server has been configured to redirect all non-canonical and non-HTTPS traffic to the canonical HTTPS URL https:// The redirect rules are as follows:
•http:// → https://
•http:// → https://
•https:// → https://
In this scenario only https:// has been configued to send the Strict-Transport-Security header.
What will happen?
1.http:// responds with a 301 redirect to https:// which sets the HSTS headers. The HSTS policy will apply only to
2.All subsequent requests or links to http:// will be translated to https://
3.Requests to http:// will not be translated to https:// because doesn’t have a HSTS policy. The server will respond with an insecure 301 redirect to https:// every time.
How do we mitigate this?
We should redirect HTTP requests to their HTTPS equivalent before any canonicalization steps (adding or removing “www”), and send the HSTS header from any domain or subdomain that is meant to be only accessible over HTTPS:
The server side redirect scheme becomes:
•http:// → https://*
•http:// → https://* → https://*
•https:// → https://*
The asterisk (*) denotes which hosts sends the HSTS header.
Now we’ve secured both the users who access your site through and those who access your site through; both domains have the HSTS policy applied.
But we haven’t secured the users who first access http://, and later access http://; the redirect from http:// to https:// is insecure because the HSTS policy has not yet been set for for these users.
To set the HSTS policy for both domains we can use the includeSubDomains token in the HSTS header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

includeSubDomains specifies that this HSTS policy also applies to any subdomain of the HSTS issuing host’s domain, i.e. the domain and all of its subdomains. However, it may not be desirable to use HSTS on all subdomains, especially if some subdomains are supposed to be accessible with plain HTTP. There are other implications as well, some of which are described in the RFC.
In addition, if your canonical URL is, the includeSubDomains token will not protect as this is not a subdomain of A solution is to make a request from to an uncached resource on https://, e.g. a 1px image, and make sure that https:// sets the HSTS header. Thus both and would have an HSTS policy in effect.
Testing HSTS policy
If you’re running Google Chrome, visit chrome://net-internals/#hsts to review the HSTS policy of different domains.