Transforming SSL server cert and private key in variables.

António P. P. Almeida appa at
Tue Jan 22 13:11:59 UTC 2013

On 22 Jan 2013 12h21 CET, mdounin at 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 {;;

map $sni_host $privkey {;;

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

More information about the nginx-devel mailing list