BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request

The following bug has been logged online:

Bug reference: 5468
Logged by: Craig Ringer
Email address: craig(at)postnewspapers(dot)com(dot)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.