LHC@home

Got this error with Rosetta and LHC 11:01am UTC 30th May 2020. On all my (Windows 10) machines, while requesting work.
"Peer certificate cannot be authenticated with given CA certificates"
But Universe and Einstein and Milkyway are ok.

Any ideas what screwed up? My computer? Both Rosetta and LHC at once? Boinc in general?

---

I am also getting this.
I think LHC@home's webcerts might of expired.
:C

I also getting this.
I think LHC@home's webcerts might of expired.
:C

I just thought it odd that Rosetta had the same problem at precisely the same time. I guess they bought them from the same place :-)

I don't know much about certificates. I've seen my Opera browser get annoyed about them before, but other browsers aren't so fussy. I assumed Opera didn't allow any leeway but others did. I guess Boinc is equally OCD.

---

I also see the same, it could be the BOINC certificate expired?

I also see the same, it could be the BOINC certificate expired?

But my other three projects (Universe, Milkyway, Einstein) are ok. Only Rosetta and LHC failed.

How do these certificates work? Explain like I'm five (T.M. Reddit)

---

I also see the same, it could be the BOINC certificate expired?

But my other three projects (Universe, Milkyway, Einstein) are ok. Only Rosetta and LHC failed.

How do these certificates work? Explain like I'm five (T.M. Reddit)

Is basically a file with a cryptographic key in in that says hey you can trust me from xx/xx/xxxx to xx/xx/xxxx
if those dates go out of range you can no longer trust that connection and in this day and age most things reject that as insecure.

Edit:

Here is a much better non five year old explanation.
https://www.entrustdatacard.com/pages/ssl

Is basically a file with a cryptographic key in in that says hey you can trust me from xx/xx/xxxx to xx/xx/xxxx
if those dates go out of range you can no longer trust that connection and in this day and age most things reject that as insecure.

Edit:

Here is a much better non five year old explanation.
https://www.entrustdatacard.com/pages/ssl

I see, thanks. I've only ever had it with Opera browser before, it moaned about my own ISP's webpage when I was trying to use their forum. But it did let me continue "at my own risk". And other browsers didn't even say anything at all, I assume some have a leeway, like a cop letting you go 31 in a 30 limit.

I take it there's some kind of central place that issues these things, and that's what my computer checks it against to make sure it's really the page I think it is? Otherwise surely Mr Smith could make a fake banking page, and just hand me a "certificate", like someone coming to my door and saying "I'm a policeman and here's my badge" - I can't trust him unless I call the police station and they can confirm that particular badge wasn't just printed off by a thief's inkjet.

---

You may check if your BOINC client uses the most recent CA certificates.
Locate the file ca-bundle.crt in your BOINC directory and check if the timestamp in line 4 is at least:

## Certificate data from Mozilla as of: Fri Jan 26 21:30:21 2018 GMT

If not ca-bundle.crt has to be replaced with a version from a recent BOINC client.

The file can also be downloaded from:
https://github.com/BOINC/boinc/blob/master/curl/ca-bundle.crt

You may check if your BOINC client uses the most recent CA certificates.
Locate the file ca-bundle.crt in your BOINC directory and check if the timestamp in line 4 is at least:

## Certificate data from Mozilla as of: Fri Jan 26 21:30:21 2018 GMT

If not ca-bundle.crt has to be replaced with a version from a recent BOINC client.

The file can also be downloaded from:
https://github.com/BOINC/boinc/blob/master/curl/ca-bundle.crt

Mine (all 6 computers) have precisely that date in there. But they will not connect to LHC or Rosetta. Universe, Milkyway, Einstein are all fine.

It was working overnight, as I have a huge number of Rosettas downloaded that weren't there when I went to bed, but as of about 11am GMT they refuse to connect.

---

I've got the same date in there as well.

There are complaints on Rosetta. I can't upload either, just in the past hour or so.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=6893

There are complaints on Rosetta. I can't upload either, just in the past hour or so.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=6893

Yip, and my thread there: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14006

Hopefully somebody somewhere will work out what's wrong. Not knowing anything about SSL, I don't know where it's expired.

---

same problem here, with LHC and Rosetta. GPUGRID and WCG are okay.

When opening the file ca-bundle.crt it shows a certificate valid from 1.9.1998 - 28.1.2028.
Besides, line 4 says "Certificate data from Mozilla as of: Fri Jan 26 21:30:21 2018 GMT"

Same issue here. I thought LHC had lent some server capacity to Rosetta for the COVID-19 project. Maybe this has messed something up...

same problem here, with LHC and Rosetta. GPUGRID and WCG are okay.

When opening the file ca-bundle.crt it shows a certificate valid from 1.9.1998 - 28.1.2028.
Besides, line 4 says "Certificate data from Mozilla as of: Fri Jan 26 21:30:21 2018 GMT"

Open the ca-bundle.ca with notepad or similar then its line 4

I assume then it's the server side certificate that expired for these projects. Since all of our client side certs are valid til 2028

I assume then it's the server side certificate that expired for these projects. Since all of our client side certs are valid til 2028

Then why can people use Mac and Linux ok? Apparently only Windows is refusing.

---

Add NumberFields@home as another project affected.

Unfortunately, opening ca-bundle.crt in Windows only shows the details for the first of the 133 certificates in the bundle. I've been through them all, and - although a few of them have expired - none expired this morning.

Although the COMODO certificate authenticating this website, and the InCommon certificate authenticating the NumberFields and Rosetta websites, all seem to be in order, I've seen a suggestion on the web that certificates may be rejected as expired in some cases when a newer certificate is issued (even if the old one appears still to have time left to run before expiry).

OK, that doesn't make any sense then, maybe the certificate was expired early due to some security problem? I don't think there is much we can do on the client side though?

Add NumberFields@home as another project affected.

Unfortunately, opening ca-bundle.crt in Windows only shows the details for the first of the 133 certificates in the bundle. I've been through them all, and - although a few of them have expired - none expired this morning.

Although the COMODO certificate authenticating this website, and the InCommon certificate authenticating the NumberFields and Rosetta websites, all seem to be in order, I've seen a suggestion on the web that certificates may be rejected as expired in some cases when a newer certificate is issued (even if the old one appears still to have time left to run before expiry).

Just noticed this in Opera browser on Windows 10:
This discussion is fine, but this thread: https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5387
Which has images, specifically http://cms-results.web.cern.ch/cms-results/public-results/publications/SMP-15-003/CMS-SMP-15-003_Figure_006-a.png
Shows: https://www.dropbox.com/s/6qjbvllcsgslvrt/unsecure.jpg?dl=0

---