Re: [PATCH] Automatic client certificate selection support for libpq v1

Поиск
Список
Период
Сортировка
От Seth Robertson
Тема Re: [PATCH] Automatic client certificate selection support for libpq v1
Дата
Msg-id 200905081747.n48HlS3f004765@no.baka.org
обсуждение исходный текст
Ответ на Re: [PATCH] Automatic client certificate selection support for libpq v1  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Automatic client certificate selection support for libpq v1  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
In message <8766.1241799013@sss.pgh.pa.us>, Tom Lane writes:
   Seth Robertson <in-pgsql-hackers@baka.org> writes:   > I had a situation where I needed to connect to multiple
postgresql  > servers in a variety of programs written in a variety of languages,   > including some which connected to
multipleservers at the same time.   > As some of you might know, you cannot usefully put multiple   > certificates or
keysin the postgresql.crt/.key files.      Hmm, shouldn't we fix *that* rather than inventing a hack like this?
 

I certainly agree that it would be ideal.  My understanding is that
OpenSSL does not really support certificate stores/wallets or other
methods of automatically handling multiple certificates (see
http://gagravarr.org/writing/openssl-certs/general.shtml and
http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html, the
latter which says: "NOTES The internal certificate store of OpenSSL
can hold two private key/certificate pairs at a time: one
key/certificate of type RSA and one key/certificate of type DSA.")

The http://www.openssl.org/docs/ssl/SSL_CTX_set_client_cert_cb.html
document suggests that the callback function (which postgresql already
uses) can be extended to search a private certificate store to select
and return the proper certificate.  However, it is not clear from this
manual page how to get access to the information about the requested
certificate--I can only presume the information was sent to the
client.  Following each certificate chain from the client certificates
loaded back to see if any match would be pretty painful as well.

Basically doing this would probably become a project instead of a 5
minute hack to support 80% of the functionality.  I understand the
desire to limit the number of hacks in the source code, though.
                -Seth Robertson                 in-pgsql-hackers@baka.org



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Some 8.4 changes needed according to pg_migrator testing
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Some 8.4 changes needed according to pg_migrator testing