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

From Seth Robertson
Subject Re: [PATCH] Automatic client certificate selection support for libpq v1
Date
Msg-id 200905081747.n48HlS3f004765@no.baka.org
Whole thread Raw
In response to Re: [PATCH] Automatic client certificate selection support for libpq v1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Automatic client certificate selection support for libpq v1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
In message <8766.1241799013@sss.pgh.pa.us>, Tom Lane writes:
   Seth Robertson <in-pgsql-hackers@baka.org> writes:   > I had a situation where I needed to connect to multiple
postgresql  > servers in a variety of programs written in a variety of languages,   > including some which connected to
multipleservers at the same time.   > As some of you might know, you cannot usefully put multiple   > certificates or
keysin the postgresql.crt/.key files.      Hmm, shouldn't we fix *that* rather than inventing a hack like this?
 

I certainly agree that it would be ideal.  My understanding is that
OpenSSL does not really support certificate stores/wallets or other
methods of automatically handling multiple certificates (see
http://gagravarr.org/writing/openssl-certs/general.shtml and
http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html, the
latter which says: "NOTES The internal certificate store of OpenSSL
can hold two private key/certificate pairs at a time: one
key/certificate of type RSA and one key/certificate of type DSA.")

The http://www.openssl.org/docs/ssl/SSL_CTX_set_client_cert_cb.html
document suggests that the callback function (which postgresql already
uses) can be extended to search a private certificate store to select
and return the proper certificate.  However, it is not clear from this
manual page how to get access to the information about the requested
certificate--I can only presume the information was sent to the
client.  Following each certificate chain from the client certificates
loaded back to see if any match would be pretty painful as well.

Basically doing this would probably become a project instead of a 5
minute hack to support 80% of the functionality.  I understand the
desire to limit the number of hacks in the source code, though.
                -Seth Robertson                 in-pgsql-hackers@baka.org



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Some 8.4 changes needed according to pg_migrator testing
Next
From: Tom Lane
Date:
Subject: Re: Some 8.4 changes needed according to pg_migrator testing