On 22 Jan 2013 12h21 CET, mdounin@mdounin.ru wrote:

> Hello!

Hello Maxim,

Thank you for your reply.

> On Tue, Jan 22, 2013 at 11:21:44AM +0100, António P. P. Almeida
> wrote:
>
>> Hello,
>>
>> I've not yet ventured into Nginx C module coding, but I would like
>> to know if changing the current SSL module directives:
>> ssl_certificate and ssl_certificate_key, so that instead of strings
>> they can be variables (complex values) is feasible, or due to the
>> fact that SSL happens below the protocol layer, is much more
>> difficult, than, for instance, the recent transformation in
>> variables of the auth_basic module directives?
>
> It is going to be much more difficult, as you have to reload
> certificates and keys into SSL context before asking OpenSSL to
> establish connection, and you'll likely need at least some caching
> layer in place to make things at least somewhat reasonable from
> performance point of view.
>
> Besides that, the only connection-specific info available when
> establishing SSL connection is remote address (in all cases) and
> server name indicated by a client (in case of SNI). Which makes
> it mostly useless, as remote address destinction is mostly useless
> (and/or should be done at layer 3), and server{} blocks are here
> to handle server name distinction.

It's precisely for SNI in mass SSL hosting. Wouldn't be much more
efficient if there was a callback that returned the host (SNI) and
that would select a proper (cert, key) pair so that instead of
reloading we could proceed without having to reload the config?

I would like for something of the kind.

map $sni_host $cert {
example.net example.net.pem;
example.com example.com.pem;
...
}

map $sni_host $privkey {
example.net key.example.net.pem;
example.com key.example.com.pem;
...
}

Then in the server block:

server {
listen 80;
listen 443 ssl;
server_name *.example.*;

ssl_certificate $cert;
ssl_certificate_key $privkey;

...
}

Also this will avoid having a plethora of server {}.

Thank you,
--- appa

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