Re: [HACKERS] Possible SSL improvements for a newcomer to tackle - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: [HACKERS] Possible SSL improvements for a newcomer to tackle
Date
Msg-id CAMkU=1w8uiQn9_FOBSeBhmN57t7zgDO02a6ys7qQrwpxE=h9ww@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Possible SSL improvements for a newcomer to tackle  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Oct 3, 2017 at 6:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Oct 3, 2017 at 6:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not an SSL expert, so insert appropriate grain of salt, but AIUI the
>> question is what are you going to verify against?

> One way to do it would be to default to the "system global certificate
> store", which is what most other SSL apps do. For example on a typical
> debian/ubuntu, that'd be the store in /etc/ssl/certs/ca-certificates.crt.
> Exactly where to find them would be distribution-specific though, and we
> would need to actually add support for a second certificate store. But that
> would probably be a useful feature in itself.

Maybe.  The impression I have is that it's very common for installations
to use a locally-run CA to generate server and client certs.  I would not
expect them to put such certs into /etc/ssl/certs. 

Well, I would do it that way if it worked.  Not directly /etc/ssl/certs, but /etc/pki/ca-trust/source/anchors/

I would like the locally-run CA to able to sign not just postgresql server certs, but also apache server certs.  And then install the CA cert file in one place per client  and have it work for psql, curl, wget, etc.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [sqlsmith] crash in RestoreLibraryState duringlow-memory testing
Next
From: Jeff Janes
Date:
Subject: Re: [HACKERS] postgres_fdw super user checks