1

I have an SSL certificate being only valid for example.com (not valid for subdomains) and therefore want to redirect both http://example.com and http://www.example.com to https://example.com using nginx. My config file starts as follows:

server {
        # This should catch all non-HTTPS requests to example.com and *.example.com
        listen 80;
        server_name example.com www.example.com;
        access_log off;
        return 301 https://example.com$request_uri;
}

server {
        listen 443 ssl;
        # Actual server config starts here...

However, the redirection does not work as desired. Requesting http://example.com leads correctly to https://example.com, but http://www.example.com will be redirected to https://www.example.com which yields an SSL error as my certificate is not valid for subdomains. I'm aware that there is no possibility of redirecting from invalid HTTPS to valid HTTPS, but I at least want to achieve a redirect from HTTP to HTTPS because users still tend to type in www. in the browser.

When I wget --spider www.example.com, it returns the correct result: 

Spider mode enabled. Check if remote file exists.
--2015-03-19 02:22:47--  http://www.example.com/
Resolving www.example.com (www.example.com)... ***.***.***.*** 
Connecting to www.example.com (www.example.com) **** connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://example.com/ [following]
Spider mode enabled. Check if remote file exists.
--2015-03-19 02:22:47--  https://example.com/
...

But for some reason, browsers end up requesting https://www.example.com rather than https://example.com. I already tried from multiple browsers and computers. Where is my mistake? The whole first server block in the config file seems to be completely ignored - if I delete it, the browser shows the exact same behaviour (with disabled DNS cache), whereas the output of wget --spider changes consistently.

Œlrim
  • 111
  • 1
  • 1
    Your SSL certificate vendor should have issued a certificate valid for both example.com and www.example.com; virtually all of them will do this. Contact them to find out what's wrong with your certificate. – Michael Hampton Mar 19 '15 at 01:52
  • That was my fault, I got a free certificate from StartCom and was given the choice which subdomain they should include. Foolishly, I entered "web" instead of "www" and to change this, I'd need to revoke the certificate and pay 25$. I need a temporary solution. – Œlrim Mar 19 '15 at 01:54
  • 3
    There isn't a temporary solution. If you're using a [HSTS header](https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security) that would explain the unexpected `https://www` redirect - otherwise it's browser cache of some form. – AD7six Mar 19 '15 at 01:56
  • You have to get a Class 2 certificate ($59.90) before you can request revocations with StartSSL. Those are your options with StartCom. The other option is to get a certificate elsewhere. – Paul Mar 19 '15 at 01:59
  • Yes, I will do that shortly. In the meantime, I'll have to disable HSTS. Thank you for that crucial hint. – Œlrim Mar 19 '15 at 02:05
  • Time to replace your StartCom certificate with one from [Let's Encrypt](https://letsencrypt.org/)! Strange HSTS interfered with your (not shown) configuration, unless you explicitely told it to `includeSubDomains`... – Bernard Rosset May 04 '16 at 19:28

0 Answers0