Thread: SSL and USER_CERT_FILE
I am using PostgreSQL's SSL support and the conventions for the key and
certifications don't make sense from the client perspective. Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{ user_crt_filename = strdup(filename);
}
PQsetSSLUserKeyFileName(char *filename)
{ user_key_filename = strdup(filename);
}
Adding two static vars in fe-secure.c
char *user_key_filename=NULL;
char *user_crt_filename=NULL;
In client_cert_cb(...)
Add:
if(user_crt_filename) strncpy(fnbuf, sizeof(fnbuf), user_crt_filename);
else snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_CERT_FILE);
and:
if(user_key_filename) strncpy(fnbuf, sizeof(fnbuf), user_key_filename);
else snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_KEY_FILE);
The purpose of these changes is to make it easier to configure SSL in an
application which uses libpq.
Any comments?
Mark Woodward wrote:
> I am using PostgreSQL's SSL support and the conventions for the key and
> certifications don't make sense from the client perspective. Especially
> under Windows.
>
> I am proposing a few simple changes:
>
> Adding two API
> void PQsetSSLUserCertFileName(char *filename)
> {
> user_crt_filename = strdup(filename);
> }
> PQsetSSLUserKeyFileName(char *filename)
> {
> user_key_filename = strdup(filename);
> }
>
>
>
[snip]
> Any comments?
>
>
I think it would probably be much better to allow for some environment
variables to specify the locations of the client certificate and key
(and the CA cert and CRL) - c.f. PGPASSFILE.
That way not only could these be set by C programs but by any libpq user
(I'm sure driver writers who use libpq don't want to have to bother with
this stuff.) And we wouldn't need to change the API at all.
cheers
andrew
> Mark Woodward wrote:
>> I am using PostgreSQL's SSL support and the conventions for the key and
>> certifications don't make sense from the client perspective. Especially
>> under Windows.
>>
>> I am proposing a few simple changes:
>>
>> Adding two API
>> void PQsetSSLUserCertFileName(char *filename)
>> {
>> user_crt_filename = strdup(filename);
>> }
>> PQsetSSLUserKeyFileName(char *filename)
>> {
>> user_key_filename = strdup(filename);
>> }
>>
>>
>>
> [snip]
>> Any comments?
>>
>>
>
>
> I think it would probably be much better to allow for some environment
> variables to specify the locations of the client certificate and key
> (and the CA cert and CRL) - c.f. PGPASSFILE.
>
> That way not only could these be set by C programs but by any libpq user
> (I'm sure driver writers who use libpq don't want to have to bother with
> this stuff.) And we wouldn't need to change the API at all.
>
The problem I have with environment variables is that they tend not to be
application specific and almost always lead to configuration issues. As a
methodology for default configuration, it adds flexibility. Also, the
current configuration does not easily take in to consideration the idea
that different databases with different keys can be used from the same
system the same user.
Maybe we need to go even further and add it to the PQconnect API
sslkey=filename and sslcrt=filename in addition to sslmode?
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
On May 15, 2008, at 6:31 AM, pgsql@mohawksoft.com wrote:
>> Mark Woodward wrote:
>>> I am using PostgreSQL's SSL support and the conventions for the
>>> key and
>>> certifications don't make sense from the client perspective.
>>> Especially
>>> under Windows.
>>>
>>> I am proposing a few simple changes:
>>>
>>> Adding two API
>>> void PQsetSSLUserCertFileName(char *filename)
>>> {
>>> user_crt_filename = strdup(filename);
>>> }
>>> PQsetSSLUserKeyFileName(char *filename)
>>> {
>>> user_key_filename = strdup(filename);
>>> }
>>>
>>>
>>>
>> [snip]
>>> Any comments?
>>>
>>>
>>
>>
>> I think it would probably be much better to allow for some
>> environment
>> variables to specify the locations of the client certificate and key
>> (and the CA cert and CRL) - c.f. PGPASSFILE.
>>
>> That way not only could these be set by C programs but by any libpq
>> user
>> (I'm sure driver writers who use libpq don't want to have to bother
>> with
>> this stuff.) And we wouldn't need to change the API at all.
>>
>
> The problem I have with environment variables is that they tend not
> to be
> application specific and almost always lead to configuration issues.
> As a
> methodology for default configuration, it adds flexibility. Also, the
> current configuration does not easily take in to consideration the
> idea
> that different databases with different keys can be used from the same
> system the same user.
Environment variables don't have to be set in your shell.
This would seem to give the same functionality you suggest above,
given support for environment variables:
void PQsetSSLUserCertFileName(char * filename)
{ setenv("PGCERTFILE", filename);
}
void PQsetSSLUserKeyFileName(char *filename)
{ setenv("PGKEYFILE", filename);
}
Or, in perl, $ENV{PGKEYFILE} = $file and so on. It seems
less intrusive than adding new API calls.
Cheers, Steve
> 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.
>
> On May 15, 2008, at 6:31 AM, pgsql@mohawksoft.com wrote:
>
>>> Mark Woodward wrote:
>>>> I am using PostgreSQL's SSL support and the conventions for the
>>>> key and
>>>> certifications don't make sense from the client perspective.
>>>> Especially
>>>> under Windows.
>>>>
>>>> I am proposing a few simple changes:
>>>>
>>>> Adding two API
>>>> void PQsetSSLUserCertFileName(char *filename)
>>>> {
>>>> user_crt_filename = strdup(filename);
>>>> }
>>>> PQsetSSLUserKeyFileName(char *filename)
>>>> {
>>>> user_key_filename = strdup(filename);
>>>> }
>>>>
>>>>
>>>>
>>> [snip]
>>>> Any comments?
>>>>
>>>>
>>>
>>>
>>> I think it would probably be much better to allow for some
>>> environment
>>> variables to specify the locations of the client certificate and key
>>> (and the CA cert and CRL) - c.f. PGPASSFILE.
>>>
>>> That way not only could these be set by C programs but by any libpq
>>> user
>>> (I'm sure driver writers who use libpq don't want to have to bother
>>> with
>>> this stuff.) And we wouldn't need to change the API at all.
>>>
>>
>> The problem I have with environment variables is that they tend not
>> to be
>> application specific and almost always lead to configuration issues.
>> As a
>> methodology for default configuration, it adds flexibility. Also, the
>> current configuration does not easily take in to consideration the
>> idea
>> that different databases with different keys can be used from the same
>> system the same user.
>
> Environment variables don't have to be set in your shell.
>
> This would seem to give the same functionality you suggest above,
> given support for environment variables:
>
> void PQsetSSLUserCertFileName(char * filename)
> {
> setenv("PGCERTFILE", filename);
> }
>
> void PQsetSSLUserKeyFileName(char *filename)
> {
> setenv("PGKEYFILE", filename);
> }
>
> Or, in perl, $ENV{PGKEYFILE} = $file and so on. It seems
> less intrusive than adding new API calls.
>
> Cheers,
> Steve
Doesn't it make sense that the connection be configured in one place? I
agree with Tom, if it should be done, it should be done in PQconnectdb.
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? //Magnus
> 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.