From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Will Crawford <billcrawford1970(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Successor of MD5 authentication, let's use SCRAM |
Date: | 2012-10-23 06:49:52 |
Message-ID: | CAAZKuFbqQPs0jv9gPYZgrXbxoP-gG+Rd2jOh6F3UkuArduMcQQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 22, 2012 at 3:54 PM, Greg Stark <stark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Lars Kanis | 2012-10-23 08:09:40 | Failing SSL connection due to weird interaction with openssl |
Previous Message | Tom Lane | 2012-10-23 02:07:04 | Re: [Bug] SELECT INSTEAD with sub-query |