what is 3rd step? can't understand.

can you just upload working certificate after all editions?

Greetings,

I currently have 13 tasks with a deadline of TOMORROW! I also have 24 tasks with a deadline of Tuesday. If I don't get a resolution on this issue soon, I would have wasted time doing those tasks and Rosetta would be out the work done, at least until the tasks can be resent for further processing. I don't like that. :(

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr XO
USS Vre'kasht NCC-33187

"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

Hi,

to all the Ubuntu guys: Playing around with "/usr/local/share/ca-certificates" is the wrong way to get this fixed. It might be possible that, depending on the order of the certs inside "/etc/ssl/certs/ca-certificates.crt" and/or the version of libcurl, you have to deactivate the expired system-wide cert to get the Boinc client running. This is done by:

# sudo sed -i 's/mozilla/AddTrust_External_Root/!mozilla/AddTrust_External_Root/' /etc/ca-certificates.conf
# sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 1 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Now the old cert is not linked within "/etc/ssl/certs/" and not present inside "/etc/ssl/certs/ca-certificates.crt" any longer and the Boinc client works without any restart.

My short tests showed me that Ubuntu 20.04 and 18.04.4 work flawlessly out of the box without the above fix, Ubuntu 16.04.6 though needed this procedure. On all these 3 systems both the old "AddTrust_External_Root" and the new "COMODO_RSA_Certification_Authority" were already installed. There was no need to add the new COMODO cert (also called "1720081") to any of my systems.

Windows users please note: https://github.com/BOINC/boinc/issues/3789#issuecomment-636400593
That means: If your client is no older than 7.9.1/7.10 (so it was shipped with the latest "ca-bundle.crt" from January 2018), it's sufficient to delete the "AddTrust External Root" block in "ca-bundle.crt" and you are done. But be aware: I did not check the exact Boinc client version numbers, they are a guess based on the source code repository!

You might adapt this on other Ubuntu versions and/or Debian based distributions.

Hth and best wishes,

walli

win7
these steps
1) download ca-bundle.crt linked by Tony https://boinc.berkeley.edu/forum_thread.php?id=13758&postid=98903#98903
2) copy 1720081.crt certificate from GitHub https://github.com/BOINC/boinc/issues/3789
and just BOINC relaunch worked for me.

Sure thing, raw text https://pastebin.com/CYj1Vsek and crt https://we.tl/t-vcXZh9iAYd :)

Does Boinc auto-update? If so, Boinc could release a new version with an updated security file.
If it doesn't autoupdate, then Rosetta (and LHC and Numberfields) should email every user and tell them to update Boinc.

It doesn't auto-update, no.
Though it could auto-update Android Boinc if people's Google Play Store settings allow it

I still don't know what's going on with Android Boinc. One of my phones (Android 7.0) has a version that isn't supposed to exist, 7.16.5. My other phone, Android 4.5, has version 7.4.53.

---

[quote]Welp, I guess that's two Android devices down for me. One because of issues with BOINC and Android 9.0, plus the fact that I don't charge that device enough to meet the deadlines. One because of this certificate expiring.

I hope this gets resolved before we get a massive wave of tasks timing out.

It only affects some projects, my Androids are doing other project work instead. I only know of LHC, Rosetta, and Numberfields needing the certificate.

I'm running WCG on my two phones now. I am concerned about the impact on this project though.

From the sound of things, I'm inclined to advise people to suspend all Android Rosetta tasks, abort those that haven't started, and switch to run or join WCG's Open Pandemics CV19 tasks.
I can't be sure this issue will be fixed before deadlines and that time is better spent running something productive.
If Admins aren't around until Monday it'll have been 2 days before they can begin to look for a solution and Android deadlines will likely be missed

By this time I would think all tasks have been completed anyway and are just jammed in the phone's upload queue.

---

Here is a link for people that trust me

https://1drv.ms/u/s!AsVDg7OAm7-whqEqBXKHuOie0UoBKA?e=VHwBAP

Thanks so much for this, made my life a lot easier! :)

Hi,

to all the Ubuntu guys: Playing around with "/usr/local/share/ca-certificates" is the wrong way to get this fixed. It might be possible that, depending on the order of the certs inside "/etc/ssl/certs/ca-certificates.crt" and/or the version of libcurl, you have to deactivate the expired system-wide cert to get the Boinc client running. This is done by:

# sudo sed -i 's/mozilla/AddTrust_External_Root/!mozilla/AddTrust_External_Root/' /etc/ca-certificates.conf
# sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 1 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Now the old cert is not linked within "/etc/ssl/certs/" and not present inside "/etc/ssl/certs/ca-certificates.crt" any longer and the Boinc client works without any restart.

My short tests showed me that Ubuntu 20.04 and 18.04.4 work flawlessly out of the box without the above fix, Ubuntu 16.04.6 though needed this procedure. On all these 3 systems both the old "AddTrust_External_Root" and the new "COMODO_RSA_Certification_Authority" were already installed. There was no need to add the new COMODO cert (also called "1720081") to any of my systems.

Windows users please note: https://github.com/BOINC/boinc/issues/3789#issuecomment-636400593
That means: If your client is no older than 7.9.1/7.10 (so it was shipped with the latest "ca-bundle.crt" from January 2018), it's sufficient to delete the "AddTrust External Root" block in "ca-bundle.crt" and you are done. But be aware: I did not check the exact Boinc client version numbers, they are a guess based on the source code repository!

You might adapt this on other Ubuntu versions and/or Debian based distributions.

Hth and best wishes,

walli

Hi Walli,

There seems to be a problem. I did a copy paste from here into Terminal and this is what I got:

rick@Minty-Winders:~$ sudo sed -i 's/mozilla/AddTrust_External_Root/!mozilla/AddTrust_External_Root/' /etc/ca-certificates.conf
[sudo] password for rick:                 
sed: -e expression #1, char 34: unknown option to `s'
rick@Minty-Winders:~$

I haven't a clue what that means. Does the "!" belong in front of the second mozilla?

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr XO
USS Vre'kasht NCC-33187

"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

Yep, sorry that I didn't check twice, but somehow the escaping backslashs have been substituted away...

---

This forum seems to kill them for some reason, even inside a code block. Wait a sec...

It should look like:
https://pastebin.com/avKg94bv

Sorry, I cannot edit the old post to correct this :(.

All the "sed" command does is putting a "!" in front of the corresponding line.

The "!" in front of an entry marks a certificate as being deactivated, but you have to apply the changes via a "sudo update-ca-certificates". You could have put a "#" as well (which means "this is a comment"), but this would NOT remove any old existing symlink in "/etc/ssl/certs/" which is also necessary to get rid of the expired cert.

thank you.
1) and 2) and PC restart solved all issues.

Yep, sorry that I didn't check twice, but somehow the escaping backslashs have been substituted away...

---

This forum seems to kill them for some reason, even inside a code block. Wait a sec...

It should look like:
https://pastebin.com/avKg94bv

Sorry, I cannot edit the old post to correct this :(.

The "!" in front of an entry marks a certificate as being deactivated, but you have to apply the changes via a "sudo update-ca-certificates". You could have put a "#" as well (which means "this is a comment"), but this would NOT remove any old existing symlink in "/etc/ssl/certs/" which is also necessary to get rid of the expired cert.

Hi Walli,

Yep, I was researching "sed" on the Internet and came across using the backslash to delimit the forward slash and I found what the "!" was used for. I shall make the modifications and let you know what I get. :)

[edit] I am BACK in business!!! :) Thanks Walli!!![/edit]

[edit2] I was going to make the changes to my laptop which was in the same state as my main. I guess the laptop caught wind of what I did with my main and it fixed itself. I don't know how, but it uploaded the stuck uploads and downloaded new tasks to work on. Woohoo!!! :) [/edit2]

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr XO
USS Vre'kasht NCC-33187

"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

Yep, sorry that I didn't check twice, but somehow the escaping backslashs have been substituted away...

---

This forum seems to kill them for some reason, even inside a code block. Wait a sec...

It should look like:
https://pastebin.com/avKg94bv

Sorry, I cannot edit the old post to correct this :(.

All the "sed" command does is putting a "!" in front of the corresponding line.

The "!" in front of an entry marks a certificate as being deactivated, but you have to apply the changes via a "sudo update-ca-certificates". You could have put a "#" as well (which means "this is a comment"), but this would NOT remove any old existing symlink in "/etc/ssl/certs/" which is also necessary to get rid of the expired cert.

Whoever controls this forum is a control freak, first they adjust links to say https when they shouldn't, now they remove key backslashes.

---

Whoever controls this forum is a control freak, first they adjust links to say https when they shouldn't, now they remove key backslashes.

It's the forum software that doesn't allow backslashes to be posted as they are reserved control characters.

---

Grant
Darwin NT

Whoever controls this forum is a control freak, first they adjust links to say https when they shouldn't, now they remove key backslashes.

It's the forum software that doesn't allow backslashes to be posted as they are reserved control characters.

I thought only square brackets meant anything in here, like the word quote enclosed in them. Anyway, I've written path names with backslashes either here or another Boinc forum without a problem. I shall try a Windows path below:

c:windowssystem

Ok, so they get deleted in here, but not elsewhere. So not the software, but a setting chosen in Rosetta but not elsewhere.

c:windowssystem

The above one is enclosed in the word code in square brackets. Meddling inside a code tag is ridiculous.

---

I think Rosetta changed something in the server within the past hour. The SSL Labs test is now giving me different results that don't include the expired cert in the trust chain at all. Maybe now it will work without any workaround.

---

Grant (SSSF) wrote:

It's the forum software that doesn't allow backslashes to be posted as they are reserved control characters.

More likely a bug, as backslashes in user input get interpreted as escape characters instead of themselves being escaped…

… multiple times…

… which means if you type enough in the input to overcome that, you’ll get one in the output!

Four backslashes in ⟶ one backslash out

  C:\Program Files\BOINC

Same in [pre]:

C:\Program Files\BOINC

Grant (SSSF) wrote:

It's the forum software that doesn't allow backslashes to be posted as they are reserved control characters.

More likely a bug, as backslashes in user input get interpreted as escape characters instead of themselves being escaped…

… which means if you type enough in the input to overcome that, you’ll get one in the output!

Four backslashes in ⟶ one backslash out

  C:\Program Files\BOINC

Same in [pre]:

C:\Program Files\BOINC

This is a conspiracy, somebody is harvesting those slashes. Check for them being advertised on Ebay.

---

Does Boinc auto-update? If so, Boinc could release a new version with an updated security file.
If it doesn't autoupdate, then Rosetta (and LHC and Numberfields) should email every user and tell them to update Boinc.

It doesn't auto-update, no.
Though it could auto-update Android Boinc if people's Google Play Store settings allow it

I still don't know what's going on with Android Boinc. One of my phones (Android 7.0) has a version that isn't supposed to exist, 7.16.5. My other phone, Android 4.5, has version 7.4.53.

Did we talk about this before?
7.16.5 appears to be a beta but it's not available in the Play Store ttbomk - no idea where to find it, nor whether it'll fix this particular issue

---