On Tue, May 25, 2010 at 10:29:07PM -0400, Tom Lane wrote:
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
Garick Hamlin gham...@isc.upenn.edu writes:
I am guessing the problem is that validating the presented chain is hard?
No, the problem is that the current libpq code fails to present the
chain at all. It will only load and send the first cert in the
postgresql.crt file. This works only when
On Wed, May 26, 2010 at 10:54:42AM -0400, Tom Lane wrote:
Garick Hamlin gham...@isc.upenn.edu writes:
I am guessing the problem is that validating the presented chain is hard?
No, the problem is that the current libpq code fails to present the
chain at all. It will only load and send the
Garick Hamlin gham...@isc.upenn.edu 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
I wrote:
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().
Just for the archives: I've
On 27/05/10 10:21, Tom Lane wrote:
What will happen as things stand is that all the certs get loaded
into a common pool. That's not too horrible as long as there are
not actual conflicts, but it could mean that for example some
connections trust CA certs that the app programmer expected to
Craig Ringer cr...@postnewspapers.com.au writes:
On 27/05/10 10:21, Tom Lane wrote:
What will happen as things stand is that all the certs get loaded
into a common pool. That's not too horrible as long as there are
not actual conflicts, but it could mean that for example some
connections
