On Mon, Jan 9, 2023 at 7:40 AM Andrew Dunstan <and...@dunslane.net> wrote: > 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.
Right. But I don't know anything about the security model for using a publicly issued server certificate as a client certificate. So if you tell me that your only requirement is that the hostname/CN matches an entry in your ident file, and that you don't need to verify that the certificate identifying example.org is actually coming from example.org, or do any sort of online revocation processing to help mitigate the risks from that, or even handle wildcards or SANs in the cert -- fine, but I don't know the right questions to ask to review that case for safety or correctness. It'd be better to ask someone who is already comfortable with it. >From my perspective, ssl_ca_file=system sure *looks* like something reasonable for me to choose as a DBA, but I'm willing to guess it's not actually reasonable for 99% of people. (If you get your pg_ident rule wrong, for example, the number of people who can attack you is scoped by the certificates issued by your CA... which for 'system' would be the entire world.) By contrast I would have no problem recommending sslrootcert=system as a default: a certificate can still be misissued, but a would-be attacker would still have to get you to connect to them. That model and its risks are, I think, generally well understood by the community. --Jacob