I wrote:
> It strikes me that we could not only fix this case, but make the libpq
> code simpler and more like the backend case, if we got rid of
> client_cert_cb and instead preloaded the ~/.postgresql/postgresql.crt
> file using SSL_CTX_use_certificate_chain_file().
Just for the archives: I've applied a patch along that line, but it made
me realize afresh what an ugly kluge OpenSSL's API is. Unless I've
missed something basic, it's only possible to load additional certs for
a cert chain into an SSL_CTX object, not an SSL object. (This is
reflected in the fact that SSL_CTX_use_certificate_chain_file doesn't
have an SSL-object equivalent, and even more fundamentally that
SSL_CTX_add_extra_chain_cert doesn't either.) Basically, certificate
stores are managed at the SSL_CTX level not as part of SSL objects.
This is a problem for libpq because it tries to maintain only one
SSL_CTX object per client-side process: if you have multiple PG
connections in a single client process, either concurrently or one
after another, they all share the same SSL_CTX. Now that doesn't
matter so long as all the connections use the same
sslcert/sslkey/sslrootcert/sslcrl settings, but what if they don't?
What will happen as things stand is that all the certs get loaded
into a common pool. That's not too horrible as long as there are
not actual conflicts, but it could mean that for example some
connections trust CA certs that the app programmer expected to only
be trusted for other connections. I did arrange (and test) that the
client cert and key are local to each connection, but leakage of
trusted root certs is a different story.
We could avoid this problem if we were willing to set up a separate
SSL_context for each connection, but I'm not sure if it's worth that.
The scenario where a single application process is managing multiple
distinct sets of trusted certs seems a bit far-fetched anyway.
Comments?
regards, tom lane