On Mon, Oct 22, 2012 at 3:54 PM, Greg Stark <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
