MIME-Version: 1.0
References: <88986722-5A72-4DEC-8750-BDBF67FF8C01@yesql.se>
 <7E77028B-5A3A-436B-9046-8E9992E9F94A@yesql.se> <Z1jeINLtB05YMVOY@paquier.xyz>
 <E51258CD-C7B2-4BB1-AB9C-A3DD2B6592D0@yesql.se> <F4222274-15C0-40E4-84FB-8FC1355BB8B2@yesql.se>
 <CAOYmi+mSrV8hRaQkvGDf1Df4cmpv5SeTbTxppyxeonMe6MW8nA@mail.gmail.com>
 <0BC5B9B1-6503-4563-AAC6-33DEF264AE3F@yesql.se> <aa7gx3mychf3m2g67mbslzbxjy3if4enpcflstoa5pol3432x5@ugqz45gsvurq>
 <F585452A-1F69-4658-A7E8-D1273AC663ED@yesql.se> <aLT9xVsTVp0j3zWy@paquier.xyz>
 <80F4F8F4-8E4F-4B6F-866B-D837057C1192@yesql.se> <D9F6F14D-FCB1-48B5-9CBC-AE89FA0AEF4C@yesql.se>
 <CAOYmi+m2Ks7D4obtXay3y-UNn6CkTNrmr_zWC25vKTdesatafA@mail.gmail.com>
 <0C53C316-C24E-4307-807B-D825CA3F7254@yesql.se> <DD77A37A-BFCA-4819-A029-1A41E2443D8E@gmail.com>
 <378D83FA-338C-4EA1-BC60-397BE08D0F01@yesql.se> <2025112617144938459246@163.com>
 <0217DEFA-9684-4A77-A005-D30EBEF155C4@yesql.se> <afb479af-2fe7-4790-ad11-437a326329b5@iki.fi>
 <5D0E78E0-EA79-480E-ABD3-B1EF0156BF8B@yesql.se> <f621264b-26a6-4b7a-8982-3820b7d6d397@iki.fi>
 <CAGECzQTWH-bzHcdPo=i09TL_P6_HBBNEkBmr+rpN_J9zVfR2Fw@mail.gmail.com>
 <785C0B88-7068-4576-AF55-251D06CEC112@yesql.se> <CAOYmi+=u=vS1beiog6p5e843uVdout9qZY=pRj4vo=jCVwgGTA@mail.gmail.com>
 <FB2759EB-C8DB-49FA-800F-7010C65EB8DF@yesql.se> <CAOYmi+mZ=i55iH44zPqidZfoNDLwPBMD=PUtD03LR2ut+zMEag@mail.gmail.com>
 <01412917-C42E-4238-97E2-707C32940DDD@yesql.se> <CAOYmi+m05X5fRaeV7w3y4VOePnJJQrihK9A_6ma3e5Pesa5mXA@mail.gmail.com>
 <F3BFF481-E9FD-4893-92D2-925BE2229401@yesql.se>
In-Reply-To: <F3BFF481-E9FD-4893-92D2-925BE2229401@yesql.se>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 16 Jan 2026 15:44:55 -0800
Message-ID: <CAOYmi+nsqYiXLxN7G4A5edBJWXZ8qD=zFnaE2bEzuMj2_xBT7Q@mail.gmail.com>
Subject: Re: Serverside SNI support in libpq
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Heikki Linnakangas <hlinnaka@iki.fi>, 
	Dewei Dai <daidewei1970@163.com>, "li.evan.chao" <li.evan.chao@gmail.com>, 
	Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, 
	Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2BnsqYiXLxN7G4A5edBJWXZ8qD%3DzFnaE2bEzuMj2_xBT7Q%40mail.gmail.com>
Precedence: bulk

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

On Tue, Jan 13, 2026 at 1:57=E2=80=AFAM Daniel Gustafsson <daniel@yesql.se>=
 wrote:
> I think the attached is pretty clear improvement over the previous versio=
n 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 righ=
t
> thing with the connection, but terminates the handshake in a different pl=
ace).
> 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 callbac=
k
> 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 diffe=
rent
> form of right.  The same failing test is added to 0001 to run it in a str=
ictly
> 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 present=
ed.
> +    * 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+cl=
ient_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 cli=
ent 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+se=
rver_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 se=
rver 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%3D3iT3w6FysOf=
fKw9cxDQ%40mail.gmail.com
[2] https://github.com/openssl/openssl/blob/5d401004a0/ssl/ssl_lib.c#L731