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.

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.
    – rvs
    Jul 4, 2011 at 18:04
  • For the correct method check out this post: serverfault.com/a/337893/26204 Dec 5, 2011 at 20:46

3 Answers 3

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.

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

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.
    – AJ01
    Apr 11, 2011 at 4:17
  • I think you're right, its prob something particular to SSL and likely by design
    – iainlbc
    Apr 11, 2011 at 4:23
  • relevant thread with nginx creator: forum.nginx.org/read.php?2,84559
    – iainlbc
    Apr 11, 2011 at 4:26
  • TLDR; thread implies you may need the certificate for domain.com as well
    – iainlbc
    Apr 11, 2011 at 4:30
  • Sadness, I just read it. It makes sense why that is the case, but unfortunate none the less.
    – AJ01
    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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .