Re: Successor of MD5 authentication, let's use SCRAM - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: Successor of MD5 authentication, let's use SCRAM
Date
Msg-id CAAZKuFbqQPs0jv9gPYZgrXbxoP-gG+Rd2jOh6F3UkuArduMcQQ@mail.gmail.com
Whole thread Raw
In response to Re: Successor of MD5 authentication, let's use SCRAM  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Mon, Oct 22, 2012 at 3:54 PM, Greg Stark <stark@mit.edu> wrote:
> We could go even further:
> INFO: Server identity "ACME Debian Machine" certified by "Snakeoil CA"
> WARNING: Server identity signed by unknown and untrusted authority "Snakeoil CA"
> HINT: Add either the server certificate or the CA certificate to
> "/usr/lib/ssl/certs" after verifying the identity and certificate hash
>
> SSL is notoriously hard to set up, it would go a long way to give the
> sysadmin an immediate pointer to what certificates are being used and
> where to find or install the CA certs. It might be worth mentioning
> the GUC parameter names to control these things too.

Are the possible locations of certs that libpq reads in always so
short and definitive?  Is it clear that the user would always want to
fix the cert situation in that way?  What if they don't have file
system access to the remote database and would like to learn its
public key anyway (ala SSH trust on first use).

Overall, I do very much like the sentiment: less guesswork around
where the heck to put things or what to search for in documentation.

-- 
fdr



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [Bug] SELECT INSTEAD with sub-query
Next
From: Lars Kanis
Date:
Subject: Failing SSL connection due to weird interaction with openssl