Disabling SSL3 and 3DES support to improve security for CAcert’s users

CAcert intends to disable SSL3 and 3DES support for its main website www.cacert.org by December 1, 2014.

The main CAcert website is currently still supporting the SSL3 protocol for secure connections. However, in https://www.openssl.org/~bodo/ssl-poodle.pdf  it is shown that SSL3 is susceptible to certain cryptograhical attacks. While www.cacert.org does support the recommended TLS_FALLBACK_SCSV option to protect clients with that same protocol option against unintended downgrades to SSL3, this still leaves plain old SSL3 clients vulnerable for the new attack.

Similarly, www.cacert.org is currently still supporting the 3DES cipher suite for encyrpting secure connections. However, this provides only 112 bits of security, which is below the currently recommended number of 128. Hence we should disable it to protect CAcert’s clients.

In practice, the only client known to negotiate SSL3 with www.cacert.org is Internet Explorer 6.0 as found in Windows XP. Thus disabling SSL3 will block https access for these clients only. Similarly, 3DES will only be negotiated by IE 6 and IE 8 running on Windows XP. Since Windows XP is no longer supported by its vendor, and the widely circulated advice to all its users is to switch to a more recent operating system (or switch at least to a more current browser), announcing termination of support for SSL3 and 3DES by CAcert on December 1, 2014 does not seem unreasonable, and is fully in line with our mission to support the security of its users.

