Re: what can go in root.crt ?

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: what can go in root.crt ?
Date: 2020-06-03 12:07:30
Message-ID: CANwKhkP8Qdr1eajkrO8YkyRjRK8HSkwca9cTW=zVVs7eLsHvbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2 Jun 2020 at 20:14, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> The server certificate should be issued by a certificate authority root
> outside of your organization only if you want people outside of your
> organization to trust your server certificate, but you are then asking
> for the client to only trust an intermediate inside your organization.
> The big question is why bother having the server certificate chain to a
> root certificat you don't trust when you have no intention of having
> clients outside of your organization trust the server certificate.
> Postgres could be made to handle such cases, but is is really a valid
> configuration we should support?
>

I think the "why" the org cert is not root was already made clear, that is
the copmany policy. I don't think postgres should take a stance whether the
certificate designated as the root of trust is self-signed or claims to get
its power from somewhere else.

It's pretty easy to conceive of certificate management procedures that make
use of this chain to implement certificate replacement securely. For
example one might trust the global issuer to verify that a CSR is coming
from the O= value that it's claiming to come from to automate replacement
of intermediate certificates, but not trust that every other sub-CA signed
by root and their sub-sub-CA-s are completely honest and secure.

Regards,
Ants Aasma

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 李杰 (慎追) 2020-06-03 12:22:29 how to create index concurrently on paritioned table
Previous Message Dave Cramer 2020-06-03 11:33:14 Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762