Re: what can go in root.crt ?

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: what can go in root.crt ?
Дата
Msg-id CAMsr+YFxY+ZwkteNAhZTB5mQrRTshMPBT6QrVxiZx1eR2hUO0g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: what can go in root.crt ?  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: what can go in root.crt ?  (Chapman Flack <chap@anastigmatix.net>)
Список pgsql-hackers
On Tue, 26 May 2020 at 11:43, Chapman Flack <chap@anastigmatix.net> wrote:
On 05/25/20 23:22, Laurenz Albe wrote:
> I don't know if there is a way to get this to work, but the
> fundamental problem seems that you have got the system wrong.
>
> If you don't trust WE ISSUE TO EVERYBODY, then you shouldn't use
> it as a certification authority.


Right. In fact you must not, because WE ISSUE TO EVERYBODY can issue a new certificate in the name of WE ISSUE TO ORGS LIKE YOURS.COM - right down to matching backdated signing date and fingerprint.

Then give it to WE ARE THE BAD GUYS.COM.

If you don't trust the root, you don't trust any of the intermediate branches.

The main reason to put intermediate certificates in the root.crt is that it allows PostgreSQL to supply the whole certificate chain to a client during the TLS handshake. That frees the clients from needing to have local copies of the intermediate certificates; they only have to know about WE ISSUE TO EVERYBODY.

If you wanted to require that your certs are signed by WE ISSUE TO ORGS LIKE YOURS.COM, you must configure your CLIENTS with a restricted root of trust that accepts only the intermediate certificate of WE ISSUE TO ORGS LIKE YOURS.COM . Assuming the client will accept it; not all clients allow you to configure "certificates I trust to sign peers" separately to "certificates that sign my trusted roots". Because really, in security terms that's nonsensical.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Trouble with hashagg spill I/O pattern and costing
Следующее
От: Guillaume Lelarge
Дата:
Сообщение: Re: Default gucs for EXPLAIN