If you want to discuss this issue further, please use the bug tracker created for this issue (https://bugs.cacert.org/view.php?id=1314).

CAcert Assurances at the LISA Conference in Seattle, WA, USA, 11 November 2014

The 28th Large Installation System Administration conference (aka. Lisa 2014) will be meeting November 9-14 in Seattle, WA, USA. We have held a CAcert Birds-of-a-Feather (BoF) session at several previous LISA events. The CAcert Assurance BoF at LISA 14 will be Tuesday evening November 11th. This session is open to the public. Full details are posted on the event page on the CACert Wiki:


We will start with a presentation to introduce CAcert to newcomers. We will also discuss recent changes to the CCA (CACert Community Agreement), the TTP Assurance Program and other changes.. We will have several assurers there to do initial assurances. Mutual assurances are encouraged for getting practice and for answering questions. And there is the added benefit of earning experience points.

If you are in town for the conference or you live in the area, please join us to learn more about free digitial certificates available through CAcert.org.

Assurance-Point auf dem Open-Source-Day 2014 am 22.10. in Hamburg

Open Source Day 2014Der Hamburger Open-Source-Day 2014 ist in Hamburg im Zeitraum 10:00 Uhr – 14:00 Uhr geöffnet. Details sind unter [3] zu finden.

Dieser Assurance-Point ist interessant für alle die ihren Status innerhalb der CAcert-Communitiy verbessern wollen. Dabei ist jeder, ob CAcert Assurer, CAcert Assuree/Member, CAcert Interessierte, Einsteiger oder Unentschlossener herzlich willkommen. Es gibt die Möglichkeit für Assurees/Members Assurance-Punkte zu erwerben, für Assurer sich Erfahrungspunkte zu verdienen und sich über die CAcert Community zu informieren. Um einen reibungslosen Ablauf der Identitätsüberprüfung zu ermöglichen, wird darum gebeten neben hinreichenden amtlichen Lichtbildausweisen auch genügend ausgedruckte CAP-Formulare, für sich selber und andere, mitzubringen.

Es wird empfohlen, sich vor der Veranstaltung schon bei CAcert [1] zu registrieren, da so der Prozess vor Ort beschleunigt werden kann.
Die Einsicht in die Policies ist unter [2] möglich.

[1] http://www.cacert.org/
[2] http://www.cacert.org/policy/
[3] Open Source Day 2014

Starts: 2014-10-22 10:00 am
Ends: 2014-10-22
Duration: 4 hours:
Beim Strohhause 17

FrOSCon 9 in St. Augustin 23./24. August 2014

For the English version see below.

Auch in diesem Jahr wird CAcert wieder auf der FrOSCon am 23. und 24. August in St. Augustin mit einem Stand vertreten sein.

Sprecht uns auf dem Stand an, um zu erfahren, welche Aktivitäten zur Zeit bei CAcert durchgeführt und geplant sind. Mehr unter wiki.cacert.org/Events/FrOSCon2014

CAcert will be present again with a booth on the FrOSCon in St. Augustin 23th/24th August.

Feel free to come along and ask us what CAcert is doing at the moment and what are the plans for the near future. More see wiki.cacert.org/Events/FrOSCon2014

Downtime for www.cacert.org on July 23, 2014

On July 23, the CAcert webdb server will be unavailable for most services from 10:00 CEST until approximately 11:30 CEST.

The reason for this is the need to convert the database from MyISAM format to InnoDB format, to address https://bugs.cacert.org/view.php?id=1172

We cannot predict exactly how long this conversion will last, but it is estimated to be less than 90 minutes. During this time, the server will remain up and running. The web frontend will also remain up and running, but with very limited functionality only (no user logins), due to the database being offline.

We apologize for any inconvenience caused by this major but necessary operation.

Change when adding an assurance

The software team pushed a new patch to production that has an impact on the way how new assurances have to be entered into the system.

Starting today, besides entering the primary email address further information has to be provided in order to gain access to assurance relevant data of the assuree. Additionally the date of birth of the assuree has to be stated by the assurer, before any data of the assuree is displayed for the assurance process.

This change was made for data protection reasons to ensure nobody is able gain access to personal data entrusted to CAcert by mere guessing of email addresses.

It hopefully will also reduce the number of problems with assurances that contain a wrong date of births.

CAcert applies to become “Interested Party” for the CA/Browser forum

CAcert Inc. board decided with the motion m20140706.3 to apply at the CA/Browser forum [1] as “Interested Party”. The CA/Browser forum is responsible for the guidelines how to use X.509 certificates.

The reasons are:

  • get the latest ideas and hints how the the certificate business is developing
  • get the chance to show how CAcert Web of Trust works and that it might be an alternative for the commercial registry authority approach

CAcert nominated Benedikt Heintel as contact person to the CA/Browser forum.

[1] https://cabforum.org/

The policy group has started a new vote on “CCA – Update” (CAcert Community Agreement)

CAcert-vote p20140709After a long period of inactivity on the policy side, we are back in
in business again.

In February board nominated a Policy Officer (Eva Stöwe) and this was later
confirmed by a Policy Group vote.

At about the same time an intensive discussion regarding changes to the CCA

There are a lot of changes, some of them being just cleanups or
rephrasing, but there are also some bigger changes.

The central changes are:
- The CCA can be accepted by more ways than currently allowed.
– How CCA may be terminated was greatly rephrased, it now also covers
death of members.
– A clear obligation to answer truthfully before and to help arbitration
was added.

If you want to follow the discussion visit the archive on

The actual version of the proposal is located here:

Every community member is also invited to participate by joining the
policy group. Just subscribe the mailing list cacert-policy@lists.cacert.org

The state of the voting can be found at https://wiki.cacert.org/PolicyDecisions#p20140709

The voting stays open until Sunday 27th of July 2014.

Selection of hash algorithm during certificate creation

[German version below]
The software team recently released a patch which enables users to choose the hash algorithm used during the creation of a new certificate. Since the deprecation of SHA-1 earlier this year only certificates using SHA-512 for the signature could be issued. Now the available choices have been extended to SHA-256, SHA384 and SHA-512 where SHA-256 is the current default. Due to some organisational issues, the choice of SHA-384 will for now silently use SHA-512 instead.

The default hash algorithm has been selected as SHA-256 for compatibility with Debian systems using GNU TLS 2.12, which fails to operate correctly when a certificate signed with anything but SHA-256 has been used. This decision may be reviewed in the near future once the new Debian (Jessie) is released.

The move away from SHA-1 had to be made as the National Institute of Standards and Technology (NIST) disallowed certificates with SHA-1 algorithm issued after 2013-12-31 [1]. If your software still needs a SHA-1 signed certificate, get in contact with your vendor and request a software update, to cope with SHA-2 signatures. The use of SHA-1 had been deprecated since 2011.

N.B.: The software team still needs your help to test the remaining parts of the patch and get it released in a timely manner. The same is true for all our other patches that are waiting to be released. Feel free to drop by in the IRC channel or ask your questions on our mailing list.

[1] http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf;

Das Software-Team hat einen Patch herausgegeben, der es Nutzern erlaubt, die Stärke des bei der Erstellung des Zertifikates benutzten Hash-Algorithmus auszuwählen. Seit Anfang des Jahres ist die Nutzung von SHA-1 geächtet. Daher wurden die Zertifikate bisher mit SHA-512 ausgestellt. Jetzt stehen die Algorithmen SHA-256, SHA-384 und SHA-512 zur Auswahl, mit SHA-256 als Standardeinstellung. Aus organisatorischen Gründen, benutzt SHA-384 intern derzeit allerdings noch SHA-512.

Der Standard-Hash-Algorithmus wurde mit SHA-256 gewählt, um kompatibel mit Debian-Systemen zu sein, die noch GnuTLS 2.12 nutzen und Schwierigkeiten haben andere, als mit SHA-256 signierte Zertifikate zu verwenden. Diese Vorgabe wird überarbeitet werden, sobald das nächste Debian (Jessie) veröffentlicht wird.

Der Wechsel weg von SHA-1 wurde notwendig, da Zertifikate, die nach dem 2013-12-31 ausgestellt werden und SHA-1 nutzen, vom National Institute of Standards and Technology (NIST) als unsicher eingestuft werden [1]. Falls Ihre Software noch ein Zertifikat mit SHA-1 erfordert, fragen Sie bei dem Hersteller Ihrer Software nach, warum die Software noch nicht angepasst wurde, da SHA-1 bereits seit 2011 nicht mehr eingesetzt werden sollte.

P.S.: Das Software-Team benötigt weiterhin Unterstützung, um die verbleibenden Teile dieser Änderung zu testen, damit diese zeitnah freigegeben werden können. Das gleiche gilt auch für weitere Änderungen, die auf ihre Freigabe warten. Jeder ist eingeladen, sich in unserem IRC-Channel zu melden oder auf unserer Mailingliste seine Fragen loszuwerden.