Re: libpq should not be using SSL_CTX_set_client_cert_cb - Mailing list pgsql-hackers

From Garick Hamlin
Subject Re: libpq should not be using SSL_CTX_set_client_cert_cb
Date
Msg-id 20100526155238.GA11419@isc.upenn.edu
Whole thread Raw
In response to Re: libpq should not be using SSL_CTX_set_client_cert_cb  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: libpq should not be using SSL_CTX_set_client_cert_cb
List pgsql-hackers
On Wed, May 26, 2010 at 10:54:42AM -0400, Tom Lane wrote:
> Garick Hamlin <ghamlin@isc.upenn.edu> writes:
> > I am guessing the problem is that validating the presented chain is hard?  
> 
> No, the problem is that the current libpq code fails to present the
> chain at all.  It will only load and send the first cert in the
> postgresql.crt file.  This works only when the client's cert is signed
> directly by one of the CAs trusted by the server.

Sorry, I just re-read your original message.  You were clear, but I read
it wrong.

This is much less limiting than what I thought was being suggested.  Having 
a user's credentials work with only one trust anchor isn't that bad.  I am 
not familiar enough with openssl to know if there is a specific pitfall to
the change you suggested (which I think was what you were asking)..

One could make it work with multiple TAs in a similar fashion if it also 
checked for the existence of a directory (like: ~/.postgresql/client_ta ) to 
store chains to each supported TA by fingerprint.  

That might not be worth the effort at this point...

Garick

> 
>             regards, tom lane


pgsql-hackers by date:

Previous
From: Steve Singer
Date:
Subject: Re: Exposing the Xact commit order to the user
Next
From: Robert Haas
Date:
Subject: Re: Exposing the Xact commit order to the user