Re: SSL and USER_CERT_FILE - Mailing list pgsql-hackers

From pgsql@mohawksoft.com
Subject Re: SSL and USER_CERT_FILE
Date
Msg-id 56886.24.60.196.157.1210873460.squirrel@mail.mohawksoft.com
Whole thread Raw
In response to Re: SSL and USER_CERT_FILE  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
> pgsql@mohawksoft.com wrote:
>> > pgsql@mohawksoft.com writes:
>> >> Maybe we need to go even further and add it to the PQconnect API
>> >> sslkey=filename and sslcrt=filename in addition to sslmode?
>> >
>> > If there's a case to be made for this at all, it should be handled
>> > the same way as all other libpq connection parameters.
>> >
>> >             regards, tom lane
>> >
>>
>> Here's the use case:
>>
>> I have an application that must connect to multiple PostgreSQL
>> databases and must use secure communications and the SSL keys are
>> under the control of the business units the administer the databases,
>> not me. In addition my application also communicates with other SSL
>> enabled versions of itself.
>>
>> I think you would agree that a hard coded immutable location for
>> "client" interface is problematic.
>
> I agree fully with the use-case. Most of the other things we allow both
> as connection parameters and as environment variables, so we should do
> that IMHO. What could be debated is if we should also somehow allow it
> to be specified in .pgpass for example?
>


I am testing a patch that is currently against the 8.2 series.

It implements in PQconnectdb(...)

sslmode=require sslkey=client.key sslcert=client.crt ssltrustcrt=certs.pem
sslcrl=crl.pem"

BTW: the revocation list probably never worked in the client.


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: SSL and USER_CERT_FILE
Next
From: Alvaro Herrera
Date:
Subject: Re: Bug 3883 revisited