Re: Serverside SNI support in libpq
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Daniel Gustafsson <daniel@yesql.se>, Dewei Dai <daidewei1970@163.com>
Cc: "li.evan.chao" <li.evan.chao@gmail.com>,
Jacob Champion <jacob.champion@enterprisedb.com>,
Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>,
Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-03T09:57:32Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ssl: Serverside SNI support for libpq
- 4f433025f666 19 (unreleased) landed
-
ssl: Add tests for client CA
- 25e568ba7ce7 19 (unreleased) landed
Sorry for jumping in so late. On Fri, May 10, 2024 at 7:23 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote: > The attached patch adds serverside SNI support to libpq, it is still a bit > rough around the edges but I'm sharing it early to make sure I'm not designing > it in a direction that the community doesn't like. A new config file > $datadir/pg_hosts.conf is used for configuring which certicate and key should > be used for which hostname. The file is parsed in the same way as pg_ident > et.al so it allows for the usual include type statements we support. A new > GUC, ssl_snimode, is added which controls how the hostname TLS extension is > handled. The possible values are off, default and strict: > > > - off: pg_hosts.conf is not parsed and the hostname TLS extension is > not inspected at all. The normal SSL GUCs for certificates and keys > are used. > - default: pg_hosts.conf is loaded as well as the normal GUCs. If no > match for the TLS extension hostname is found in pg_hosts the cert > and key from the postgresql.conf GUCs is used as the default (used > as a wildcard host). > - strict: only pg_hosts.conf is loaded and the TLS extension hostname > MUST be passed and MUST have a match in the configuration, else the > connection is refused. > > > As of now the patch use default as the initial value for the GUC Do we need the GUC? It feels a little confusing that a GUC affects how the settings in the pg_hosts.conf are interepreted. It'd be nice if you could open pg_hosts.conf in an editor, and see at one glance everything that affects this. 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). Should we support wildcards like "*.example.com* too? For backwards-compatibility, if you specify a certificate and key in postgresql.conf, they are treated the same as if you had a "*" line in pg_hosts.conf. - Heikki