libpq should not be using SSL_CTX_set_client_cert_cb

Поиск
Список
Период
Сортировка
От Tom Lane
Тема libpq should not be using SSL_CTX_set_client_cert_cb
Дата
Msg-id 3456.1274840947@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>)
Список pgsql-hackers
I've been experimenting with SSL setups involving chains of CA
certificates, ie, where the server or client cert itself is signed by
an intermediate CA rather than a trusted root CA.  This appears to work
well enough on the server side if you configure the server correctly
(see discussion of bug #5468).  However, libpq is not able to work with
a client certificate unless that cert is directly signed by a CA that
the server trusts (ie, one listed directly in the server's root.crt file).
This is because there is no good way to feed back any intermediate CA
certs to the server.  The man page for SSL_CTX_set_client_cert_cb says
in so many words that the client_cert_cb API is maldesigned:
BUGS
The client_cert_cb() cannot return a complete certificate chain,it can only return one client certificate. If the chain
onlyhasa length of 2, the root CA certificate may be omitted accordingto the TLS standard and thus a standard
conforminganswer can besent to the server. For a longer chain, the client must send thecomplete chain (with the option
toleave out the root CAcertificate). This can only be accomplished by either adding theintermediate CA certificates
intothe trusted certificate storefor the SSL_CTX object (resulting in having to add CAcertificates that otherwise maybe
wouldnot be trusted), or byadding the chain certificates using theSSL_CTX_add_extra_chain_cert(3) function, which is
onlyavailablefor the SSL_CTX object as a whole and that thereforeprobably can only apply for one client certificate,
makingtheconcept of the callback function (to allow the choice fromseveral certificates) questionable.
 

It strikes me that we could not only fix this case, but make the libpq
code simpler and more like the backend case, if we got rid of
client_cert_cb and instead preloaded the ~/.postgresql/postgresql.crt
file using SSL_CTX_use_certificate_chain_file().  Then, using an
indirectly signed client cert would only require including the full cert
chain in that file.

So I'm wondering if there was any specific reason behind using the
callback API to start with.  Anybody remember?
        regards, tom lane


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

Предыдущее
От: Takahiro Itagaki
Дата:
Сообщение: Open Item: invalid declspec for PG_MODULE_MAGIC
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: Exposing the Xact commit order to the user