Re: BUG #17224: Postgres Yum repo mirror has expired SSL certificate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matt Bush <mattpbush(at)gmail(dot)com>
Cc: postgres(at)netlag(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17224: Postgres Yum repo mirror has expired SSL certificate
Date: 2021-10-12 16:54:00
Message-ID: 580887.1634057640@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Matt Bush <mattpbush(at)gmail(dot)com> writes:
> As mentioned, it's entirely intermittent. The playbook action immediately
> prior to the failing step is to verify that the installed ca-certificates
> us up-to-date, which it is:

> $ rpm -qa | grep ca-certificates
> ca-certificates-2021.2.50-72.el7_9.noarch

Okay, but what about your openssl version? (I'd think RHEL7 contains
something reasonably up-to-date, but I might be wrong.) It might be
worth logging the output of "curl -V".

The intermittency might be an artifact of consulting several different
mirrors, only some of which use Let's Encrypt certificates. (Although
I think all of *.postgresql.org do use those.)

You could also investigate by logging the output of

openssl s_client -connect download.postgresql.org:443 </dev/null

If there's a mirror rotation involved this wouldn't necessarily hit
the same server as curl does, though. Anyway I just tried that here,
on an up-to-date RHEL8 installation, and I get a pass on each of the
four IP addresses that we advertise for download.postgresql.org:

$ openssl s_client -connect 217.196.149.55:443 </dev/null
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = ftp.postgresql.org
verify return:1
---
Certificate chain
0 s:CN = ftp.postgresql.org
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
... blah, blah, blah ...
Verify return code: 0 (ok)
---
DONE

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-10-12 18:57:21 BUG #17225: Query with CTE failed after upgrade Postgres from 11 to 12/13
Previous Message Jed Walker 2021-10-12 16:47:34 Re[2]: v12.4 pg_dump .sql fails to load data via psql