Re: libpq should not be using SSL_CTX_set_client_cert_cb

Поиск
Список
Период
Сортировка
От Garick Hamlin
Тема Re: libpq should not be using SSL_CTX_set_client_cert_cb
Дата
Msg-id 20100526155238.GA11419@isc.upenn.edu
обсуждение исходный текст
Ответ на Re: libpq should not be using SSL_CTX_set_client_cert_cb  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: libpq should not be using SSL_CTX_set_client_cert_cb  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Steve Singer
Дата:
Сообщение: Re: Exposing the Xact commit order to the user
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Exposing the Xact commit order to the user