Re: Making sslrootcert=system work on Windows psql - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Making sslrootcert=system work on Windows psql
Date
Msg-id CAGECzQTm4Pazv3g+42fhc3MhZYAKZ_bVq2YyFjebYdME2+a45Q@mail.gmail.com
Whole thread Raw
In response to Re: Making sslrootcert=system work on Windows psql  (George MacKerron <george@mackerron.co.uk>)
Responses Re: Making sslrootcert=system work on Windows psql
List pgsql-hackers
On Wed, 23 Apr 2025 at 17:47, George MacKerron <george@mackerron.co.uk> wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly named for Windows users.
sslrootcert=systembecomes a deprecated synonym for this option. 
>
> (2) sslrootcert=os

Okay I have some time to respond to this thread now. My main thought is this:

I think we should try as hard as possible for sslrootcert=system to do
"the right thing" on all platforms. "the right thing" being: allowing
users to connect to a Postgres server if the cert of that server. It's
a huge shame that MANY users connect to their production Postgres
databases over unauthenticated TLS. I believe the only way to fix that
is by having a *standard* & *secure* connection string that people can
copy paste from their database service provider's portal. Adding new
options that users need to choose between makes it impossible for
database providers to provide such a *standard* connection string
because the exact string will depend on the platform. Which means
they'll continue to only provide sslmode=require in their provided
connstrings. And even if we can somehow avoid that, it will reset the
clock on when most clients will actually support that *standard*
connection string. Thus increasing the time (by at least two years)
before database providers dare to put these options in their default
connection strings, in fear of their customers not being able to
connect and opening support requests or closing their accounts.

But yeah, the discussed situation is problematic for this: Windows
machines have multiple cert stores that could be reasonably considered
the system store.

So I'd like to propose a different way around that problem: Instead
adding more connection options. How about we add a *compile time*
option that allows the person that compiles libpq to choose which cert
store it should use if sslrootcert=system is provided. Something like
--system-cert-store=openssl and --system-cert-store=winstore flags for
./configure. This way users don't have to choose between the various
system stores to get behaviour that is sensible. Which one should be
the default, requires discussion, and maybe we'd want to let that
depend on the OpenSSL version or change it in the future. We could
even make it required for people compiling libpq on Windows (with an
OpenSSl version that supports winstore) to choose between these two
options, by making it a required flag.

Note: This doesn't mean we couldn't allow people to override the
compile time systemstore at runtime with e.g. sslsystemstore=winstore,
but the default would be the one that was chosen at compile time.

> BIGGER IDEA

I would really like to get to a point where libpq by default fails to
connect if you're not connecting to Postgres in a secure way: i.e. one
where you're not both encrypting traffic and authenticating the host
(unless you're connecting over unix sockets and maybe local loopback).
I think there's no point in actually working on/proposing that until
we have a secure connection string that works on all systems (i.e.
what sslrootcert=system is supposed to do)



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Fix premature xmin advancement during fast forward decoding
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: sslmode=secure by default (Re: Making sslrootcert=system work on Windows psql)