Explain the 3 SSL_CTX we have
authorPhil Pennock <pdp@exim.org>
Sun, 2 Dec 2012 23:55:49 +0000 (18:55 -0500)
committerPhil Pennock <pdp@exim.org>
Sun, 2 Dec 2012 23:55:49 +0000 (18:55 -0500)
src/src/tls-openssl.c

index ae009c028457a8c3c870612710bff8890256e25b..08b92bae56f9e3023ed88f804a71d4a97704b6a0 100644 (file)
@@ -46,6 +46,25 @@ static BOOL client_verify_callback_called = FALSE;
 static BOOL server_verify_callback_called = FALSE;
 static const uschar *sid_ctx = US"exim";
 
+/* We have three different contexts to care about.
+
+Simple case: client, `client_ctx`
+ As a client, we can be doing a callout or cut-through delivery while receiving
+ a message.  So we have a client context, which should have options initialised
+ from the SMTP Transport.
+
+Server:
+ There are two cases: with and without ServerNameIndication from the client.
+ Given TLS SNI, we can be using different keys, certs and various other
+ configuration settings, because they're re-expanded with $tls_sni set.  This
+ allows vhosting with TLS.  This SNI is sent in the handshake.
+ A client might not send SNI, so we need a fallback, and an initial setup too.
+ So as a server, we start out using `server_ctx`.
+ If SNI is sent by the client, then we as server, mid-negotiation, try to clone
+ `server_sni` from `server_ctx` and then initialise settings by re-expanding
+ configuration.
+*/
+
 static SSL_CTX *client_ctx = NULL;
 static SSL_CTX *server_ctx = NULL;
 static SSL     *client_ssl = NULL;