Adding "sslkey" and "sslcert" to the PQconnectdb connection string.

After some discussion, I think it is more appropriate to add the key/cert
file for SSL into the connect string. For example:

PQconnectdb("host=foo dbname=bar sslmode=require
sslkey=/opt/myapp/share/keys/client.key
sslcert=/opt/myapp/share/keys/client.crt");


Any comments?




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

pgsql@mohawksoft.com wrote:
> Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
>
> After some discussion, I think it is more appropriate to add the key/cert
> file for SSL into the connect string. For example:
>
> PQconnectdb("host=foo dbname=bar sslmode=require
> sslkey=/opt/myapp/share/keys/client.key
> sslcert=/opt/myapp/share/keys/client.crt");
>
>
> Any comments?
>
>

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.

cheers

andrew

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

>
>
> pgsql@mohawksoft.com wrote:
>> Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
>>
>> After some discussion, I think it is more appropriate to add the
>> key/cert
>> file for SSL into the connect string. For example:
>>
>> PQconnectdb("host=foo dbname=bar sslmode=require
>> sslkey=/opt/myapp/share/keys/client.key
>> sslcert=/opt/myapp/share/keys/client.crt");
>>
>>
>> Any comments?
>>
>>
>
> 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.

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

pgsql@mohawksoft.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/curre...libpq-ssl.html

cheers

andrew

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