The ca-bundle.crt that comes with the Client is only used on Windows. On Linux and Mac the system certificate stores are used. To confirm this please try curl -v like this (I'm on Stretch):
$ curl -v https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
* Trying 130.75.116.40...
* Connected to scheduler.einsteinathome.org (130.75.116.40) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 696 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: www.einsteinathome.org (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=US,ST=Wisconsin,L=Milwaukee,O=University of Wisconsin-Milwaukee,OU=Physics,CN=www.einsteinathome.org
* start date: Fri, 11 Dec 2015 00:00:00 GMT
* expire date: Mon, 10 Dec 2018 23:59:59 GMT
* issuer: C=US,O=thawte\, Inc.,CN=thawte SSL CA - G2
* compression: NULL
* ALPN, server did not agree to a protocol
> GET /EinsteinAtHome_cgi/cgi HTTP/1.1
> Host: scheduler.einsteinathome.org
> User-Agent: curl/7.46.0
> Accept: */*
>
The ca-bundle.crt that comes with the Client is only used on Windows. On Linux and Mac the system certificate stores are used. To confirm this please try curl -v like this (I'm on Stretch):
*snip*
I think that either curl doesn't use the correct certificate store or the update of the store was broken.
pi@rpi0-0:~ $ curl -v https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
* Hostname was NOT found in DNS cache
* Trying 130.75.116.40...
* Connected to scheduler.einsteinathome.org (130.75.116.40) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
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.
Since I can show BOINC/EAH working fine before doing an apt-get update/upgrade, I'm going to guess it came in the update, which I realize that is very unusual.
By chance, can anyone download the 11/21/2015-jessie lite image, install it, and do an apt-get update/upgrade to verify that the ca-certificates v20141019+deb8u1 gets installed and breaks boinc? I can reliably reproduce the error, but I'd like to see if someone else can.
I haven't tried stretch because again, I had heard that there was an issue as they were updating libc that broke the EAH application (read about this in the parallella thread).
By chance, can anyone download the 11/21/2015-jessie lite image, install it, and do an apt-get update/upgrade to verify that the ca-certificates v20141019+deb8u1 gets installed and breaks boinc? I can reliably reproduce the error, but I'd like to see if someone else can.
I haven't tried stretch because again, I had heard that there was an issue as they were updating libc that broke the EAH application (read about this in the parallella thread).
I have an old Raspberry B that I can reformat and test on. In the meantime can you try to reconfigure the ca-certificates package using "dpkg-reconfigure ca-certificates". The curl installation needs to know about the CAfile and read in the certificates from there.
Another option is to go back to the working version and forbid the update of ca-certificates, then update and see if it works.
Edit: I would also like to see the "curl -v ..." output from a working rpi0-? installation just to compare the CAfile and CApath values.
and it worked manually. I then added it to global config and it did not work.
Which leads me to the conclusion that you cannot compare the curl command line tool and BOINC. For me https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi does not work manually, with the same output as for KF7IJZ, but BOINC doesn't seem to care. On the other hand, https://einstein10.aei.uni-hannover.de/EinsteinAtHome_cgi/cgi does work manually and scheduler.einsteinathome.org is einstein10. I start to wonder whether BOINC behaves as it should, in my case connecting to a https server that can't be verified, in the other case not connecting when it should.
I am interested in trying either forbidding an upgrade to ca-certificates or installing the version from the test stream.
Right now, the only node I don't really want to fool with rolling back is rpi0-0, which is currently broken due to ca-certs and is the master node w/ the correct network setup. I will try to get the testing version of ca-certs installed there though. I can blow the rest of my Zeros away and test whatever as I have time.
I am not sure why you're getting a 2014 version, Stretch should be recent.
My only B+ running Jessie is being offered the deb8u1 version from 2014, which I have currently declined to install due to the issues you're having. I might backup the SD card first and then try it.
I was the one who got the 1.06 BRP4 app failure when Stretch updated libc6. I didn't have a recent backup so had to reinstall Jessie. I sent a PM to Bikeman about it.
After updating it now can't connect. I would have to concur that whatever Debian put in there (or took out) breaks it.
Quote:
Einstein@Home 26-01-2016 12:08 PM update requested by user
Einstein@Home 26-01-2016 12:08 PM Sending scheduler request: Requested by user.
Einstein@Home 26-01-2016 12:08 PM Not requesting tasks: "no new tasks" requested via Manager
26-01-2016 12:08 PM Project communication failed: attempting access to reference site
Einstein@Home 26-01-2016 12:08 PM Scheduler request failed: Peer certificate cannot be authenticated with given CA certificates
26-01-2016 12:08 PM Internet access OK - project servers may be temporarily down.
The ca-bundle.crt that comes
)
The ca-bundle.crt that comes with the Client is only used on Windows. On Linux and Mac the system certificate stores are used. To confirm this please try curl -v like this (I'm on Stretch):
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home
* Connection #0 to host scheduler.einsteinathome.org left intact
I think that either curl doesn't use the correct certificate store or the update of the store was broken.
RE: begin EDIT$ curl
)
I tried curl on this address and it worked manually. I then added it to global config and it did not work.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: The ca-bundle.crt that
)
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.
Since I can show BOINC/EAH working fine before doing an apt-get update/upgrade, I'm going to guess it came in the update, which I realize that is very unusual.
By chance, can anyone download the 11/21/2015-jessie lite image, install it, and do an apt-get update/upgrade to verify that the ca-certificates v20141019+deb8u1 gets installed and breaks boinc? I can reliably reproduce the error, but I'd like to see if someone else can.
I haven't tried stretch because again, I had heard that there was an issue as they were updating libc that broke the EAH application (read about this in the parallella thread).
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: By chance, can anyone
)
I have an old Raspberry B that I can reformat and test on. In the meantime can you try to reconfigure the ca-certificates package using "dpkg-reconfigure ca-certificates". The curl installation needs to know about the CAfile and read in the certificates from there.
Another option is to go back to the working version and forbid the update of ca-certificates, then update and see if it works.
Edit: I would also like to see the "curl -v ..." output from a working rpi0-? installation just to compare the CAfile and CApath values.
RE: I tried curl on this
)
Meaning https://einstein10.aei.uni-hannover.de/EinsteinAtHome_cgi/cgi
Which leads me to the conclusion that you cannot compare the curl command line tool and BOINC. For me https://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi does not work manually, with the same output as for KF7IJZ, but BOINC doesn't seem to care. On the other hand, https://einstein10.aei.uni-hannover.de/EinsteinAtHome_cgi/cgi does work manually and scheduler.einsteinathome.org is einstein10. I start to wonder whether BOINC behaves as it should, in my case connecting to a https server that can't be verified, in the other case not connecting when it should.
RE: In the meantime can you
)
I don't dare try it without knowing the current configuration. What options would there be?
Aren't the certificates from CAfile supposed to be present in CApath? Soft links actually, which makes me think of checking the real files.
I was going to suggest the other way around, update the certificates only.
RE: Edit: I would also
)
Here's the output from rpi2-3, which is running stock jessie more or less.
First, the curl output
611
http://einstein.phys.uwm.edu/
60.000000
Error in request message: no start tag
Einstein@Home
* Connection #0 to host scheduler.einsteinathome.org left intact
Next, ca-certificates version
I am interested in trying either forbidding an upgrade to ca-certificates or installing the version from the test stream.
Right now, the only node I don't really want to fool with rolling back is rpi0-0, which is currently broken due to ca-certs and is the master node w/ the correct network setup. I will try to get the testing version of ca-certs installed there though. I can blow the rest of my Zeros away and test whatever as I have time.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
So I added Raspbian Stretch
)
So I added Raspbian Stretch as an apt-source and selectively installed ONLY ca-certificates.
Running curl still gives the error.
Here's the version info:
I was really surprised that this didn't work. I'm going to progressively upgrade components, starting with boinc-client next.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
This is one of my Pi2's
)
This is one of my Pi2's running Stretch
I am not sure why you're getting a 2014 version, Stretch should be recent.
My only B+ running Jessie is being offered the deb8u1 version from 2014, which I have currently declined to install due to the issues you're having. I might backup the SD card first and then try it.
I was the one who got the 1.06 BRP4 app failure when Stretch updated libc6. I didn't have a recent backup so had to reinstall Jessie. I sent a PM to Bikeman about it.
BOINC blog
After updating it now can't
)
After updating it now can't connect. I would have to concur that whatever Debian put in there (or took out) breaks it.
BOINC blog