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>
In-Reply-To: <785C0B88-7068-4576-AF55-251D06CEC112@yesql.se>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 11 Dec 2025 09:47:28 -0800
Message-ID: 
 <CAOYmi+=u=vS1beiog6p5e843uVdout9qZY=pRj4vo=jCVwgGTA@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%2B%3Du%3DvS1beiog6p5e843uVdout9qZY%3DpRj4vo%3DjCVwgGTA%40mail.gmail.com>
Precedence: bulk

Hi!

On Mon, Nov 24, 2025 at 6:53=E2=80=AFAM Daniel Gustafsson <daniel@yesql.se>=
 wrote:
> The attached incorporates your tests, fixes them to make them pass.  The
> culprit seemed to be a combination of a bug in the code (the verify callb=
ack
> need to be defined in the default context even if there is no CA for it t=
o be
> called in an SNI setting because OpenSSL), and that the tests were matchi=
ng
> backend errors against frontend messages.

The new v12 tests still don't pass for me (they all use "certificate
verify failed", but the failure modes should be different).

> +           if (host->ssl_ca && host->ssl_ca[0] !=3D '\0')

The comment for HostsLine.ssl_ca, and the code that assigns it,
implies to me that host->ssl_ca should never be NULL. Am I missing a
case where it could be?

On Wed, Dec 3, 2025 at 1:57=E2=80=AFAM Heikki Linnakangas <hlinnaka@iki.fi>=
 wrote:
> I propose that there is no GUC. In 'pg_hosts.conf', you can specify a
> wildcard '*' host that matches anything. You can also specify a "no sni"
> line which matches connections with no SNI specified. (Or something
> along those lines, I didn't think too hard about all the interactions).

That seems to position SNI as a feature that every DBA should have to
think about by default. ("learn this file. you can't turn it off.") Is
it, yet?

Web servers enable SNI implicitly because name-based hosting is a
top-level concept for users over there (hostnames are baked into the
application layer). I would argue that we don't have that here. Maybe
in the future someone will ask for that, but at that point don't you
want a very different, name-based, config system?

On Wed, Dec 3, 2025 at 3:28=E2=80=AFPM Daniel Gustafsson <daniel@yesql.se> =
wrote:
> > On 3 Dec 2025, at 22:27, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> > What if we make it so that if a pg_hosts.conf file exists, then the
> > ssl_cert_file/ssl_key_file configs are ignored? And by default initdb
> > would not create a file (or it would, but with the same default
> > settings that we have now).
>
> Maybe.  I'm not a big fan of magic-file-exist configurations

Me neither. (I especially don't like the idea of ignoring a
certificate+key setting that a user has taken the time to put into a
config.)

Thanks,
--Jacob