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
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 |