Wrong Vhost being followed when using SSL

Hello all,

I have one server hosting two sites and am trying to set up my nginx
vhost.conf to have both sites working with SSL.

My vhost.conf file can be seen here (domain names have been changed):
http://pastie.org/357919

Everything works fine except when trying to access a secure page for
reddomain.com, which is being picked up by the server block for
bluedomain.com

To clarify, despite using server_name to set which domain a server block
applies to, the secure reddomain.com is following the first ‘listen 443’
it comes across and making use of the incorrect ssl certificate and
giving invalid certificate errors when viewing with a browser.

If I swap the server blocks over so ssl server block for reddomain.com
is first, the problem is switched, with reddomain.com loading fine but
bluedomain complaining of an invalid certificate.

What confuses matters more is that if we agree to view the page despite
an invalid certificate, the correct app for that domain is loaded (so
although reddomain may get follow the server block of bluedomain, the
outcome is the reddomain app getting loaded).

So my question is:

  • For the domains on port 443, why are they following the first server
    block that is listening to that port, ignoring the fact that the domain
    is not listen in ‘server_name’?

and come anyone see what I may be doing wrong from my vhost.conf, or
bring anything to my attention that may be causing this problem

On Sun, Jan 11, 2009 at 9:29 PM, James R. [email protected]
wrote:

bluedomain.com
What confuses matters more is that if we agree to view the page despite
and come anyone see what I may be doing wrong from my vhost.conf, or
bring anything to my attention that may be causing this problem

Posted via http://www.ruby-forum.com/.

only one certificate per ip is allowed for ssl connection

Unless you are using a wild card certificate you can associate at most
one vhost per IP for SSL.

Cheers

Dave

On Sun, Jan 11, 2009 at 6:29 AM, James R. [email protected]
wrote:

  • For the domains on port 443, why are they following the first server
    block that is listening to that port, ignoring the fact that the domain
    is not listen in ‘server_name’?

I had the same issue; although I thought it was due to maybe the load
balancing in front of my server. I thought name-based SSL was usable
by now, and I thought I had my cert wrong :slight_smile:

When looking at the nginx debug log, it seems to negotiate the SSL
conversation first, and then it gets the Host: header after. So it
made sense. however, to get the SSL conversation properly processed it
has to be the right SSL cert; typically SSL requires one IP per cert,
but I believe you can do name-based SSL now. However I don’t think
it’s supported enough…

“Server Name Indication (SNI), as described in section 3.1 of the
RFC3546, is a TLS extension which makes the configuration of
SSL-enabled name-based virtual hosts possible.” [1]

It does appear that the SSL gods have wisened up - no more wasting
IPs, hopefully, and with a new protocol/extensions to existing ones it
may be possible. I haven’t found out yet browser compatibility/etc,
and then of course I don’t think nginx supports it yet. However, if it
does have wide compatibility, this would definately be something to
request for nginx (I could use it right now!)

[1] for example,

On Sun, Jan 11, 2009 at 12:15 PM, mike [email protected] wrote:

It does appear that the SSL gods have wisened up - no more wasting
IPs, hopefully, and with a new protocol/extensions to existing ones it
may be possible. I haven’t found out yet browser compatibility/etc,
and then of course I don’t think nginx supports it yet. However, if it
does have wide compatibility, this would definately be something to
request for nginx (I could use it right now!)

Oops. According to wikipedia
Server Name Indication - Wikipedia nginx already can
support this.

However, I just noticed - IE6 and IE7 on XP don’t. Doh. How pathetic.
All it would be is a frickin couple files changed probably.

For nginx to support it, you just need OpenSSL built with SNI support
(–enable-tlsext) and I’m not sure if you have to specify
ssl_protocols or something related to ‘force’ that protocol all the
time in nginx or not.

This sucks though. I have to support IE6/IE7 on XP…

On Sun, Jan 11, 2009 at 12:25:26PM -0800, mike wrote:

Server Name Indication - Wikipedia nginx already can
support this.

However, I just noticed - IE6 and IE7 on XP don’t. Doh. How pathetic.
All it would be is a frickin couple files changed probably.

For nginx to support it, you just need OpenSSL built with SNI support
(–enable-tlsext) and I’m not sure if you have to specify
ssl_protocols or something related to ‘force’ that protocol all the
time in nginx or not.

You do not need to configure SNI in nginx: it just works if there is
OpenSSL support.

This sucks though. I have to support IE6/IE7 on XP…

The single hope is Windows 7. If it will be lighter than Vista,
then people may consider to upgrade.

On Jan 13, 2009, at 5:56 AM, Igor S. [email protected] wrote:

does have wide compatibility, this would definately be something to
(–enable-tlsext) and I’m not sure if you have to specify

Sadly the UI is all vista-y and is really pissing me off. But think of
how long it takes to upgrade the general public. It will be a long
time before SNI equipped windows is the standard. There is probably
more chance in them patching the existing IEs…

Sadly the UI is all vista-y and is really pissing me off. But think
of how long it takes to upgrade the general public. It will be a
long time before SNI equipped windows is the standard. There is
probably more chance in them patching the existing IEs…

I’d be betting on major countries moving to IPv6 before SNI is
mainstream.

Cheers

Dave

On Sun, Jan 11, 2009 at 3:29 PM, James R. [email protected]
wrote:

Hello all,

I have one server hosting two sites and am trying to set up my nginx
vhost.conf to have both sites working with SSL.

Hi,

We run into this issue last year for http://www.digiprof.fr . If you
can search the mailing-list you will see how we got around it. But
basically the idea is to have one IP address per SSL certificate. We
use IP failovers.

yeah, ipv6 is one of those “how the hell to upgrade ‘john q public’
user” issues