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.
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?
Import Notes
Reply to msg id not found: 482C401D.6030808@dunslane.net
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.
Import Notes
Reply to msg id not found: 4097.1210860772@sss.pgh.pa.us
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
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.
Import Notes
Reply to msg id not found: 039E3266-CEFC-4E25-9B66-DB42D723DFF7@blighty.com
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 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.
Import Notes
Reply to msg id not found: 20080515201033.20a83789@mha-laptop.hagander.net
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