CAcert Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001305Main CAcert Websitecertificate issuingpublic2014-09-15 14:072017-04-05 07:54
Reporterwytze 
Assigned Todastrath 
PriorityurgentSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformMain CAcert WebsiteOSN/AOS Versionstable
Product Version2014 Q3 
Target VersionFixed in Version 
Summary0001305: CAcert Class1 root certificate needs to be reissued with an updated CDP and a SHA-based signature
DescriptionThe CAcert Class1 root certificate (THE CAcert root) is suffering from two operational problems:

1. The CDP (CRL Distribition Point) listed in the root cert is
        https://www.cacert.org/revoke.crl [^]
But since we do not want to distribute the (huge) CRL through our main web server but rather through a specialized CRL server, the main web server is redirecting all requests for the above URL to http://crl.cacert.org. [^] It turns out that some validation software, for example Microsoft's CryptoAPI, is unable to deal with such HTTP redirects, and reports a verification failure.

Also, the use of HTTPS in the CDP is *not* recommended, see RFC5280 http://tools.ietf.org/html/rfc5280, [^] in the section Security Considerations:
   When certificates include a cRLDistributionPoints extension with an
   https URI or similar scheme, circular dependencies can be introduced.
   The relying party is forced to perform an additional path validation
   in order to obtain the CRL required to complete the initial path
   validation! Circular conditions can also be created with an https
   URI (or similar scheme) in the authorityInfoAccess or
   subjectInfoAccess extensions. At worst, this situation can create
   unresolvable dependencies.

So the CDP should be http://crl.cacert.org/revoke.crl. [^]

2. The current root cert is signed with a MD5 hash. While from a security point of view, the quality of the hash algorithm used for such a trusted cert does not matter, from time to time rumours and sometimes even software appear which choke about this. A SHA-256 based signature would kill all such issues right away.

Steps To ReproduceIssue 1 can be demonstrated with a command like this on a Windows 7 system:
     certutil -f -verify -urlfetch server.crt
for some CAcert Class3 issued server certificate. Output of the above command has been added as attachment to this bug entry.

Issue 2 is demonstrated somewhat by the currently open Bugzilla issue for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1058812 [^]
Additional InformationThe CAcert Class3 intermediate root certificate has been resigned in 2011 to deal with the MD5 issue (for this cert, being intermediate, it was truly a blocking problem). A similar procedure could be used to resign the CAcert Class1 root. This will likely be a much faster process than waiting for the results of the NRE (New Roots & Escrow) project.
Tagscertificates
Reviewed by
Test Instructions
Attached Fileslog file icon crl-redirect-issue.log [^] (5,274 bytes) 2014-09-15 14:07
? file icon Global Sign.p7b [^] (936 bytes) 2014-10-04 09:58

- Relationships
related to 0001254fix availableBenBE Update the signed PGP-Message containing the fingerprints of CAcert 

-  Notes
(0005486)
felixd (updater)
2015-11-25 23:53

There exists a procedure now that will fix this problem:
https://github.com/CAcertOrg/cacert-procedures/tree/master/rootResignSHA256 [^]

It was executed on test data on the FrosCON.
The following Audit report documents this execution:
https://wiki.cacert.org/Audit/Results/session2015.4 [^]

Currently the resulting files (re-singed test certificate, intermediate files, etc) are kept with Board that should soon release them to the public.

Therefore we should soon (after enough review) be good to go for the real certificate.
(0005492)
felixd (updater)
2015-12-14 21:58

We noticed problems related to keeping the serial of the Certificate. We therefore need to adjust the serial number to circumvent "reused issuer and serial"-errors when the Browser has both certificates (i.e. one installed and the other via the SSL Handshake)

I therefore propose:
https://github.com/yellowant/cacert-procedures/commit/a73faf1dbd8d88ebc490bd182db8c4c9e0dccaf2 [^]
(0005495)
cilap (reporter)
2016-02-05 09:50

the issue has more pressure in the meanwhile.

On Java and Eclipse I am getting:
svn: E175002: SSL handshake failed: 'java.security.cert.CertificateException: Certificates does not conform to algorithm constraints'

Since oracle has enforced the default handling of rejecting MD2 and MD5 certificates, any SSL connection on Ubuntu 14.04 is failing in combination with a Java VM.
Sadly the implementation is so stupid, that all certificates are getting read in added to the trust store during first connection. And all certificates are checked, not only the once which should be checked on the chain from the server cert up to the root.

Is there any plan on reissuing the root certificate with a SHA fingerprint and to get rid of MD5withRSA

A workaround - but only working till next java update - is to change

vi /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security

and to change to this:

#jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

#jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

But this is from security perspective not really nice, that CaCert is still working on his root cert on a "obsoleted" algorithm.

Hope I could help some guys with my report and the workaround description
(0005512)
reinhardm (updater)
2016-03-14 17:00

Today I added the new roots into the browser.
I am running OpenSUSE and firefox. The roots installed by a mouseckick with no problems. I tried several logins where certificate login is required. All woreked well.
I removed the old roots and made a login to https://bugs.cacert.org [^] with no problems.
I will try further on different browsers and OS versions.
(0005542)
bjobjo (reporter)
2017-04-04 16:12

Hello,
I increased the priority and severity.
Firefox is not accepting any more the Root Certificate, so we have to add an exception for every site that uses CA Cert Authority.

The ticket was opened in 2014 and we still don't have a new root cert.

The whole reputation of CAcert is in danger if the root certs are not secure.

Please do urgently fix this.
Current firefox message for example:

wiki.cacert.org uses an invalid security certificate. The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure. Error code: SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED

- Issue History
Date Modified Username Field Change
2014-09-15 14:07 wytze New Issue
2014-09-15 14:07 wytze File Added: crl-redirect-issue.log
2014-09-15 14:23 wytze Steps to Reproduce Updated View Revisions
2014-09-15 14:23 wytze Steps to Reproduce Updated View Revisions
2014-10-03 07:43 wytze Description Updated View Revisions
2014-10-03 07:44 wytze Description Updated View Revisions
2014-10-04 09:58 Ruel Print Tag Attached: certificates
2014-10-04 09:58 Ruel Print File Added: Global Sign.p7b
2015-11-25 20:47 INOPIAE Relationship added related to 0001245
2015-11-25 20:47 INOPIAE Relationship deleted related to 0001245
2015-11-25 20:47 INOPIAE Relationship added related to 0001254
2015-11-25 23:53 felixd Note Added: 0005486
2015-12-14 21:58 felixd Note Added: 0005492
2016-02-05 09:50 cilap Note Added: 0005495
2016-03-14 17:00 reinhardm Note Added: 0005512
2017-04-04 16:12 bjobjo Note Added: 0005542
2017-04-04 16:12 bjobjo Priority normal => urgent
2017-04-04 16:12 bjobjo Severity minor => major
2017-04-05 07:54 wytze Assigned To => dastrath


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker