Re: libpq should not be using SSL_CTX_set_client_cert_cb

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: libpq should not be using SSL_CTX_set_client_cert_cb
Дата
в 13:22:05
Msg-id
13714.1274890913@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
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 Garick Hamlin <ghamlin@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 Garick Hamlin <ghamlin@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>
Re: libpq should not be using SSL_CTX_set_client_cert_cb Craig Ringer <craig@postnewspapers.com.au>
Re: libpq should not be using SSL_CTX_set_client_cert_cb Tom Lane <tgl@sss.pgh.pa.us>
Garick Hamlin  writes:
> 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...

I'm inclined to think not.  You can instruct libpq to send a non-default
certificate file by setting its sslcert/sslkey parameters, and I think
what people would typically do is just treat those as known properties
of each server connection they have to deal with.  Implementing cert
selection logic inside libpq would simplify such cases, but I can't see
that anybody is likely to get around to that anytime soon.

Chained certs, on the other hand, definitely are in use in the real
world, so we'd better fix libpq to handle that case.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Jan Wieck
Дата:
От: Greg Stark
Дата:
FAQ