Thread
-
Re: [PATCH] Automatic client certificate selection support for libpq v1
Robin Haberkorn <haberkorn@b1-systems.de> — 2025-03-31T10:57:55Z
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
-
Re: [PATCH] Automatic client certificate selection support for libpq v1
Seth Robertson <in-pgsql-hackers@baka.org> — 2025-03-31T14:56:40Z
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
-
Re: [PATCH] Automatic client certificate selection support for libpq v1
Jacob Champion <jacob.champion@enterprisedb.com> — 2025-03-31T16:52:49Z
On Mon, Mar 31, 2025 at 9:01 AM Seth Robertson <in-pgsql-hackers@baka.org> wrote: > 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. Can this be handled well enough with a service file? > 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. Yeah, at least not without a solid use case. (If anyone does feel motivated to pick it up, be aware of the server-side SNI work [1]. It'd be nice if the two halves were complementary -- or at minimum, not clashing with each other.) Thanks! --Jacob [1] https://postgr.es/m/1C81CD0D-407E-44F9-833A-DD0331C202E5%40yesql.se
-
Re: [PATCH] Automatic client certificate selection support for libpq v1
Seth Robertson <in-pgsql-hackers@baka.org> — 2025-03-31T20:29:39Z
Yes, at first glance the service file looks like it should work and is a much more elegant and generic method than my proposed hack. I can't trivially tell if the ssl configuration aspect of it was available in 8.3/8.4, but that isn't overly relevant since it is certainly available now. Thanks! -Seth Robertson From: Jacob Champion Date: Mon, 31 Mar 2025 09:52:49 -0700 To: Seth Robertson, To: Robin Haberkorn Subject: Re: [PATCH] Automatic client certificate selection support for libpq v1 On Mon, Mar 31, 2025 at 9:01 AM Seth Robertson <in-pgsql-hackers@baka.org> wrote: > 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. Can this be handled well enough with a service file? > 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. Yeah, at least not without a solid use case. (If anyone does feel motivated to pick it up, be aware of the server-side SNI work [1]. It'd be nice if the two halves were complementary -- or at minimum, not clashing with each other.) Thanks! --Jacob [1] https://postgr.es/m/1C81CD0D-407E-44F9-833A-DD0331C202E5%40yesql.se
-
Re: [PATCH] Automatic client certificate selection support for libpq v1
Bruce Momjian <bruce@momjian.us> — 2025-04-07T23:18:56Z
Great, TODO item removed, thanks. --------------------------------------------------------------------------- On Mon, Mar 31, 2025 at 04:29:39PM -0400, Seth Robertson wrote: > > Yes, at first glance the service file looks like it should work and is > a much more elegant and generic method than my proposed hack. I can't > trivially tell if the ssl configuration aspect of it was available in > 8.3/8.4, but that isn't overly relevant since it is certainly > available now. > > Thanks! > -Seth Robertson > > From: Jacob Champion > Date: Mon, 31 Mar 2025 09:52:49 -0700 > To: Seth Robertson, > To: Robin Haberkorn > Subject: Re: [PATCH] Automatic client certificate selection support for libpq v1 > > On Mon, Mar 31, 2025 at 9:01 AM Seth Robertson > <in-pgsql-hackers@baka.org> wrote: > > 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. > > Can this be handled well enough with a service file? > > > 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. > > Yeah, at least not without a solid use case. (If anyone does feel > motivated to pick it up, be aware of the server-side SNI work [1]. > It'd be nice if the two halves were complementary -- or at minimum, > not clashing with each other.) > > Thanks! > --Jacob > > [1] https://postgr.es/m/1C81CD0D-407E-44F9-833A-DD0331C202E5%40yesql.se > > -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.