Craig Ringer 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 trust CA certs that th
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 only
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 a
Garick Hamlin 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 point...
I'm inclin
On Wed, May 26, 2010 at 10:54:42AM -0400, Tom Lane wrote:
> Garick Hamlin 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 t
Garick Hamlin 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 the client's cert is s
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 si
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 #5