Re: libpq should not be using SSL_CTX_set_client_cert_cb

On Tue, May 25, 2010 at 10:29:07PM -0400, Tom Lane wrote:
> 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:

I don't understand the problem (I don't know the code).  

However, requiring intermediate certs be prepopulated in a trust store will 
effectively make use cases like Bridged PKI not practical.  (and think that 
use cases like that will be very interesting as things like various PIV 
Cards projects are implemented).  

InCommon is also rolling out personal and machine certificates soon and 
there are some potentially similar use cases there for educational 
communities.  Their offering is not a bridge (although some users could
join a bridge), but there will likely be many different intermediate CA
created and likely created on a regular basis so the same issue exists.

Ideally, I think the client code should be able to compute a path to an
offered Trust Anchor and present it.  The server should not have to store 
and keep up-to-date the entire bridge's repository to authenticate any user. 
This would be the "right way", IMO.

It should be easy for the client to build a path: they have the Trust Anchor 
in their store along with whatever intermediate certs they need otherwise
their cert would be less than useful.  They just need to send that chain.

I am guessing the problem is that validating the presented chain is hard?  
or am I misunderstanding the reason to want to nail down all the 
intermediates ahead of time.  

Again, I am not very familiar with what that code does currently....

Garick

> 
>     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