Can't contact EAH Servers - Peer Certificate Cannot be Authenticated...

KF7IJZ
KF7IJZ
Joined: 27 Feb 15
Posts: 110
Credit: 6,108,311
RAC: 0
Topic 198389

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

Logforme
Logforme
Joined: 13 Aug 10
Posts: 332
Credit: 1,714,373,961
RAC: 0

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

Christian Beer
Christian Beer
Moderator
Joined: 9 Feb 05
Posts: 595
Credit: 100,068,514
RAC: 4,124

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.

floyd
floyd
Joined: 12 Sep 11
Posts: 133
Credit: 186,610,495
RAC: 0

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:

ca-certificates (20141019+deb8u1) stable; urgency=medium

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.

KF7IJZ
KF7IJZ
Joined: 27 Feb 15
Posts: 110
Credit: 6,108,311
RAC: 0

RE: The issue seems to be

Quote:
The issue seems to be resolved by now, the OP is getting new work.

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

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

Start-Date: 2016-01-24  00:21:09
Commandline: apt-get upgrade
Upgrade: tzdata:armhf (2015f-0+deb8u1, 2015g-0+deb8u1), apt:armhf (1.0.9.8.1, 1.0.9.8.2), libirs-export91:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), libpam-modules-bin:armhf (1.1.8-3.1, 1.1.8-3.1+deb8u1), libpam-modules:armhf (1.1.8-3.1, 1.1.8-3.1+deb8u1), libdns-export100:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), libmagic1:armhf (5.22+15-2, 5.22+15-2+deb8u1), libisccc90:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), file:armhf (5.22+15-2, 5.22+15-2+deb8u1), libisc-export95:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), libpcre3:armhf (8.35-3.3, 8.35-3.3+deb8u2), libisc95:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), libapt-pkg4.12:armhf (1.0.9.8.1, 1.0.9.8.2), libbind9-90:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), libdns100:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), liblwres90:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), apt-utils:armhf (1.0.9.8.1, 1.0.9.8.2), libapt-inst1.5:armhf (1.0.9.8.1, 1.0.9.8.2), libpam0g:armhf (1.1.8-3.1, 1.1.8-3.1+deb8u1), libisccfg90:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), bind9-host:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), libisccfg-export90:armhf (9.9.5.dfsg-9+deb8u4, 9.9.5.dfsg-9+deb8u5), ca-certificates:armhf (20141019, 20141019+deb8u1), libpam-runtime:armhf (1.1.8-3.1, 1.1.8-3.1+deb8u1)
End-Date: 2016-01-24  00:27:24

My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ

KF7IJZ
KF7IJZ
Joined: 27 Feb 15
Posts: 110
Credit: 6,108,311
RAC: 0

RE: What BOINC version are

Quote:

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.

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

KF7IJZ
KF7IJZ
Joined: 27 Feb 15
Posts: 110
Credit: 6,108,311
RAC: 0

RE: A quick google suggests

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

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

Christian Beer
Christian Beer
Moderator
Joined: 9 Feb 05
Posts: 595
Credit: 100,068,514
RAC: 4,124

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:

$ wget --quiet -O - https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi

611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home

$ curl https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi

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.

KF7IJZ
KF7IJZ
Joined: 27 Feb 15
Posts: 110
Credit: 6,108,311
RAC: 0

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

KF7IJZ
KF7IJZ
Joined: 27 Feb 15
Posts: 110
Credit: 6,108,311
RAC: 0

RE: The ca-certificates

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

So I just realized that I had updated rpi0-0 yesterday. Running curl, I get the following:

pi@rpi0-0:~ $ curl https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

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:

pi@rpi0-0:~ $ wget --quiet -O - https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi

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

floyd
floyd
Joined: 12 Sep 11
Posts: 133
Credit: 186,610,495
RAC: 0

$ curl

$ curl https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

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

$ curl https://einstein10.aei.uni-hannover.de/EinsteinAtHome_cgi/cgi

611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home

end EDIT

$ curl --cacert boinc-client_release-7.6-7.6.22/curl/ca-bundle.crt https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi

611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home


But

$ wget --quiet -O - https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi

611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.