I've been experimenting with SSL setups involving chains of CA
certificates, ie, where the server or client cert itself is signed by
an intermediate CA rather than a trusted root CA. This appears to work
well enough on the server side if you configure the server correctly
(see discussion of bug #5468). However, libpq is not able to work with
a client certificate unless that cert is directly signed by a CA that
the server trusts (ie, one listed directly in the server's root.crt file).
This is because there is no good way to feed back any intermediate CA
certs to the server. The man page for SSL_CTX_set_client_cert_cb says
in so many words that the client_cert_cb API is maldesigned:
BUGS
The client_cert_cb() cannot return a complete certificate chain,
it can only return one client certificate. If the chain only has
a length of 2, the root CA certificate may be omitted according
to the TLS standard and thus a standard conforming answer can be
sent to the server. For a longer chain, the client must send the
complete chain (with the option to leave out the root CA
certificate). This can only be accomplished by either adding the
intermediate CA certificates into the trusted certificate store
for the SSL_CTX object (resulting in having to add CA
certificates that otherwise maybe would not be trusted), or by
adding the chain certificates using the
SSL_CTX_add_extra_chain_cert(3) function, which is only
available for the SSL_CTX object as a whole and that therefore
probably can only apply for one client certificate, making the
concept of the callback function (to allow the choice from
several certificates) questionable.
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(). Then, using an
indirectly signed client cert would only require including the full cert
chain in that file.
So I'm wondering if there was any specific reason behind using the
callback API to start with. Anybody remember?
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
