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
Re: libpq should not be using SSL_CTX_set_client_cert_cb |
Список | 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 по дате отправления: