Re: [PATCH] Automatic client certificate selection support for libpq v1 - Mailing list pgsql-hackers

Wow, blast from the past.

First, I no longer have this use case.

Second, the PGSSLCERT, PGSSLKEY, and other relevant environmental
variables should make most clients able to be "fairly easily" switched
from one server to another.

Third, the only real use case where this feature would be critical is
a client which needs to have connections to two different PostgreSQL
servers at the same time.  Those applications are likely fairly rare
and doing custom programming to support different filenames would
likely be warranted.

However, I still think that this feature would make it easier for
users often connect to multiple servers from different
administrative/security domains.

Given the lack of "me too" or "+1" posts over the past 16 years, I
suspect there may be features with higher user benefit.  I would not
cry if it gets removed.

Thanks,
                    -Seth Robertson



From: "Robin Haberkorn"
Date: Mon, 31 Mar 2025 13:57:55 +0300
To: "Seth Robertson"
Subject: Re: [PATCH] Automatic client certificate selection support for libpq v1

Hello everybody!

I was investigating the item "Allow automatic selection of SSL client
certificates from a certificate store" from the Todo list [1]. If I
understand Seth Robertson in his initial mail correctly, he wanted libpq to
select client certificates automatically based on the host while storing
several client certificates and keys in single crt and key files.

Client certs are currently loaded with SSL_CTX_use_certificate_chain_file()
in src/interfaces/libpq/fe-secure-openssl.c.
While it is theoretically possible to implement host-specific logic using
SSL_CTX_set_client_cert_cb(), I don't think you could store all
the possible certificates in a single file as you might actually already
need several certificates for a single host in the form of a certificate
chain. As was pointed out in the thread back then, you would have to
implement something like a certificate wallet/store from scratch.
At the most, Seth's initial patch could be improved by looking
up per-host client certificate/key files based on the host-reported
server name (SSL_get_servername()), which should be more reliable when
working with host aliases.

But then on the other hand, there are sslcert/sslkey connection parameters
since 8.4, which Seth was apparently aware of. As far as I understand,
he just wanted this patch for 8.3 as well and he didn't want to update
all of his existing programs. Considering that his initial mail was
written 16 years ago, I don't think this is a valid argument anymore.
It should be possible to adapt programs easily, e.g. by accepting
"postgresql://" URIs instead of domains and manually choosing appropriate
certificate/key filenames.

In my opinion there is little than can and should be done in Postgres
at this point. Or does anybody think, that a server-name-based certificate
file selection feature should still be implemented?
If yes, I would be happy to take care of it.
If not, I would suggest to remove this item from the agenda/wiki.

Best regards,
Robin Haberkorn

[1]: http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php

-- 
Robin Haberkorn
Senior Software Engineer
Tel.: +49 157 85228715
E-Mail: haberkorn@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537