Thread

  1. Re: Serverside SNI support in libpq

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-17T23:58:10Z

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