I wanted to provide an overview and summary of the issue regarding Debian Stable (Jessie) and our https certificate.

For those of you who are less knowledgeable about https certificates, the following articles will provide context for the following discussion:

• How https works: http://robertheaton.com/2014/03/27/how-does-https-actually-work/
  
• Why everyone is rushing to release new certificates: https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1

Additionally, the industry is also moving to 2048-bit keys from the prior 1024-bit keys.

Summary
The industry is changing to longer keys and changing to a stronger cryptographic hashing function at the same time. This increases the security of the internet but does come with some industry wide challenges. We have updated our https certificate to the current best practices and they are secure and up to date.

Technical details
The challenge that started this thread is caused by the migration of Root Certificates from 1024-bit to 2048-bit signing keys.

World Community Grid upgraded to a 2048-bit key signed using SHA-2 in the summer of 2015 (see http://www.worldcommunitygrid.org/about_us/viewNewsArticle.do?articleId=437). This certificate was signed by the "thawte SSL CA - G2" intermediate certificate. The "thawte SSL CA - G2" has a 2048-bit key and has a SHA-2 signature from "thawte Primary Root CA". The "thawte Primary Root CA" is a root certificate with a 2048 bit key. It is expected that applications using https should store the public key for "thawte Primary Root CA" in their trusted certificate store.

This means that we have the following trusted chain that uses SHA-2 for signatures and 2048 bit keys.

WCG Certificate -> Thawte G2 Intermediate Certificate -> Thawte Primary Root CA

This chain will be trusted since the public key for the Thawte Primary Root CA should be found by the applications in its trusted certificate store.

Therefore this represents a current and secure certificate.

However, the problem is that the "thawte Primary Root CA" was not created until 2006 and is not as broadly deployed as their 1024 bit root certificate called "Thawte Premium Server CA". In fact, the "thawte Primary Root CA" was not added to the trusted certificate file in the BOINC system until July 11, 2013 (https://github.com/BOINC/boinc/commits/master/curl/ca-bundle.crt see commit 03b69a8). Thus, any BOINC client built before the trusted certificate store was updated will not trust the "Thawte Primary Root CA" public key and the trust chain shown above would be determined to be untrusted by the BOINC client.

Thawte, like other certificate providers, anticipated this problem so they provided a second trusted path as shown below:

WCG Certificate -> Thawte G2 Intermediate Certificate -> Thawte Primary Root CA (cross-signed) -> Thawte Premium Server CA

This chain will be trusted since the public key for the Thawte Premium Server CA should be found by the applications in its trusted certificate store.

Having two paths to a trusted certificate, as we do, is a valid and standards compliant configuration.

The BOINC client that is available through Debian is built to use the trusted certificate store from Debian and the version of OpenSSL deployed with Debian. Recently, Debian updated their trusted certificate store to remove the public keys of the 1024 root certificates. This means that they removed "Thawte Premium Server CA" and thus the alternate certificate chain was no longer recognized as a trusted certificate path. However, since the "Thawte Primary Root CA" continues to be present in their trusted root store, the 1st path above continues to be a valid trusted path. Unfortunately, there is a bug in the version of OpenSSL that causes it to not handle multi-path certificate chains correctly and it is started to reject our certificate. This bug in OpenSSL has already been fixed in a more recent version of the library.

This means that Debian needs to restore the public keys for the 1024-bit root certificates or upgrade their OpenSSL library. There is a bug open at Debian which Christian Beer at Einstein@Home has contributed to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812708

This issue could be resolved if we removed the 2nd certificate chain from what the server sends with our certificate. At some point when the "Thawte Primary Root CA" is broadly enough deployed this is indeed something we will do. However, at this time this would break all BOINC clients before version 7.4. Thus this configuration needs to remain in place and we have to wait until the Debian trusted certificate file is updated.

Note that Christian Beer has also posted a work around at Einstein@Home that should be used for people experiencing this issue. You can read this here: https://einstein.phys.uwm.edu/forum_thread.php?id=11768