Skip site navigation (1) Skip section navigation (2)

Re: BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Date: 2010-05-22 04:01:23
Message-ID: 4BF75713.8000006@postnewspapers.com.au (view raw or flat)
Thread:
Lists: pgsql-bugs
On 21/05/2010 10:35 PM, Magnus Hagander wrote:
> On Fri, May 21, 2010 at 7:52 AM, Craig Ringer
> <craig(at)postnewspapers(dot)com(dot)au>  wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference:      5468
>> Logged by:          Craig Ringer
>> Email address:      craig(at)postnewspapers(dot)com(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Tom MolesworthDate: 2010-05-22 14:24:49
Subject: Re: psql or pgbouncer bug?
Previous:From: Nelson da Silva da SilvaDate: 2010-05-22 03:39:28
Subject: Ola

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group