View Issue Details

IDProjectCategoryView StatusLast Update
0000665Main CAcert Websitecertificate issuingpublic2013-01-15 07:57
ReporterAlainKnaff Assigned ToUli60  
Status closedResolutionfixed 
Fixed in Version2011 Q2 
Summary0000665: Intermediate level-3 certificate is MD5-signed
DescriptionIn regards of the new RapidSSL/MD5 issue, this will pop up all kinds of warnings when setting it up on a webserver as a chained certificate off the level 1 root.
Please re-issue it as a SHA-1 signed certificate.
TagsNo tags attached.
Attached Files
Class3MD5CACert.png (41,385 bytes)   
Class3MD5CACert.png (41,385 bytes)   
Reviewed by
Test Instructions


parent of 0000946 closedUli60 class3 subroot resign procedure - rollout 



2009-01-03 20:52

reporter   ~0001264

I think this should be solved as part of the integration of the new (audit conforming) certs. In meantime it would be possible to just not off new certs signed by the class 3 one.


2009-11-09 08:19

reporter   ~0001504

Since this issue was not modified sinde Janaury, I loaded a screenshot showing the problems that each site has if using Class3 (or Class1) signed certificates. A new Class3 Intermediate Certificate should be issued as soon as possible (see screenshot)

Kind Regards


Daniel Black

2009-11-09 08:50

reporter   ~0001505

if this is error is displayed for Class 1 certificate then it is an error in the plugin. Root certificates with MD5 integrity on themselves are not a risk to users. If this is the case provide a bug report to the plugin provider.

As you can appreciate, changing a root certificate on a CA where most users need to download a new certificate is not that desirable. As with all security its a cost benefit decision that takes place and at the moment the costs of replacing an Intermediate certificate exceed benefits for both CAcert and all its users.

If you depend on the Class 3 certificate for some purpose this should be installed as a trusted root certificate and a good plugin should then ignore the warnings on this certificate.


2009-11-10 08:32

reporter   ~0001506

I'm not talking about replacing the class 1 root certificate. But as long as certificates are signed with the class 1 certificate, this means that you keep this certificate online and this compromises the trust in Since the class 3 certificate also uses an MD5 signature algorithm and CACert will never be able to take this certificate offline, it should be replaced as soon as possible.

In my opinion following should be urgently done to ensure the necessary quality and the trust in

- Issue a new Class 3 Certificate, not using vulnerable signing algorithm like
- Sign all requests with this new class 3 certificate
- Take the vulnerable Root Class 1 Certificate offline.
- Take the current Class 3 certificate offline as soon as there are no more
  certificates signed with this certificate. Should be possible in 2013.

Would you agree in such an aproach and what measures need to be taken to speed up this approach?

Regards Roberto


2009-11-10 09:58

reporter   ~0001507

If you look at the chain:

Class 1 MD5 ---> Class 3 MD 5 ----> Certificate SHA1
    | | |
 vulnerable vulnerable ok
                          +--> means that this certificate could be generated somewhere else, CACert is compromised

Class 1 MD5 ---> Class SHA1 ----> Certificate SHA1
    | | |
 vulnerable ok ok

As long as CACert issues certificates signed by the class 1 root certificate or by a class 3 intermediate certificate, compromises the whole WOT, since third parties could be able to generate certificates with identical content. As soon as the class 3 certificate is replaced with a not vulnerable certificate an CACert stops issuing Class 1 signed certificates, the trust remains a real trust. We have a nice WOT established and this should not be compromised by weak intermediate certificates.

Daniel Black

2009-11-10 11:13

reporter   ~0001508

Last edited: 2009-11-11 03:33

help appreciated


2009-11-10 11:42

reporter   ~0001509

Sorry for bothering you.


2009-11-23 18:42

developer   ~0001515

Seen in Mozilla Policy Central, today:

In addition to this communication about the .int issue, I will also be sending email to the CAs who have root certificates in NSS that have an outdated signature algorithm (MD2, MD5) and/or a low modulus length (1024). In this email I will be requesting that each CA provide a high level description and timeline of their plan to phase out the corresponding root certificates. I won't be sending this communication to CAs who have already requested that their corresponding roots be removed or disabled.


2009-11-26 11:07

developer   ~0001521

Jacob A wrote to support 20091014 and said this:

If you simply add random data to the serial number or to an alternate field, you make a *targeted* collision much harder to pull off from a practical stand point.

(posted without permission, but I know Jacob, and I make the call.)


2011-06-30 10:17

updater   ~0002075

project finished in May/June 2011
and the rollout
2011-06-10 class3 subroot rollout day


2011-06-30 10:18

updater   ~0002076

project finished in May/June 2011
and the rollout
2011-06-10 class3 subroot rollout day

Issue History

Date Modified Username Field Change
2009-01-03 14:57 AlainKnaff New Issue
2009-01-03 20:52 ph3 Note Added: 0001264
2009-11-09 08:17 mazzo File Added: Class3MD5CACert.png
2009-11-09 08:19 mazzo Note Added: 0001504
2009-11-09 08:50 Daniel Black Note Added: 0001505
2009-11-10 08:32 mazzo Note Added: 0001506
2009-11-10 09:58 mazzo Note Added: 0001507
2009-11-10 11:13 Daniel Black Note Added: 0001508
2009-11-10 11:42 mazzo Note Added: 0001509
2009-11-11 03:33 Daniel Black Note Edited: 0001508
2009-11-23 18:42 iang Note Added: 0001515
2009-11-26 11:07 iang Note Added: 0001521
2011-06-30 10:12 Uli60 Relationship added parent of 0000946
2011-06-30 10:17 Uli60 Note Added: 0002075
2011-06-30 10:18 Uli60 Note Added: 0002076
2011-06-30 10:18 Uli60 Status new => closed
2011-06-30 10:18 Uli60 Assigned To => Uli60
2011-06-30 10:18 Uli60 Resolution open => fixed
2013-01-15 07:57 Werner Dworak Fixed in Version => 2011 Q2