Matt Bush <mattpbush@gmail.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