The following bug has been logged online: Bug reference: 5468 Logged by: Craig Ringer Email address: cr...@postnewspapers.com.au PostgreSQL version: 8.4 Operating system: Ubuntu 10.04, but affects all Description: Pg doesn't send accepted root CA list to client during SSL client cert request Details:
When configured to request a client certificate by the installation of the 'root.crt' file in the data dir, PostgreSQL will instruct OpenSSL to send a CertificateRequest message during the SSL handshake. This asks the client to send a certificate. However, Pg doesn't tell OpenSSL to present the list of accepted signing roots to the client, so the client has no way of knowing what client certificate to present. Existing clients (such as psql) generally only have one certificate/key pair, and will blindly present it without checking what the server supports. So it works fine. If a client has a selection of keypairs, however, it will be unable to negotiate with the server as it has no way to know which keypair to offer. It can brute-force this with multiple connection attempts, but that's more than little ugly. It may also try to guess the right client cert to send based on the cert the server presented, but that'll only work if the server cert happens to be signed by the same CA as the client certs, which is frequently NOT the case. Pg needs to tell OpenSSL to present the accepted root certificate(s) to the client during negotiation, so the client can tell what to do. Adding a suitable call to SSL_CTX_set_client_CA_list(...) in src/backend/libpq/be-secure.c will do the trick, though it'll require explicit loading of the CA cert list rather than the current approach of just telling OpenSSL the file name. This change will fix Java/JDBC clients trying to negotiate with a Pg server. At present, a Java client using the Sun built-in X509KeyManager implementation fails to negotiate because it doesn't know what cert to present to the server. The user may provide a custom X509KeyManager, but in doing so makes it difficult for the user to use PKCS#11 hardware tokens, system-wide single sign-on, kerberos key storage, or other mechanisms. This issue will also affect other clients using key stores capable of holding multiple keys, like Mozilla's NSS and any PKCS#11 hardware token provider, so it's not just Java specific. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
