View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000665 | Main CAcert Website | certificate issuing | public | 2009-01-03 14:57 | 2013-01-15 07:57 |
| Reporter | AlainKnaff | Assigned To | Uli60 | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 2011 Q2 | ||||
| Summary | 0000665: Intermediate level-3 certificate is MD5-signed | ||||
| Description | In 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. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Reviewed by | |||||
| Test Instructions | |||||
|
|
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. |
|
|
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 Roberto |
|
|
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. |
|
|
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 CACert.org. 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 CACert.org - Issue a new Class 3 Certificate, not using vulnerable signing algorithm like MD5 - 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 |
|
|
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, CACert.org 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. |
|
|
help appreciated |
|
|
Sorry for bothering you. |
|
|
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. |
|
|
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.) |
|
|
project finished in May/June 2011 https://wiki.cacert.org/Roots/Class3ResignProcedure/Migration https://wiki.cacert.org/Roots/Class3ResignProcedure and the rollout 2011-06-10 class3 subroot rollout day http://blog.cacert.org/2011/06/518.html |
|
|
project finished in May/June 2011 https://wiki.cacert.org/Roots/Class3ResignProcedure/Migration https://wiki.cacert.org/Roots/Class3ResignProcedure and the rollout 2011-06-10 class3 subroot rollout day http://blog.cacert.org/2011/06/518.html |
| 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 |
