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
On Friday 30 August 2019 12:03:26 Alexander Dalloz wrote:> You are welcome Gary. And I am curious about what the cause of your repo > troubles is.I have looked back over what I have done, and cannot see what has caused the problem to occurr. I do not see anywhere where it could have been from any action that I have taken, including deleting the contents of the yum cache.> 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.I have done both of these steps and got the same results as you. This may be because I have already re-installed ca-certificates as Tony's suggestion. The main thing is that the server now has a working yum once again, but it wouls have been nice to find out the original cause. Once again, thanks to everyone for you assistance. I found it very educational.
On Fri, Aug 30, 2019 at 12:17:47PM +0100, Gary Stainburn wrote:> On Friday 30 August 2019 12:03:26 Alexander Dalloz wrote: > > > > Besides a corrupted certificates bundle I cannot imagine a different > > root cause actually.Just to mention that the 'etckeeper' package from EPEL is great for tracking changes to /etc. Package installs trigger a commit, as do a daily cron job. If in this case it was a corrupt file in /etc/pki, then a 'git log' or similar could show when it happened. Although I think you tried 'rpm -V' already so perhaps it wasn't a corrupt cert file. Paddy -- Paddy Doyle Research IT / Trinity Centre for High Performance Computing, Lloyd Building, Trinity College Dublin, Dublin 2, Ireland. Phone: +353-1-896-3725 https://www.tchpc.tcd.ie/