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).

Project timeline

Press Release

English - German - Dutch - French - Spanish - Russian

česky - English - German - Dutch - French - Spanish - Russian

Class3 Subroot Re-sign - Press Release (English)

CAcert-Press Release

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 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:

  1. Download the new Class 3 PKI Key from

  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

Q: Am I affected ?

Q: What do I have to do ?

Q: Do I have to recreate my class3 certificates ?

Q: My email partner receives a notification that my class3 cert produces an error

Q: Do my email partners receives a notification too if I have a class1 issued cert ?

Q: I have a server cert issued by the CAcert Root as a Class 1. Am I affected ?

Q: I have only installed a class3 issued server cert. Am I affected ?

Q: I run a website with one of these class3 certificates. How can I help my users over the transition?

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?

Q: New class3 cert doesn't work, but old class3 subroot does?

Q: Why can the root CAcert certificate (class 1) still be signed using the MD5 algorithm?

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?

The safest way to avoid problems is to replace old root certificates with new ones:

  1. installation of both new root certificates (the procedure described here),

  2. deleting old root certificates, and
  3. 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.


  1. 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.
  2. 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.

Add your questions here ...

FAQ/Class3Resign (last edited 2020-02-01 15:21:43 by AlesKastner)