Re: SSL and USER_CERT_FILE round 2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql(at)mohawksoft(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSL and USER_CERT_FILE round 2
Date: 2008-05-15 17:40:30
Message-ID: 482C758E.2020006@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

pgsql(at)mohawksoft(dot)com wrote:
>>
>> I think if you're going to provide for these then you should also
>> provide for the CA cert and CRL.
>>
>> Otherwise, it seems sensible.
>>
>
> I thought about that, but the root and crl are for the server, and that
> makes sense that the keys would be in the server directory. The server
> needs to protect its data against clients wishing to connect. The client
> on the other hand, needs to access one or more postgresql servers.
>
> It makes sense that the server keys and credentials be hard coded to its
> protected data directory, while the client needs the ability to have
> multiple keys.
>
> Think of it this way, a specific lock only takes one key while a person
> needs to carry multiple keys on a ring.
>

This is completely wrong. Why do you think your web browser has CA keys
embedded in it? So it can know which server keys to trust. As
documented, if a CA certificate set is present on the libpq client, the
client will only trust server keys signed with a chain starting from
that set.

CA certificates and CRLs can in general be used on both sides of an SSL
connection, and we make explicit provision for them on both sides.

See http://www.postgresql.org/docs/current/static/libpq-ssl.html

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message pgsql 2008-05-15 17:44:20 Re: SSL and USER_CERT_FILE
Previous Message Tom Lane 2008-05-15 16:09:31 Re: libpq object hooks