Results 1 to 7 of 7
  1. #1
    Join Date
    Jun 2014
    Posts
    217
    Points
    3,880
    Level
    26

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

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

    Cheers,
    Michael

  2. #2
    Join Date
    Apr 2012
    Posts
    2,150
    Points
    23,244
    Level
    66
    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

  3. The Following User Says Thank You to d2d4j For This Useful Post:


  4. #3
    Join Date
    Apr 2012
    Posts
    2,150
    Points
    23,244
    Level
    66
    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

  5. The Following User Says Thank You to d2d4j For This Useful Post:


  6. #4
    Join Date
    Jun 2014
    Posts
    217
    Points
    3,880
    Level
    26
    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 ;-)

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

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


    Cheers,
    Michael

  7. The Following User Says Thank You to mdeinhardt For This Useful Post:


  8. #5
    Join Date
    Jun 2014
    Posts
    217
    Points
    3,880
    Level
    26
    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.

  9. The Following User Says Thank You to mdeinhardt For This Useful Post:


  10. #6
    Join Date
    Apr 2012
    Posts
    2,150
    Points
    23,244
    Level
    66
    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
    Last edited by d2d4j; 08-22-2017 at 12:43 PM.

  11. #7
    Join Date
    Apr 2012
    Posts
    2,150
    Points
    23,244
    Level
    66
    Hi Michael
    I came accross this so hopefully help you, but sorry if you have alread seen it
    Many thanks
    John
    https://sentinelstand.com/article/ht...-www-redirects

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •