On 2023-01-06 Fr 09:28, Jelte Fennema wrote:
>> One reason might be that it doesn't give you any way not to fall back on
>> the system store.
> To not fall back to the system store you could still provide the exact path
> to the CA cert file.
I guess. I don't have strong feelings one way or the other about this.
>
>> +1 for doing this, although I think client certs are less likely to have
>> been issued by a public CA.
> I totally agree that it's less likely. And I definitely don't want to block this
> patch on this feature. Especially since configuring your database server
> is much easier than configuring ALL the clients that ever connect to your
> database.
>
> However, I would like to give a use case where use public CA signed
> client authentication can make sense:
> Authenticating different nodes in a citus cluster to each other. If such
> nodes already have a public CA signed certificate for their hostname
> to attest their identity for regular clients, then you can set up client
> side auth on each of the nodes so that each node in the
> cluster can connect as any user to each of the other nodes in
> the cluster by authenticating with that same certificate.
Yeah, I have done that sort of thing with pgbouncer auth using an ident
map. (There's probably a good case for making ident maps for useful by
adopting the +role mechanism from pg_hba.conf processing, but that's a
separate issue).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
