Re: Serverside SNI support in libpq

On Fri, Dec 12, 2025 at 3:41 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > 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.

Aha! I think ssl_ca should be moved into the "Optional fields" section
of `struct HostsLine` now.

> I'm still not sure why they pass for me locally with that error, but I've
> updated to patch to match CI.

There's one diff remaining from my old tests patch: the example.org
line doesn't set ssl_ca, so I expect

> - expected_stderr => qr/unknown ca/);
> + expected_stderr => qr/client certificates can only be checked if a root certificate store is available/);

because host_context->ssl_loaded_verify_locations should be false. But
that doesn't happen... Why?

> Adding a boolean GUC which turns ph_hosts (and thus SNI) on or off can perhaps
> fix both complaints?

Sounds reasonable, I think.

--

Just checking my understanding: is the use case for no_sni primarily
that you should be able to strictly refuse clients who say they're
talking to someone else -- so you don't want a wildcard -- but you
still want to gracefully handle clients who don't speak SNI at all?

> + else if (strcmp(host->hostname, "no_sni") == 0)
> + no_sni_context = host_context;

Will anyone be mad at us for camping on the "no_sni" identifier? I
know technically underscore isn't allowed in DNS hostnames, buuuut [1,
2]

> + /* Hostname */
> + field = list_head(tok_line->fields);
> + tokens = lfirst(field);
> + token = linitial(tokens);
> + parsedline->hostname = pstrdup(token->string);

We should probably check tokens->length to make sure that the user
hasn't passed more than one token for each field, similar to how
parse_hba_line() does it.

Should we support multiple hostname tokens in a single line, though,
and just copy the settings that follow across all of them? That would
allow you to collapse

example.org server.crt server.key
example.com server.crt server.key
sub.example.com server.crt server.key
* other.crt other.key

into

example.org,example.com,sub.example.com server.crt server.key
* other.crt other.key

or even

@my-hostnames.txt server.crt server.key
* other.crt other.key

Then you'd have a fighting chance at automatically generating the
lists, especially since we don't do wildcards yet.

--Jacob

[1] https://github.com/netty/netty/pull/8150
[2] https://github.com/openssl/openssl/issues/12566