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