View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001305||Main CAcert Website||certificate issuing||public||2014-09-15 14:07||2018-04-18 21:37|
|Platform||Main CAcert Website||OS||N/A||OS Version||stable|
|Product Version||2014 Q3|
|Target Version||Fixed in Version|
|Summary||0001305: CAcert Class1 root certificate needs to be reissued with an updated CDP and a SHA-based signature|
|Description||The 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
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
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 Reproduce||Issue 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 Information||The 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.|
crl-redirect-issue.log (5,274 bytes)
Global Sign.p7b (936 bytes)
There exists a procedure now that will fix this problem:
It was executed on test data on the FrosCON.
The following Audit report documents this execution:
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.
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:
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
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
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.
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
New signed roots are tested on multiple platforms, see here: https://lists.cacert.org/wws/arc/cacert-board/2018-04/msg00014.html
Some people reported to use the certificates for years without any problems.
Any person left in the software team is welcome to announce where people can continue working.
|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|
|2018-04-18 21:37||dops||Note Added: 0005586|