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
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 |