Re: what can go in root.crt ?

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

In response to

Responses

Browse pgsql-hackers by date

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