Can't contact EAH Servers - Peer Certificate Cannot be Authenticated...
24 Jan 2016 7:01:30 UTC
Topic 198389
(moderation:
I am running Debian Jessy on a Raspberry Pi Zero (actually, on 3). After performing an apt-get update/upgrade, BOINC is no longer able to get work unites from EAH. In stdoutdae, I'm getting the following:
24-Jan-2016 01:25:09 [http://einstein.phys.uwm.edu/] update requested by user
24-Jan-2016 01:25:13 [http://einstein.phys.uwm.edu/] Sending scheduler request: Requested by user.
24-Jan-2016 01:25:13 [http://einstein.phys.uwm.edu/] Requesting new tasks for CPU
24-Jan-2016 01:25:16 [---] Project communication failed: attempting access to reference site
24-Jan-2016 01:25:16 [http://einstein.phys.uwm.edu/] Scheduler request failed: Peer certificate cannot be authenticated with given CA certificates
24-Jan-2016 01:25:19 [---] Internet access OK - project servers may be temporarily down.
Any thoughts? Googling and following instructions hasn't helped much.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
Can't contact EAH Servers - Peer Certificate Cannot be Authentic
)
A quick google suggests that either the root certificates are old or your machine have an incorrect date/time.
https://stackoverflow.com/questions/14566864/peer-certificate-cannot-be-authenticated-with-known-ca-certificates-using-php-oa
What BOINC version are you
)
What BOINC version are you using? Do you have a recent version of the ca-certificates package installed? We have seen this problem on Windows but not Linux before. Your local certificate store should have the correct CA root certificate for the scheduler server.
If you could also check your client_state.xml and post the content of the tag would be helpful.
The issue seems to be
)
The issue seems to be resolved by now, the OP is getting new work. Just for information, yesterday's Debian update included this:
Update Mozilla certificate authority bundle to version 2.6.
The following certificate authorities were added (+):
+ "CA WoSign ECC Root"
+ "Certification Authority of WoSign G2"
+ "Certinomis - Root CA"
+ "CFCA EV ROOT"
+ "COMODO RSA Certification Authority"
+ "Entrust Root Certification Authority - EC1"
+ "Entrust Root Certification Authority - G2"
+ "GlobalSign ECC Root CA - R4"
+ "GlobalSign ECC Root CA - R5"
+ "IdenTrust Commercial Root CA 1"
+ "IdenTrust Public Sector Root CA 1"
+ "OISTE WISeKey Global Root GB CA"
+ "S-TRUST Universal Root CA"
+ "Staat der Nederlanden EV Root CA"
+ "Staat der Nederlanden Root CA - G3"
+ "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
+ "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H6"
+ "USERTrust ECC Certification Authority"
+ "USERTrust RSA Certification Authority"
The following certificate authorities were removed (-):
- "A-Trust-nQual-03"
- "America Online Root Certification Authority 1"
- "America Online Root Certification Authority 2"
- "Buypass Class 3 CA 1"
- "ComSign Secured CA"
- "Digital Signature Trust Co. Global CA 1"
- "Digital Signature Trust Co. Global CA 3"
- "E-Guven Kok Elektronik Sertifika Hizmet Saglayicisi"
- "GTE CyberTrust Global Root"
- "SG TRUST SERVICES RACINE"
- "TC TrustCenter Class 2 CA II"
- "TC TrustCenter Universal CA I"
- "Thawte Premium Server CA"
- "Thawte Server CA"
- "TURKTRUST Certificate Services Provider Root 1"
- "TURKTRUST Certificate Services Provider Root 2"
- "UTN DATACorp SGC Root CA"
- "Verisign Class 4 Public Primary Certification Authority - G3"
WFM, but since this was a major update I didn't try it without a full system restart.
RE: The issue seems to be
)
I am receiving new work for all of my machines that did not apt-get upgrade yesterday, which is all of them but the one I posted about, whose hostname is rpi0-2. I verified that still this morning it is unable to pick up work, and yes I did complete a full reboot. At this point, I'm going to clone one of my working nodes and try.
When looking at a node that is working (rpi0-1), I see this.
~ $ sudo apt-cache policy ca-certificates ca-certificates: Installed: 20141019 Candidate: 20141019+deb8u1 Version table: 20141019+deb8u1 0 500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages *** 20141019 0 100 /var/lib/dpkg/statusI tried to downgrade this package last night back to 20141019 but apt-get told me that it wasn't a valid version.
In case it matters later, here's a list of all the packages that upgrade prior to this breaking.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: What BOINC version are
)
I am running 7.4.23, stock for Jessie on Raspbian.
client_state.xml
-18000
rpi0-2
127.0.1.1
6a4aacd36119a3ced32fa3bc7a4da961
1
ARM
half thumb fastmult vfp edsp java tls
353892821.031345
1401486253.567291
1000000000.000000
1453070125.106205
0
505491456.000000
-1.000000
104853504.000000
7751233536.000000
6201909248.000000
Linux
4.4.0+
0.999671
-1.000000
1.000000
1.000000
1.000000
1453641195.664715
1453069599.928925
32241.931678
32211.588129
32211.588129
643.490090
1453641833.081963
11140.909648
962574547.265178
1453070137.439982
860365.444092
14798148258.645075
1453639867.128197
http://einstein.phys.uwm.edu/
0.000000
0.000000
0.000000
0.000000
1
0
0
0
0.000000
0.000000
0.000000
2
2
1453642068.202916
0.000000
0.000000
0.000000
100.000000
0.000000
1.000000
0
0
0
0
0
0.000000
CPU
0.000000
CPU
0.000000
https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
arm-unknown-linux-gnueabihf
7
4
23
2
2
2
2
2
0.000000
1453069603.342144
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: A quick google suggests
)
Thanks - my googling also turned up both topics. My time matches the real time (the same as all of my other units). I suspect it was the installation of a new ssl package or ca-certificates with apt-get that is the problem.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
The ca-certificates update
)
The ca-certificates update did not remove necessary root certificates. Or else I would have seen this on Stretch already. Can you try to connect to the scheduler from the rpi0-2 via browser and curl/wget? For me this looks like:
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home
This is the correct error to be returned in both cases. If there is a problem with the certificate curl should tell you. For wget you have to remove the -quiet I think. There is an option for curl to output more information about the certificates used. We can try this next on a working rpi0 and the non-working one. I really would like to know what's happening here.
Christian In an effort to
)
Christian
In an effort to try to move past the issue, I have since cloned the image of rpi0-1 and have rewritten it to my card. I then did a --project reset to get a new work unit. I am now waiting on apt-get upgrade to complete so that I can retry the reset again. At that point, I should be at the same point as my last rpi0-2 image.
I will also try curl and wget (these machines are headless/running jessie-lite) so I won't be able to try in a browser.
One more piece of information - I am running rpi0-1-rpi0-n as usb ethernet gadgets configured in a bridge on rpi0-0, the main controller, plugged into a powered 7 port USB2 hub. In theory, this shouldn't matter, but thought I would share.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: The ca-certificates
)
So I just realized that I had updated rpi0-0 yesterday. Running curl, I get the following:
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Running wget seems to work:
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home
And after doing a --project reset, I now get the Peer certificate cannot be authenticated with given CA certificates error again...
I would have moved to stretch, but I read that an upgrade to libc had broken EAH all together for the moment.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
$ curl
)
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
begin EDIT
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home
end EDIT
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home
But
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home