česky | english
The new root Class1 certificate and the new subroot (intermediate) Class3 certificates - FAQ
Class3 Re-sign - Members and users FAQ
CAcert has embarked on an interim project to re-sign the Class 3 root. The project is inspired by the Mozilla announcement of Dates for Phasing out MD5-based signatures and 1024-bit moduli. Community members from the Software-Assessment Project team and Critical System Administrators team rose to the challenge to prepare, test and implement a class3 re-sign procedure.
The intention is to re-sign the class3 subroot with new sha256, and rollout the certificate. All issued class3 keys are still valid, because the class3 private key is still intact. It is similiar in process and effect to a certificate renewal. All users who uses a class3-issued cert have to replace the class3 subroot certificate in their browser, email client, or server (once only).
The proposed procedure: Class3 Re-sign Procedure
Board meeting 2011-05-15 presentation, approval
Motions: m20110515.2 that we upgrade the class-3 root ...
m20110515.3 that we ask the community to prepare a press statement ...
Class 3 subroot re-signed according to procedure by Critical Sysadms Team
Exec report from Critical Team
bug# for source code changes: bug #946
prepare press release, blog post, members notifications to be presented to board
prepare support FAQ, present to SEs and support maillist
approval of press release, blog post, members notifications: m20110605.2
2011-06-15 - 2011-06-20
proposed class3 subroot rollout date, send out press release, blog post
New Class3 Subroot rollout day
Class3 Subroot Re-sign - Press Release (English)
June 04, 2011
New signatures for CAcert-Class 3-Subroot-certificate - Changes for users of CAcert-Certificates
CAcert is going to re-sign its Class 3-certificate on June xxth with a new SHA256-based signature. The MD5-based signature on the old certificate is seen as not 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 such as Firefox and Thunderbird may experience errors when these programs try to verify such certificates.
In order to avoid warnings, webmasters and users of CAcert's Class 3-certificates will have to download and install the newly-signed certificates from CAcert's website www.cacert.org. The same procedure applies if the Class 3-certificate is used for secure e-mail communication, for code signing, or document signing.
The procedure in short:
Download the new Class 3 PKI Key from http://www.cacert.org/index.php?id=3
- 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)
- Verify the SHA1-fingerprint of the downloaded certificate:
- Example Commandline:
- openssl x509 -fingerprint -noout -in class3.crt
- Or look at the fingerprint when importing the certificate into the webbrowser
- Webmaster now re-create the necessary hash with c_rehash, or the like
CAcert blog - April 2021
We already reported here in January that our Class 3 certificate is being re-signed. This was done a few weeks ago in our data centre in the Netherlands and subsequently tested extensively by our volunteers.
The new Class 3 certificate can now be downloaded here. In some days we will update the fingerprints and publish the other formats here. We recommend that all users use the new Class 3 certificate immediately, as the old certificate is approaching its expiry date and will no longer be valid after May 20th. Download the new certificate today and install it in your browser, e-mail program or certificate server as required.
All this exciting work (planning, re-signing, testing, communication) was done by volunteers from the CAcert community. They have acquired a lot of expertise over time and have worked their way up in the community. CAcert continues to offer such opportunities to interested and committed people today.
Q: Am I affected ?
- Q: The question most users asks - Am I affected by the Class3 Subroot re-signing ?
- A: most users are affected, being users and members that created class3 client- or server-certs, codesigning certs or certs for document signing. If you do not support any class3 certs you're probably not affected.
Q: What do I have to do ?
Q: Do I have to recreate my class3 certificates ?
- A: No. You only have to download and to re-install the class3 subroot cert from CAcert. Your personal class3 cert still continues working.
Q: My email partner receives a notification that my class3 cert produces an error
- A: Please inform also all your email partners that they have to download the renewed class3 subroot cert and to install it into their email client.
Q: Do my email partners receives a notification too if I have a class1 issued cert ?
- A: If your email partners have installed the public CAcert root (class1) they are not affected.
Q: I have a server cert issued by the CAcert Root as a Class 1. Am I affected ?
- A: You not affected directly, as the Root remains untouched. But you should also download and install the renewed class3 subroot cert. When you receive a class3 issued cert from another user, you will need the class3 subroot cert for verification and to keep the certificate secure chain intact.
Q: I have only installed a class3 issued server cert. Am I affected ?
- A: Yes. You and your users visiting your website will be affected. For you, you will need the class3 subroot cert in order to keep the cert chain path intact. For your users, they will need to be able to verify your class3 issued server cert.
Q: I run a website with one of these class3 certificates. How can I help my users over the transition?
A: One way is to put some download buttons on the site for your users. An example can be found in CAcert's download page.
Probably, we can do more here... example code? Example HTML? Example disclosures?
Q: Why don't you update Class 1-certificate that is also signed using MD5 as well while you're at it?
- A: well, this is one of the next major upgrades on the way to CAcert's Audit.
- The replacement of the Root cert is a big step that depends on a working Escrow method (at this step the 2008 roots ceremony becomes audit fail).
- So therefor we have to develop and deploy a Roots escrow method that will work for CAcert.
This project was discussed in the email@example.com mailing list, but did not yet undergo a risc management test along with risc management tests of alternate escrow methods.
- By Mozillas announcement to no longer support md5 signed subroots after June 30th, 2011, CAcert has to react quickly.
We're also thought to push the new roots and escrow plan, but as said above, the escrow plan did not finish in time, so we had to deploy the intermediate class3 subroot renewal. The renewed class3 subroot rollout process can be seen as a final rehearsal for the New Roots & Escrow project.
- btw md5 signed roots are not affected yet by the Mozilla announcement with deadline set for end of June, 2011. Only md5 signed intermediate certs.
- So thats why we decided to do the subroots renewal first and finshed before the deadline set.
Q: New class3 cert doesn't work, but old class3 subroot does?
- A: You might have an exotic software running that doesn't support sha-256?
Check the Hash algorithm interoperability list.
Q: Why can the root CAcert certificate (class 1) still be signed using the MD5 algorithm?
- A: Move from MD5 to SHA256 signing algorithm has the real impact to certificates starting with the intermediate root one (class 3) downwards - thus this impact apply to all certificates signed by Class 3 Root certificate using the SHA algorithm.
- An excellent explanation by Benny Baumann (BenBE):
- With a Root certificate or sometimes called "Trust Anchor" you do not trust the self-signature (done via MD5) but the actual key material in the public key section of the certificate. Thus it doesn't matter much if a root certificate is signed by CRC32, MD5, SHA256 or Keccak.
- If you don't have the proper public key of the CA you won't be saved by the certificate signed with SHA512 or better.
- So, if you are sure that the public key of the root certificate is correct, then you are protected. [You can figure out the correctness of the root certificate by comparing the fingerprint published against the fingerprint displayed in the root certificate's details.]
- To be secured, you need understand the difference between the Class 1 Root certificate and the Class 3 Root (intermediate) certificate: Class 1 Root - signing algorithm does not matter; the hash algorithm strength becomes important at intermediate (Class3 Root) certificates. Use of the MD5 algorithm is not secure at intermediate certificates and below.
Q: I have noticed that since 20190409 CAcert has published new class 1 and 3 root certificates, signed by SHA256, with serial numbers 00000F (class 1) and 00000E (class 3). How will this affect my use of my previously issued certificates?
- A: The safest way to avoid problems is to replace old root certificates with new ones:
installation of both new root certificates (the procedure described here),
- deleting old root certificates, and
generation of new own certificates or renewal of existing ones (here it is necessary to have private keys or backups of certificates in the form .p12 or .pfx); links to procedures can be found on this page.
- The exchange of the root certificate of Class 1 forced the end of support for all MD5-signed certificates by all browsers. The intermediate class 3 certificate must also be replaced because it contains a reference to the old class 1 root certificate.
- Both (2) public keys and (2) private keys of both roots remain the same. Only the signing algorithm (of the Class1 Root) and link to the parent (of the Class3 Root) have changed.
Q: Validity of the Intermediate Class 3 Root certificate ended on May 20, 2021. What do I have to do?
A: Replace the expired Intermediate Class 3 Root certificate (serial number 00000E) with the renewed Class 3 certificate (serial number 14E228) valid for the next 10 years, as soon as possible. You can find certificate and derivative packages here: new certificates, chain, bundle, Android version. Follow the instructions: replacing procedure.
Add your questions here ...
- Your Question here