New signatures for CAcert-Class 3-Subroot-certificate – Changes for users of CAcert-Certificates
(english version, german see below)
CAcert re-signs its Class 3-certificate with a new SHA256 signature. The formerly used MD5 signature is not seen as fully secure any more by Mozilla and is therefore deprecated. Mozilla is going to drop support for MD5-signed Class 3-subroot and end-entity certificates after 30th June. Users of Mozilla products like Firefox, and Thunderbird may experience errors when these programs try to verify such certificates.
Hence webmasters, as well as users of CAcert’s Class 3-certificates, have to download and install the newly signed certificates from CAcert’s website. The same procedure applies if the Class 3-certificate is used for secure e-mail communication, for code signing, or for document signing.
The procedure in short:
1. Download the new Class 3 PKI Key from http://www.cacert.org/index.php?id=3
2. Either install it directly in your browser, or any other client program you use the certificate for, or save it to the SSL configuration directory of your webserver. For Apache this may be: /etc/apache2/ssl/class3.crt (PEM-Format)
3. Verify the SHA1-fingerprint of the downloaded certificate:
AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE
Example Commandline: openssl x509 -fingerprint -noout -in class3.crt
Or look at the fingerprint when importing the certificate into the webbrowser
4. Webmaster now re-create the necessary hash with c_rehash, or the like
By using the safe SHA256-hash CAcert is focussing on securing the internet on a continuing basis. Further information is given on CAcert’s Wiki page.
-+-
Neue Signaturen für CAcert-Class 3-Subroot-Zertifikat – Änderungen für Nutzer von CAcert-Zertifikaten
CAcert signiert sein Class 3-Subroot-Zertifikat neu mit einer SHA256-Signatur. Die bisherige von CAcert genutzte MD5-Signatur wird von Mozilla als nicht mehr ausreichend sicher angesehen. Mozilla wird deshalb MD5-signierte Class 3-Subroot- und End-Zertifikate nach dem 30. Juni nicht mehr unterstützten. Benutzer etwa von Firefox und Thunderbird können nach diesem Tag einen Fehler beim Prüfen MD5-signierter Zertifikate erhalten.
Webmaster wie Webbenutzer müssen daher, wenn sie das Class 3-Subroot-Zertifikat verwenden, dieses neu von der CAcert-Webseite herunterladen und installieren. Gleiches ist erforderlich bei Verwendung der Class 3-Zertifikate für sichere E-Mail-Kommunikation, zur Code-Signierung oder zum Unterzeichnen von Dokumenten.
Der Ablauf in Kurzform:
1. Den neuen Class 3 PKI Key von http://www.cacert.org/index.php?id=3 herunterladen
2. Je nach Anforderung entweder direkt im Browser bzw. anderen, benutzten Programmen installieren oder in das SSL-Konfigurationsverzeichnis des Webservers ablegen. Für Apache zum Beispiel: /etc/apache2/ssl/class3.crt (PEM-Format)
3. Den SHA1-Fingerabdruck des heruntergeladenen Zertifikats prüfen:
AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE
Beispiel Kommandozeile: openssl x509 -fingerprint -noout -in class3.crt
Oder im Web-Browser Anzeige des Fingerprints beim Zertifikatsimport
4. Webmaster erzeugen dann den erforderlichen Hash mit c_rehash oder ähnlichen Programmen neu
Durch den nun verwendeten SHA256-Hash investiert CAcert weiter in ein sicheres Internet. Weitere Informationen befinden sich im CAcert-Wiki.
I think it’s not good that you resigned the key and gave it a different Validity time span. The md5 signed Class 3 Root has this validity:
Not Before: Oct 14 07:36:55 2005 GMT
Not After : Mar 28 07:36:55 2033 GMT
while the sha256 signed Class 3 Root has this validity:
Not Before: May 23 17:48:02 2011 GMT
Not After : May 20 17:48:02 2021 GMT
So it starts later and it ends earlier.
People with certificates that are also valid outside the “new” validity might run into problems. I had issues with a cacert server certificate from 2010-12-31 with I put together with the “new” sha256-signed intermediate certificate into my gnutls based exim server. A symbian client whch had the cacert root certificate installed could no longer connect to the exim server. The error logged on the server side was:
(gnutls_handshake): A TLS fatal alert has been received.
Replacing your “new” intermediate certificate on the server by the “old” one fixes the issue. So either no intermediate or the old one just worked. I guess the problem is that the client refuses to accept a intermediate certificate that hasn’t been valid at the time where the server certificate was created.
So I think it might be worth evaluating if you should do the resigning again – using the same validity.
well, some more tests showed that at least this symbian TLS client problem is not related to the changed validity time spans but to some unfixed bugs in the symbian TLS stack.
And finally I found that my website isn’t accessible with IE7 from a XP SP2 workstation anymore if the new intermediate certificate with serial number 672138 (0xa418a) and SHA256 signature is installed. Installing the old MD5 signed class3 intermediate certificate makes it work again – same symptom like on the Symbian browser.
While it would have been nice if you decided to use SHA1 in 2005 it was not a very good idea to jump over to SHA256 in 2011. Many TLS implmentations just don’t support SHA256 and they will fail to connect to servers sending out the SHA256 signed class3 cert.
It looks like everyone using a CAcert certificate signed with the Class3 cert is doomed. Either the intermediate certificate will be rejected by some very recent browsers because it is unsafe (MD5 singed) or the connection to the server will fail for many users because SHA256 isn’t supported by their TLS implementations.
IMHO you really mess things up quite a lot. Setting up another SHA1 resigned version of that certificate looks like the only way out here. And maybe you should stop using that class3 cert completely and create a new one.
For other users of CAcert I can only encourage you to stop using certificates that are signed by the class3 cert if you want your site to be accessible by brand new and not to brand new browsers. Use certificates signed by the CAcert Root CA directly instead.