Add NumberFields@Home to that list. I'm getting

30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: Connected to numberfields.asu.edu (129.219.51.76) port 80 (#1791)
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Received header from server: HTTP/1.1 301 Moved Permanently
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: Issue another request to this URL: 'https://numberfields.asu.edu/NumberFields_cgi/file_upload_handler/'
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: Connected to numberfields.asu.edu (129.219.51.76) port 443 (#1792)
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: found 133 certificates in ca-bundle.crt
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: found 402 certificates in /etc/ssl/certs
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: ALPN, offering http/1.1
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
30/05/2020 14:12:06 | NumberFields@home | [http] [ID#3878] Info: server certificate verification failed. CAfile: ca-bundle.crt CRLfile: none
30/05/2020 14:12:06 | NumberFields@home | [http] HTTP error: Peer certificate cannot be authenticated with given CA certificates
30/05/2020 14:12:07 | NumberFields@home | Temporarily failed upload of wu_sf3_DS-15x271_Grp4812969of6553600_0_r194046698_0: transient HTTP error

I don't normally check their logs as closely as that - it's one of the projects which runs very smoothly - but somebody else reported a problem around 11:30 UTC today.

With three projects affected, I wonder if something in BOINC's ca-bundle.crt has expired?

I got a bit of an impromptu introduction to the subject a couple of years ago. I've checked through all those "133 certificates in ca-bundle.crt", and - although a few of them have expired - none of them died anywhere near 11 am today.

I'll look at those '402 certificates in /etc/ssl/certs' on my Linux machine, and see if they help - otherwise I''ll refer this one upstairs.

I've left a message for the NFaH admin (Arizona - probably not minding the shop at this time on a Saturday morning): he was "thinking of switching from http to https when this Pentathlon is over" earlier this month, so may have something to add.

I've looked through the Linux certificate directory. All sorts of things in there, including what looks like a duplicate of our ca-bundle.crt under another name. It didn't work either.

The NFaH log I posted was from Linux, so it isn't as simple as 'Linux & Mac good, Windows bad'.

I've posted some extras in your LHC thread. Since moderator Toby Broom is paying attention (I think he's pretty clued up), that might be the best place. But I'll certainly report upstream once we have a clear idea where the problem lies.

Hi Richard,

there is an expired certificate:

# openssl crl2pkcs7 -nocrl -certfile ca-bundle.crt | openssl pkcs7 -print_certs -text -noout | grep -i after | grep 2020
            Not After : May 30 10:48:38 2020 GMT
            Not After : Mar 25 11:03:10 2020 GMT

# openssl crl2pkcs7 -nocrl -certfile ca-bundle.crt | openssl pkcs7 -print_certs -text -noout | less
...
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
...

"AddTrust External CA Root" is an old Comodo cert, now Sectigo, which expired today.

For more information, see:
- https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rgSZ
- https://crt.sh/?id=1720081

We just need to replace the old Intermediate cert with the new Root CA cert: https://crt.sh/?d=1720081

Could you please file a bug report on GitHub? Otherwise I'll try to do this later/tomorrow...

Best wishes,

walli

Many thanks - I see it (#6 of 133). I'll do a bit of playing around, then certainly pass it on.

BINGO!

I hacked that new certificate into the bundle, and did a complete work cycle at NumberFields - Upload, report, download. All successful.

It's actually easy to do - the certificate is a cryptographic string, but just stored in text format. The COMODO download comes with Linux format line-endings - use Notepad++ to flip those to Windows. Then use the text editor of your choice to splice it into the bundle file. De-activate the old bundle file in your BOINC program directory, replace it with the new one, and simply retry the failed uploads - no need for a restart.

I'll do the GitHub issue next - feel free to pass the news round the boards while I'm busy.

I made the updated file for anyone that "trusts" me.

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

I can also confirm it works

The news is already spreading...

Linux isn't or shouldn't be affected by this issue in most cases because the client looks for system-wide shared certificates (e.g. "/etc/ssl/certs/ca-certificates.crt" on Debian based distributions). I don't know how this works on macOS or Android.

Thanks all. GitHub issue at https://github.com/BOINC/boinc/issues/3789. NumberFields admin had started checking just before I reached him, but understandably didn't find any problem. I'll start firing out some emails to key people.

Linux isn't or shouldn't be affected by this issue in most cases because the client looks for system-wide shared certificates (e.g. "/etc/ssl/certs/ca-certificates.crt" on Debian based distributions).

My Linux Mint (based on Ubuntu 18.04) got caught, but should be fixable the same way. I'll report back. Maybe I haven't updated recently enough.

Seems like the windows version of BOINC should do something like that, so the same thing doesn't happen next time certs expire?

Fixed my 3 Win hosts, but don't know how to do it on my Mint host.

https://www.systutorials.com/docs/linux/man/8-update-ca-certificates/?

Btw, nice to see you're still around Toby! :)

---

Not immediately working, here. I've tried editing the file, restarting BOINC, rebooting machine. Nada.

Running update-ca-certificates by itself did nothing ('no files changed'), but with -f things did happen. No change in BOINC, though.

Copied the newly-generated ca-certificates.crt, renamed the copy as ca-bundle.crt, and put it where the BOINC file was (in data directory). Nada again, though without restart so far this time.

Restarted BOINC, no upload - but I did get my CUDA driver back this time (it went awol, and downloaded backup OpenCL tasks instead). So now I'm doing a full update/reboot.

Thanks. I ran "sudo update-ca-certificates", and it shows that the "ca-certificates.crt" file (in /etc/ssl/certs) now has today's date.
But whether anything is changed in the file is not clear.
I will know at midnight UTC, or so it appears.

I copied the downloade 1720081.crt to /usr/local/share/ca-certificates and did a sudo update-ca-certificates and it worked.