Re: what can go in root.crt ?

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: what can go in root.crt ?
Date: 2020-05-26 06:05:17
Message-ID: CAMsr+YFxY+ZwkteNAhZTB5mQrRTshMPBT6QrVxiZx1eR2hUO0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 26 May 2020 at 11:43, Chapman Flack <chap(at)anastigmatix(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2020-05-26 06:15:00 Re: Default gucs for EXPLAIN
Previous Message Thomas Munro 2020-05-26 05:02:41 Re: Trouble with hashagg spill I/O pattern and costing