1

I have an ssl certificate for www.domain.com. Obviously if someone goes to https: //domain.com, they will get an error from the browser about a certificate mismatch. Is it possible to setup the webserver to redirect requests from https:// domain.com to https:// www.domain.com?

In nginx, I've been trying variations of this, but to no avail:

server { listen 443; server_name www.domain.com domain.com; if ($host !~ www.domain.com) { rewrite ^/(.*) https://www.domain.com/$1 permanent; } }

Edit: Just to clarify if anyone hits the site at via plain http, it's not a problem, I already can redirect them to https:// www.domain.com, which is correct. It's only if they manually type https:// domain.com, that I don't know how to do the redirection.

Improve this question
2
  • 1
    It is possible, but anyway request to domain.com would show cert warning before redirect. You need to fix your certificate, not redirects. Commented Jul 4, 2011 at 18:04
  • For the correct method check out this post: serverfault.com/a/337893/26204 Commented Dec 5, 2011 at 20:46

3 Answers 3

Reset to default
2

Unfortunately, a redirection response can only take place after the SSL session has been established.

This is clearly a certificate issue; you need a certificate that contains www.domain.com with domain.com as the SAN (Subject Alternative Name). Most CA's give a single SAN for free, e.g., digicert.

Improve this answer
0 
server { listen 443; servername www.domain.com domain.com; if ($host ~ ^(?!www)) { rewrite ^/(.*)$ http://www.$host/$1 permanent; } }

second thought it might be better to use two server blocks:

server { listen 443; server_name domain.com; rewrite ^(.*) http://www.example.com$1 permanent; } server { listen 443; server_name www.domain.com; hosting configuration here }

EDIT: What about adding domain.com as a SubjectAltName in your SSL Cert so you don't have to rewrite. Perhaps ask your CA if this is possible?

Worst case, shell the $$ for a certificate to domain.com :D

Improve this answer
6
  • Yea, I had tried something similar. I do have two separate blocks for regular http, and that works perfectly. Every request that doesn't match www.domain.com is sent to www.domain.com and all the configuration is there. The same thing doesn't work for https though. My guess is that it simply can't work with https, it's probably a limitation of the protocol because it wants to create the secure connection before processing the redirect. Commented Apr 11, 2011 at 4:17
  • I think you're right, its prob something particular to SSL and likely by design Commented Apr 11, 2011 at 4:23
  • relevant thread with nginx creator: forum.nginx.org/read.php?2,84559 Commented Apr 11, 2011 at 4:26
  • TLDR; thread implies you may need the certificate for domain.com as well Commented Apr 11, 2011 at 4:30
  • Sadness, I just read it. It makes sense why that is the case, but unfortunate none the less. Commented Apr 11, 2011 at 4:39
0

I use this to push users to a https service:

server { listen 80; server_name mail.polemon.org; rewrite ^(.*)$ https://mail.polemon.org$1 permanent; }

and this is a catch-all rule:

server { listen 80; server_name polemon.org *.polemon.org; if ($host != polemon.org) { rewrite ^(.*)$ http://polemon.org$1 permanent; } }

The catch-all has to be defined last, otherwise other subdomains won't work.

And here's another example, how to deal with people that have no Host: header line:

server { listen 80 default; server_name _; server_name_in_redirect off; root /var/www/jail/; index index.html; }

As a side note, you can create certificates for wildcarded DNS names. Those are called "wild certificates", and even if they're valid, Firefox users still get warnings.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.