Hello!

On Tue, Jan 22, 2013 at 02:11:59PM +0100, António P. P. Almeida wrote:

> 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 {}.

As long as there will be cache layer to avoid re-reading certs -
it might be efficient enough to be usable. It will require much
more code than just adding variables support though, and things
like OCSP stapling won't be available. Overall I would recommend
using server{} blocks instead.

--
Maxim Dounin
http://nginx.com/support.html

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