From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net>, Ants Aasma <ants(at)cybertec(dot)at>, Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: what can go in root.crt ? |
Date: | 2020-06-04 21:31:41 |
Message-ID: | 019045cb-108e-e0ef-7a1e-fc08738d88f5@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/3/20 7:57 PM, Chapman Flack wrote:
>
> In an ideal world, I think libpq would be using this algorithm:
>
> I'm looking at the server's certificate, s.
> Is s unexpired and in the trust file? If so, SUCCEED.
>
> otherwise, loop:
> get issuer certificate i from s (if s is self-signed, FAIL).
> does i have CA:TRUE and Certificate Sign bits? If not, FAIL.
> does i's Domain Constraint allow it to sign s? If not, FAIL.
> is i unexpired, or has s a Signed Certificate Timestamp made
> while i was unexpired? If not, FAIL.
> is i in the trust file? If so, SUCCEED.
> s := i, continue.
>
> (I left out steps like verify signature, check revocation, etc.)
>
> What it seems to be doing, though, is just:
>
> I'm looking at s
> Follow chain all the way to a self-signed cert
> is that in the file?
>
> which seems too simplistic.
>
Do we actually do any of this sort of thing? I confess my impression was
this is all handled by the openssl libraries, we just hand over the
certs and let openssl do its thing. Am I misinformed about that?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2020-06-04 21:39:47 | Re: what can go in root.crt ? |
Previous Message | Alvaro Herrera | 2020-06-04 21:20:57 | Re: repeat() function, CHECK_FOR_INTERRUPTS(), and unlikely() |