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 www.site.de instead of site.de 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 www.domain.com and domain.com 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?

Cheers,
Michael

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

John

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

John

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:

Cheers,
Michael

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: http://www.o2bln.de/
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
test
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
John

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

#ssl/tls

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:

1
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:// example.com), your browser will automatically redirect you to the HTTPS version (e.g. https:// example.com) before your request even hits the web server. All links and references to http:// example.com will be translated at the client side to https:// example.com.
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:// example.com 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:// example.com to https:// example.com. Then, as soon as your browser retrieves a response from https:// example.com, the HSTS header is sent and all subsequent references and requests to http:// example.com are translated at the client side to https:// example.com.
However, the initial redirect is still insecure as https:// example.com 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 www.example.com to example.com 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:// example.com sends the header, the policy applies only to example.com, not to www.example.com. Thus access to www.example.com 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:// example.com and https:// www.example.com 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:// example.com. The redirect rules are as follows:
•http:// www.example.com → https:// example.com
•http:// example.com → https:// example.com
•https:// www.example.com → https:// example.com
In this scenario only https:// example.com has been configued to send the Strict-Transport-Security header.
What will happen?
1.http:// example.com responds with a 301 redirect to https:// example.com which sets the HSTS headers. The HSTS policy will apply only to example.com.
2.All subsequent requests or links to http:// example.com will be translated to https:// example.com
3.Requests to http:// www.example.com will not be translated to https:// www.example.com because www.example.com doesn’t have a HSTS policy. The server will respond with an insecure 301 redirect to https:// example.com 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:// example.com → https:// example.com*
•http:// www.example.com → https:// www.example.com* → https:// example.com*
•https:// www.example.com → https:// example.com*
The asterisk (*) denotes which hosts sends the HSTS header.
Now we’ve secured both the users who access your site through example.com and those who access your site through www.example.com; both domains have the HSTS policy applied.
But we haven’t secured the users who first access http:// example.com, and later access http:// www.example.com; the redirect from http:// www.example.com to https:// www.example.com is insecure because the HSTS policy has not yet been set for www.example.com for these users.
To set the HSTS policy for both domains we can use the includeSubDomains token in the HSTS header:

1
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 www.example.com, the includeSubDomains token will not protect example.com as this is not a subdomain of www.example.com. A solution is to make a request from www.example.com to an uncached resource on https:// example.com, e.g. a 1px image, and make sure that https:// example.com sets the HSTS header. Thus both www.example.com and example.com 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.