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
|
Список | 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 по дате отправления: