Re: what can go in root.crt ? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: what can go in root.crt ?
Date
Msg-id CAMsr+YFxY+ZwkteNAhZTB5mQrRTshMPBT6QrVxiZx1eR2hUO0g@mail.gmail.com
Whole thread Raw
In response to Re: what can go in root.crt ?  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: what can go in root.crt ?
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Trouble with hashagg spill I/O pattern and costing
Next
From: Guillaume Lelarge
Date:
Subject: Re: Default gucs for EXPLAIN