Am 2019-08-29 18:26, schrieb Gary Stainburn:> On Thursday 29 August 2019 16:47:11 Alexander Dalloz wrote: >> rpm -Vv nss > > [root at stan2 ~]# rpm -Vv nss > ......... /etc/pki/nss-legacy > ......... c /etc/pki/nss-legacy/nss-rhel7.config > ......... /etc/pki/nssdb > ......... c /etc/pki/nssdb/cert8.db > ......... c /etc/pki/nssdb/cert9.db > ......... c /etc/pki/nssdb/key3.db > ......... c /etc/pki/nssdb/key4.db > ......... c /etc/pki/nssdb/pkcs11.txt > ......... c /etc/pki/nssdb/secmod.db > ......... /usr/lib64/libnss3.so > ......... g /usr/lib64/libnssckbi.so > ......... /usr/lib64/libsmime3.so > ......... /usr/lib64/libssl3.so > ......... /usr/lib64/nss/libnssckbi.so > ......... d /usr/share/man/man5/cert8.db.5.gz > ......... d /usr/share/man/man5/cert9.db.5.gz > ......... d /usr/share/man/man5/key3.db.5.gz > ......... d /usr/share/man/man5/key4.db.5.gz > ......... d /usr/share/man/man5/pkcs11.txt.5.gz > ......... d /usr/share/man/man5/secmod.db.5.gzOk, that package content looks healthy. No problem there.> [root at stan2 ~]# URLGRABBER_DEBUG=1 yum --disablerepo=\* > --enablerepo=epel update > [snip] > Loading mirror speeds from cached hostfile > 2019-08-29 17:23:17,344 combined options: { > 'text' : 'epel/x86_64/metalink',[ ... ]> 2019-08-29 17:23:17,344 attempt 1/10: > https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 > 2019-08-29 17:23:17,345 opening local file > "/var/cache/yum/x86_64/7/epel/metalink.xml.tmp" with mode wb > * About to connect() to mirrors.fedoraproject.org port 443 (#29) > * Trying 8.43.85.67... > * Connected to mirrors.fedoraproject.org (8.43.85.67) port 443 (#29) > * Initializing NSS with certpath: sql:/etc/pki/nssdb > * CAfile: /etc/pki/tls/certs/ca-bundle.crt > CApath: none > * Server certificate: > * subject: CN=*.fedoraproject.org,O=Red Hat Inc.,L=Raleigh,ST=North > Carolina,C=US > * start date: Feb 01 00:00:00 2017 GMT > * expire date: May 01 12:00:00 2020 GMT > * common name: *.fedoraproject.org > * issuer: CN=DigiCert SHA2 High Assurance Server > CA,OU=www.digicert.com,O=DigiCert Inc,C=US > * NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER) > * Peer's Certificate issuer is not recognized.So here we are. While the current ca-certificates package of CentOS 7 ca-certificates-2018.2.22-70.0.el7_5.noarch does not hold the intermediate certificate "DigiCert SHA2 High Assurance Server" I don't get that issue. # grep "DigiCert" /etc/pki/tls/certs/ca-bundle.crt # DigiCert Assured ID Root CA # DigiCert Assured ID Root G2 # DigiCert Assured ID Root G3 # DigiCert Global Root CA # DigiCert Global Root G2 # DigiCert Global Root G3 # DigiCert High Assurance EV Root CA # DigiCert Trusted Root G4> * Closing connection 29 > 2019-08-29 17:23:18,117 exception: [Errno 14] curl#60 - "Peer's > Certificate issuer is not recognized." > 2019-08-29 17:23:18,117 retrycode (14) not in list [-1, 2, 4, 5, 6, > 7], re-raising[ ... ]> Cannot retrieve metalink for repository: epel/x86_64. Please verify > its path and try againSo can we check what version of the ca-certificates packages is being installed on your system? And a check into a different direction: what's the date and time of that system? Does it fit or is it wrong? Time being not accurate can make SSL connections fail. Alexander
On Thursday 29 August 2019 18:10:19 Alexander Dalloz wrote:> > 2019-08-29 17:23:18,117 exception: [Errno 14] curl#60 - "Peer's > > Certificate issuer is not recognized." > > 2019-08-29 17:23:18,117 retrycode (14) not in list [-1, 2, 4, 5, 6, > > 7], re-raising > > [ ... ] > > > Cannot retrieve metalink for repository: epel/x86_64. Please verify > > its path and try again > > So can we check what version of the ca-certificates packages is being > installed on your system? > > And a check into a different direction: what's the date and time of that > system? Does it fit or is it wrong? Time being not accurate can make SSL > connections fail.Firstly, thank you for you help with this Alexander. I had already checked the system time. It was about 3 minutes out, but I fixed it anyway. I have checked the RPM for the certificates, and it matches the one on another box that works. [root at stan2 ~]# date Fri 30 Aug 09:45:27 BST 2019 [root at stan2 ~]# rpm -qa|grep cert ca-certificates-2018.2.22-70.0.el7_5.noarch [root at stan2 ~]#
In article <201908300952.37126.gary.stainburn at ringways.co.uk>, Gary Stainburn <gary.stainburn at ringways.co.uk> wrote:> On Thursday 29 August 2019 18:10:19 Alexander Dalloz wrote: > > > 2019-08-29 17:23:18,117 exception: [Errno 14] curl#60 - "Peer's > > > Certificate issuer is not recognized." > > > 2019-08-29 17:23:18,117 retrycode (14) not in list [-1, 2, 4, 5, 6, > > > 7], re-raising > > > > [ ... ] > > > > > Cannot retrieve metalink for repository: epel/x86_64. Please verify > > > its path and try again > > > > So can we check what version of the ca-certificates packages is being > > installed on your system? > > > > And a check into a different direction: what's the date and time of that > > system? Does it fit or is it wrong? Time being not accurate can make SSL > > connections fail. > > Firstly, thank you for you help with this Alexander. > > I had already checked the system time. It was about 3 minutes out, but I fixed it anyway. I have checked the RPM for > the certificates, and it matches the one on another box that works. > > > [root at stan2 ~]# date > Fri 30 Aug 09:45:27 BST 2019 > [root at stan2 ~]# rpm -qa|grep cert > ca-certificates-2018.2.22-70.0.el7_5.noarch > [root at stan2 ~]#Can you verify the ca-certificates package on both your systems and compare? Here is what my C7 box shows (same version package as yours): [root at hp3 ~]# rpm -Vv ca-certificates ......... /etc/pki/ca-trust ......... /etc/pki/ca-trust/README ......... c /etc/pki/ca-trust/ca-legacy.conf ......... /etc/pki/ca-trust/extracted ......... /etc/pki/ca-trust/extracted/README ......... /etc/pki/ca-trust/extracted/java ......... /etc/pki/ca-trust/extracted/java/README .M....... g /etc/pki/ca-trust/extracted/java/cacerts ......... /etc/pki/ca-trust/extracted/openssl ......... /etc/pki/ca-trust/extracted/openssl/README .M....... g /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ......... /etc/pki/ca-trust/extracted/pem ......... /etc/pki/ca-trust/extracted/pem/README .M....... g /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem .M....... g /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem .M....... g /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem ......... /etc/pki/ca-trust/source ......... /etc/pki/ca-trust/source/README ......... /etc/pki/ca-trust/source/anchors ......... /etc/pki/ca-trust/source/blacklist ......... g /etc/pki/ca-trust/source/ca-bundle.legacy.crt ......... /etc/pki/java ......... /etc/pki/java/cacerts ......... /etc/pki/tls ......... /etc/pki/tls/cert.pem ......... /etc/pki/tls/certs ......... /etc/pki/tls/certs/ca-bundle.crt ......... /etc/pki/tls/certs/ca-bundle.trust.crt ......... /etc/ssl ......... /etc/ssl/certs ......... /usr/bin/ca-legacy ......... /usr/bin/update-ca-trust ......... d /usr/share/doc/ca-certificates-2018.2.22/README ......... d /usr/share/man/man8/ca-legacy.8.gz ......... d /usr/share/man/man8/update-ca-trust.8.gz ......... /usr/share/pki ......... /usr/share/pki/ca-trust-legacy ......... /usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt ......... /usr/share/pki/ca-trust-legacy/ca-bundle.legacy.disable.crt ......... /usr/share/pki/ca-trust-source ......... /usr/share/pki/ca-trust-source/README ......... /usr/share/pki/ca-trust-source/anchors ......... /usr/share/pki/ca-trust-source/blacklist ......... /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit [root at hp3 ~]# And you could try re-installing ca-certificates on the offending box. # yum --disablerepo=\* --enablerepo=base --enablerepo=updates reinstall ca-certificates Cheers Tony -- Tony Mountifield Work: tony at softins.co.uk - http://www.softins.co.uk Play: tony at mountifield.org - http://tony.mountifield.org
Am 2019-08-30 10:52, schrieb Gary Stainburn:> On Thursday 29 August 2019 18:10:19 Alexander Dalloz wrote: >> > 2019-08-29 17:23:18,117 exception: [Errno 14] curl#60 - "Peer's >> > Certificate issuer is not recognized." >> > 2019-08-29 17:23:18,117 retrycode (14) not in list [-1, 2, 4, 5, 6, >> > 7], re-raising >> >> [ ... ] >> >> > Cannot retrieve metalink for repository: epel/x86_64. Please verify >> > its path and try again >> >> So can we check what version of the ca-certificates packages is being >> installed on your system? >> >> And a check into a different direction: what's the date and time of >> that >> system? Does it fit or is it wrong? Time being not accurate can make >> SSL >> connections fail. > > Firstly, thank you for you help with this Alexander.You are welcome Gary. And I am curious about what the cause of your repo troubles is.> I had already checked the system time. It was about 3 minutes out, but > I fixed it anyway. I have checked the RPM for the certificates, and > it matches the one on another box that works. > > > [root at stan2 ~]# date > Fri 30 Aug 09:45:27 BST 2019 > [root at stan2 ~]# rpm -qa|grep cert > ca-certificates-2018.2.22-70.0.el7_5.noarch > [root at stan2 ~]#That's good. Now please verify that the ca-certificates RPM is healthy: rpm -V ca-certificates In addition you can grep for the DigiCert certificates which are used by the fedoraproject.org mirror servers for EPEL (concentrating on a single broken HTTPS repo for now): # grep "DigiCert" /etc/pki/tls/certs/ca-bundle.crt # DigiCert Assured ID Root CA # DigiCert Assured ID Root G2 # DigiCert Assured ID Root G3 # DigiCert Global Root CA # DigiCert Global Root G2 # DigiCert Global Root G3 # DigiCert High Assurance EV Root CA <<- that one must be there # DigiCert Trusted Root G4 Besides a corrupted certificates bundle I cannot imagine a different root cause actually. Of course you could search system-wide for broken RPM content: # for RPM in $(rpm -qa); do rpm -V ${RPM} >/dev/null; if [ "$?" -eq 1 ]; then echo "----- ${RPM} -----"; rpm -V ${RPM}; fi; done Regards, Alexander