Re: Serverside SNI support in libpq

[skipping right to the weird part, will circle back to the other
questions later]

On Tue, Jan 13, 2026 at 1:57 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> I think the attached is pretty clear improvement over the previous version so
> thanks for the review suggestions. That being said, the test which was
> reported to still fail upstream is failing here as well (it does the right
> thing with the connection, but terminates the handshake in a different place).
> In an attempt to fix that I moved to using the ClientHello callback which
> OpenSSL document to be the right one (yet they use the servername callback
> themselves), but it renders the same result. I hope that your eagle eyes (or
> someone elses) can figure out either what is wrong, or if this is a different
> form of right. The same failing test is added to 0001 to run it in a strictly
> non-SNI config as well.

I hadn't realized that this also regressed without SNI! That helped a lot.

With 0001, the bug is this diff, which runs the verify_cb regardless
of the ssl_ca setting:

> - SSL_CTX_set_verify(context,
> - (SSL_VERIFY_PEER |
> - SSL_VERIFY_CLIENT_ONCE),
> - verify_cb);
> }
>
> + /*
> + * Always ask for SSL client cert, but don't fail if it's not presented.
> + * We might fail such connections later, depending on what we find in
> + * pg_hba.conf.
> + */
> + SSL_CTX_set_verify(context,
> + (SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE),
> + verify_cb);

0002 undid that but reintroduced it in be_tls_open_server():

> /* enable ALPN */
> SSL_CTX_set_alpn_select_cb(SSL_context, alpn_cb, port);
>
> + SSL_CTX_set_verify(SSL_context,
> + (SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE),
> + verify_cb);

If I remove that diff, the regression goes away. But then we start
failing SNI tests:

> [14:24:05.901](0.000s) not ok 72 - host: 'example.com', ca: 'root+client_ca.crt': connect with sslcert, client certificate sent: no stderr
> [14:24:05.902](0.000s) # Failed test 'host: 'example.com', ca: 'root+client_ca.crt': connect with sslcert, client certificate sent: no stderr'
> # at src/test/ssl/t/004_sni.pl line 314.
> [14:24:05.902](0.000s) # got: 'psql: error: connection to server at "127.0.0.1", port 15428 failed: FATAL: connection requires a valid client certificate'
> # expected: ''
> [14:24:05.917](0.000s) not ok 76 - host: 'example.net', ca: 'root+server_ca.crt': connect with sslcert, client certificate sent: matches
> [14:24:05.917](0.000s) # Failed test 'host: 'example.net', ca: 'root+server_ca.crt': connect with sslcert, client certificate sent: matches'
> # at ssl/t/004_sni.pl line 327.
> [14:24:05.917](0.000s) # 'psql: error: connection to server at "127.0.0.1", port 15428 failed: FATAL: connection requires a valid client certificate'
> # doesn't match '(?^:unknown ca)'

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?

--Jacob

[1] https://postgr.es/m/CAOYmi%2Bk%3DVF-2BCqfR49A92tx%3D_QNuL%3D3iT3w6FysOffKw9cxDQ%40mail.gmail.com
[2] https://github.com/openssl/openssl/blob/5d401004a0/ssl/ssl_lib.c#L731