• FAQ
• Class3Resign

• česky | english

• To New Roots & Escrow Project - To Class3 Re-sign Procedure

• To Class3 Subroot Fingerprint - Sources - To PR Distribution list for Class3 Re-sign Project rollout

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

Project timeline

• 	Board meeting 2011-05-15 presentation, approval	{g}
  	Motions: m20110515.2 that we upgrade the class-3 root ...	{g}
  	m20110515.3 that we ask the community to prepare a press statement ...	{g}
  2011-05-23	Class 3 subroot re-signed according to procedure by Critical Sysadms Team	{g}
  2011-05-23	Exec report from Critical Team	{g}
  2011-05-25	bug# for source code changes: bug #946	{g}
  May 2011	prepare press release, blog post, members notifications to be presented to board	{g}
  May 2011	prepare support FAQ, present to SEs and support maillist	{g}
  2011-06-05	approval of press release, blog post, members notifications: m20110605.2	{g}
  2011-06-15 - 2011-06-20	proposed class3 subroot rollout date, send out press release, blog post	{g}
  2011-06-10	New Class3 Subroot rollout day	{g}
  end+some days	from our experiences of this project, write up the procedure for rollout, so as to prepare for the Big New Roots Rollout	{0}

Press Release

CAcert blog - April 2021

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 ?

• A: Download the new re-signed class3 subroot cert from the CAcert main website. Depending on what format your application needs, select either the class3 subroot cert type PEM or DER.

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 cacert-roots@lists.cacert.org 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.

Explanation:

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.

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

• CategoryAudit

• CategoryNewRootsTaskForce