Re: [HACKERS] Possible SSL improvements for a newcomer to tackle

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] Possible SSL improvements for a newcomer to tackle
Дата
Msg-id CAMkU=1w8uiQn9_FOBSeBhmN57t7zgDO02a6ys7qQrwpxE=h9ww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Possible SSL improvements for a newcomer to tackle  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [sqlsmith] crash in RestoreLibraryState duringlow-memory testing
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: [HACKERS] postgres_fdw super user checks