Re: [PATCH] Automatic client certificate selection support for libpq v1

In message <8766(dot)1241799013(at)sss(dot)pgh(dot)pa(dot)us>, Tom Lane writes:

Seth Robertson <in-pgsql-hackers(at)baka(dot)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 multiple servers at the same time.
> As some of you might know, you cannot usefully put multiple
> certificates or keys in 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(at)baka(dot)org