On 12/02/2013 02:32 PM, Tom Lane wrote:
> Ian Pilcher <arequip...@gmail.com> writes:
>> I'm not sure what you're asking.  The desired behavior (IMO) would be to
>> accept client certificates signed by some intermediate CAs without
>> accepting any client certificate that can present a chain back to the
>> trusted root.  This is currently not possible, mainly due to the way
>> that OpenSSL works.
> 
> That notion seems pretty bogus to me.  If you don't trust the root CA to
> not hand out child CA certs to untrustworthy people, then you don't really
> trust the root CA, do you?  You should just list the certs of the
> intermediate CAs you *do* trust in the server's root.crt.

Assume you have a corporate policy that says that all SSL certificates
must be signed for the corporate root CA, which is an intermediate CA
signed by Verisign.  Presumably this means that you (or someone in your
organization) trusts Verisign to exercise some degree of care in issuing
their certificates, but that's a long way from wanting to allow every
Verisign-signed (or "rooted") certificate to connect to your database
server.

BTW, you can't just "list the certs of the intermediate CAs you do
trust"; you have to put the root CA certificate into root.crt in order
for OpenSSL to build a complete chain, and this means trusting *every*
client certificate that can present a chain back to that root.  That is
the problem.

> In any case, the idea that this is somehow OpenSSL's fault and another
> implementation of the same protocol wouldn't have the same issue sounds
> pretty silly.

Actually other implementations do this.  In fact, a flag was added to
OpenSSL fairly recently to allow validating a chain only up to an
intermediate CA for this very reason.

-- 
========================================================================
Ian Pilcher                                         arequip...@gmail.com
           Sent from the cloud -- where it's already tomorrow
========================================================================


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

Reply via email to