Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Jelte Fennema <postgres(at)jeltef(dot)nl>, Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, thomas(at)habets(dot)se, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Date: 2023-01-09 15:40:34
Message-ID: 731b02b9-890a-1190-3ee9-f98642a123de@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-01-09 Mo 10:07, Jelte Fennema wrote:
> Thanks for clarifying your reasoning. I now agree that ssrootcert=system
> is now the best option.

Cool, that looks like a consensus.

>
>>> 2. Should we allow the same approach with ssl_ca_file on the server side, for client cert validation?
>> I don't know enough about this use case to implement it safely. We'd
>> have to make sure the HBA entry is checking the hostname (so that we
>> do the reverse DNS dance), and I guess we'd need to introduce a new
>> clientcert verify-* mode? Also, it seems like server operators are
>> more likely to know exactly which roots they need, at least compared
>> to clients. I agree the feature is useful, but I'm not excited about
>> attaching it to this patchset.

I'm confused. A client cert might not have a hostname at all, and isn't
used to verify the connecting address, but to verify the username. It
needs to have a CN/DN equal to the user name of the connection, or that
maps to that name via pg_ident.conf.

cheers

andrew

--

Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-01-09 15:50:29 Re: PL/pgSQL cursors should get generated portal names by default
Previous Message Laurenz Albe 2023-01-09 15:40:10 Re: Postgres Partitions Limitations (5.11.2.3)