> On 11 Dec 2025, at 18:47, Jacob Champion <[email protected]> > wrote: > On Mon, Nov 24, 2025 at 6:53 AM Daniel Gustafsson <[email protected]> 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 callback >> need to be defined in the default context even if there is no CA for it to be >> called in an SNI setting because OpenSSL), and that the tests were matching >> 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). I'm still not sure why they pass for me locally with that error, but I've updated to patch to match CI. >> + if (host->ssl_ca && host->ssl_ca[0] != '\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? The attached version allows ssl_ca to be omitted from the pg_host config to match the ssl_ca GUC. > On Wed, Dec 3, 2025 at 1:57 AM Heikki Linnakangas <[email protected]> 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). The attached version removes the GUC and instead sets a precedence rule that if pg_hosts exists and is non-empty, it is exclusively used. If it doesn't exist, or is empty, then the regular SSL GUCs are used. Further, pg_hosts is extended with handling * for default fallback, and no_sni for rules targeting connections with no hostname. The docs changes were harder than implementing the code, suggestions on how to improve that part would be greatly appreciated. But, see below. >> 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.) I wonder if the way forward is to do both? Heikki has a good point that when working with pg_hosts.conf it should be clear from just that file what the final config will be, and in the previous version that wasn't the case since the ssl_snimode GUC set operation modes. At the same time, Jacob has a point that overriding configuration just because pg_hosts exists isn't transparent. Adding a boolean GUC which turns ph_hosts (and thus SNI) on or off can perhaps fix both complaints? If the GUC is on, pg_hosts - and only pg_hosts - is used for configuring secrets. By using the * fallback and no_sni rule in pg_hosts all variations of configs can be achieved. If the GUC is off, then the regular SSL GUCs are used and pg_host is never considered (and thus SNI is not possible). Such a GUC wouldn't make the patch all that much different from what it is right now. What do you think about that middleground proposal? -- Daniel Gustafsson
v13-0001-Serverside-SNI-support-for-libpq.patch
Description: Binary data
