ssl_session_cache get incorrect shm zone

[uvuv@…]

ssl session of b.com will set to shm zone SA !!!!!!!!

conf:
server {
listen 443 ssl;
server_name *.a.com;
ssl_session_cache shared:SA:5m;
......
}

server {
listen 443 ssl;
server_name *.b.com;
ssl_session_cache shared:SB:5m;
......
}

fix1:
ngx_http_ssl_servername:

if (sscf->ssl.ctx) {
......
c->ssl->session_ctx = sscf->ssl.ctx;
}

or fix2:
ngx_ssl_new_session:
ngx_ssl_get_cached_session:
replace c->ssl->session_ctx by SSL_get_SSL_CTX(ssl_conn);

or both.

[uvuv@…]

also ngx_ssl_session_ticket_key_callback

[Maxim Dounin]

Session resumption happens in the context of the default server. This is how OpenSSL works, and there isn't much we can do about this.

Note well that the "fixes" suggested won't actually fix anything, but will break such configurations instead. See 97f102a13f33 and ticket #235 for additional details.

[uvuv@…]

How to config different shm for servers.

new session callback called at SSL_ST_OK, and it after ngx_http_ssl_servername;
but get session callback called before ngx_http_ssl_servername;

session cache get ssl context for the current server config, not the default config.

I don't think use the origin ssl context is a good idea.

The purpose of nginx to get the ssl contex is to get the matched server's shm zone, not the default !!!

[Maxim Dounin]

As already explained, session resumption happens in the context of the default server. The SNI callback (ngx_http_ssl_servername()) is called only after the session is either resumed or not. That is, if a default server uses cache A, and some SNI-based virtual host uses cache B, you will be able to store a session to B, but won't be able to resume this session - as cache A will be used during session resumption (because it happens before the SNI callback).

Accordingly, if for some reason you want to configure different session caches in different servers, you have to use real servers with different listen sockets (usually, servers listening on different IP addresses), and not just SNI-based virtual servers.