On 21/05/2010 10:35 PM, Magnus Hagander wrote:
On Fri, May 21, 2010 at 7:52 AM, Craig Ringer
<cr...@postnewspapers.com.au>  wrote:

The following bug has been logged online:

Bug reference:      5468
Logged by:          Craig Ringer
Email address:      cr...@postnewspapers.com.au
PostgreSQL version: 8.4
Operating system:   Ubuntu 10.04, but affects all
Description:        Pg doesn't send accepted root CA list to client during
SSL client cert request
Details:

This is actually not a bug, but a documented way how it's done. It's
actually even on the TODO to get it fixed, referencing bug #5245 -
from what I can tell that's what you're talking about, except we need
to send it in both directions?

Bug 5245 is not the same issue. They're talking about the server not sending the full certificate chain for the cert that identifies the server (server.crt). It's nothing to do with client certificates. Without the full chain, the client can't verify the server unless it happens to already have the intermediate certs between the server's cert and the trusted root that signed it installed locally. I haven't encountered #5245 myself, but will test it shortly to verify. It'd certainly count as a significant bug, as it would make it impossible to use indirect trust to verify a server (as is the case when a corporate CA signed by a "big name" CA is in use).

What I'm talking about is the server not sending the set of certificates trusted as client certificate signers (root.crt) to the client when it sends a CertificateRequest to demand a client certificate from the client. Without that, the client doesn't know which client certificate to present to the server in response to the CertificateRequest.

They're somewhat related, but a fix to one won't affect a fix to the other.

Yeah, all our (at least my) testing is done on OpenSSL - I had no idea
of this behaviour of the java layer really.

You would have the same issue with a client using the Mozilla NSS libraries - but I'm not aware of any that do. Essentially, the only reason OpenSSL works is because typical setups only have one client certificate availible so they'll blindly present it without knowing or caring what the server accepts.

Unfortunately, I don't think this is something we can fix as a bugfix
- it'll be a pretty clear change of behaviour, so I think it's
something we will need to push back for a full release, which would
mean 9.1.

Urk. I think you're right, but I don't like it :S

I'm working on testing a patch that gets Pg to present all trusted roots to the client now, and will send it in as a starting point once I've tested it with the clients I have on hand - PgJDBC, libpq, etc.

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to