Re: Serverside SNI support in libpq

> On 17 Jan 2026, at 00:44, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:

> I think the root problem probably comes back to SSL_set_SSL_CTX [1].
> That copies the certificate over from the new SSL_CTX, but it doesn't
> really seem to care about much else, and there are a _lot_ of settings
> copied into the SSL pointer during initial connection [2] that are
> ignored there.
>
> The verify mode and callback are two such settings. So is the password
> callback (which may mean that the new per-host-line logic for
> openssl_tls_init_hook won't work correctly either).
>
> So unless Matt Caswell knows of an existing API that does this right,
> I think I'm coming back to the idea that we should keep a single
> SSL_CTX, and then use the selected HostsLine to override individual
> connection settings during the clienthello/servername callback. Do we
> give anything up with that approach?

After discussing this more off-list we collaborated on rewriting the mechanics
for switching out the SSL_CTX settings during SNI selection in the clienthello
callback. The attached version implements this modified approach.

The code now has a single main SSL_CTX object which is reconfigured rather than
swapped out. The HostsLine struct, which keeps the parsed pg_hosts.conf
information, gains an SSL_CTX object which contains the host specific settings,
and this is where they are then copied to the single main during
reconfiguration. The interface with Postgres and how SNI is configured has not
been changed at all. Users who don't enable ssl_sni and configure SSL in the
usual way in postgresql.conf will not notice any difference from today (and
ssl_sni is set to off by default).

As discussed above, the tls_init hook will not work very well for a multi host
setup so in the attached it will only be executed when ssl_sni is set to off.
When ssl_sni is on the ssl_passphrase_cmd parameter will still be honored for
handling passphrases.

We also realized that LibreSSL doesn't support a lot of the functionality
required, as it is *IMHO* falling further and further behind OpenSSL in it's
compatibility layer. The patch adds meson/autoconf checks for required API's
and require these to be present for ssl_sni to be enabled. Longer term I think
we need to start thinking about splitting be-secure-openssl.c into a
be-secure-libressl.c to keep the ifdef soup from getting too bad. Thats for
another patch however.

Some of the new tests added for this patchset turned out to be valuable on
their own as they fill a gap in coverage, they have been pulled out into 0001.
0002 has a few small TODO comments left but is feature complete.

--
Daniel Gustafsson