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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers