atom feed7 messages in ru.sysoev.nginxRe: ssl, (no) default and sni
FromSent OnAttachments
GerMalazDec 2, 2009 1:19 am 
Igor SysoevDec 2, 2009 2:14 am 
Maxim DouninDec 2, 2009 2:32 am 
Igor SysoevDec 2, 2009 2:41 am 
Maxim DouninDec 2, 2009 3:02 am 
GerMalazDec 2, 2009 10:42 am 
Igor SysoevDec 2, 2009 11:24 pm 
Subject:Re: ssl, (no) default and sni
From:Maxim Dounin (mdou@mdounin.ru)
Date:Dec 2, 2009 3:02:56 am
List:ru.sysoev.nginx

Hello!

On Wed, Dec 02, 2009 at 01:41:51PM +0300, Igor Sysoev wrote:

On Wed, Dec 02, 2009 at 01:33:00PM +0300, Maxim Dounin wrote:

Hello!

On Wed, Dec 02, 2009 at 01:15:11PM +0300, Igor Sysoev wrote:

On Wed, Dec 02, 2009 at 04:20:14AM -0500, GerMalaz wrote:

Any chance to allow

listen 443 ssl;

this is, NO "default", if SNI is available?

I do not understand what do you want to reach, but since 0.8.21 nginx allows to set listen socket options and features not in default server:

server { listen 443 ssl; server_name name; }

server { listen 443 default_server; server_name _; }

BTW, the problem with listen ... ssl that bugs me is that one can't do something like this:

server { listen 8443 ssl; server_name x; } server { listen 8443 ssl; server_name y; }

We use distinct ips in production, but on testing server there is only 1 ip available and our configuration flattens to something like the above. So we have to use separate ssl servers and activate ssl via ssl on; instead.

Yuo may use

server { listen 8443 ssl; server_name x; } server { listen 8443; server_name y; }

Think of the "ssl" flag as a socket option (although it's not), because you can not do non-SSL request on SSL enabled port.

Yes, I understand. The problem is that config is generated from template like this:

server { listen %ip1%:8443 ssl; server_name x; } server { listen %ip2%:8443 ssl; server_name y; }

It works for ip1 != ip2 case, but fails when ip1 == ip2. Using instead

server { listen %ip1%:8443; server_name x; ssl on; } server { listen %ip2%:8443; server_name y; ssl on; }

works ok in both cases (ip1 == ip2, ip1 != ip2).

I'm not sure we want to fix it, but probably only cheking for conflicts is a good idea.

Maxim Dounin

_______________________________________________ nginx mailing list ngi@nginx.org http://nginx.org/mailman/listinfo/nginx