Author Archives: inopiae

CAcert root certificates included in the Replicant (Android) distribution

Leave a reply

The Android distribution Replicant has recently decided to include the CAcert root certificates in default installations.

Replicant logo

Replicant was started as a pragmatic way to achieve software freedom on mobile devices, providing a fully free version of Android. Over the years, support for a dozen of different mainstream devices was added.
However, most of these devices are severely flawed when it comes to software freedom, privacy and security. Thus, it was decided to focus the development effort of Replicant for a few specific devices that perform better regarding those aspects, instead of trying to catch up with the latest mainstream devices. Replicant is sponsored and supported by the Free Software Foundation.

For further details on the inclusion status of CAcert’s root certificates in other OS distributions see wiki.cacert.org/InclusionStatus

Assurance Party in Dresden am 10. Februar 2015

Leave a reply

Im Hackerspace in Dresden findet am 10. Februar 2015 ab 19:00 eine CAcert Assurer Party statt.
Dies ist sicherlich eine gute Gelegenheit für alle Interessierten aus dem Raum Dresden assured zu werden und das CAcert Web of Trust enger zu weben.

Näheres findet sich auf der Webseite des C3D2.

ATE Freiburg, 2015-02-02

1 Reply

Freiburg i. Breisgau panorama
Am Montag, 2. Februar 2015 findet in den Räumen des Karma Indian Palace in Freiburg das nächste ATE in Deutschland statt.

  • Was hast du auf dem CAP Formular hinzuzufügen, wenn du Minderjährige überprüfst ?
  • Warum solltest du dir die 3 Buchstaben: R/L/O einprägen ?
  • Wie verhälst du dich, wenn du ein fremdes Ausweis-Dokument zum ersten mal prüfst ?

Antworten auf diese und andere Fragen erhaltet ihr auf dem Assurer Training Event.
Bringt geeignete Lichtbildausweise für Assurances mit.

ATE-Freiburg findet statt:

Karma Indian Palace
Starts: 2015-02-02 19:00
Duration: 3 hours:
Bertoldstrasse 51-53
Freiburg, Baden-Wuertemburg
79098
DE

Registrierung: Ich moechte am ATE-Freiburg teilnehmen

Vielleicht treffen wir uns ja da.

Mit bestem Gruß vom Events Team!

Weitere Infos:
ATE Freiburg im CAcert Wiki

CAcert at FOSDEM 2015, Jan 31st – Feb 1st

Leave a reply

FOSDEM, the Free and Open Source Software Developers

CAcert and secure-u e.V. will be present at FOSDEM 2015, the Free and Open Source Software Developers’ European Meeting, on January 31st – February 1st.

If you want to help at our booth, register yourself on our events wiki page for FOSDEM 2015 planning.

CU at FOSDEM …

Selection of hash algorithm during certificate creation

1 Reply

[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;

[German]
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.

CAcert appoints internal auditor

Leave a reply

[German version below]

CAcert gets down to business to the next step for reopening the audit process and has appointed Benedikt Heintel as internal auditor in last december. The goal is the acceptance of CAcert as trustworthy certificate authority. Benedikt Heintel cares for the compliance of internal process flows with the rules and thereby for the reliability and trustworthiness of the CA overall. With the beginning of this year Benedikt Heintel has started with the first checks within the scope of the internal audit.
Quite a while ago CAcert has appointed co-auditors who check the quality of CAcerts’ web-of-trust with which identities of persons are verified. With this check co-auditors do the preliminary work for the internal auditor. These to different subject areas are the basis of CAcert and its secure certificates.

CAcert-PM-Internal-Auditor-en

[German version]

CAcert macht Ernst mit dem nächsten Schritt zur Wiederaufnahme des Audit-Verfahrens und hat im vergangenen Dezember Benedikt Heintel als internen Auditor ernannt. Ziel ist die Anerkennung von CAcert als vertrauenswürdige Zertifizierungsstelle. Benedikt Heintel kümmert sich um die Einhaltung sauberer Prozessabläufe bei CAcert und damit um die Vertrauenswürdigkeit der Arbeit der CA insgesamt. Anfang des Jahres hat er mit den ersten Überprüfungen im Rahmen des internen Audits begonnen.
Vor geraumer Zeit hatte CAcert bereits Co-Auditoren ernannt, die das CAcert-Web-of-Trust prüfen, mit dem die Identität von Personen sichergestellt wird und dem internen Auditor auf diese Weise zuarbeiten. Diese zwei unterschiedlichen Themen machen zusammen erst CAcert und seine sicheren Zertifikate aus.

CAcert-PM-Interner-Auditor-de

Server downtime on Thursday 14 November 2013 from 16:00 – 17:00 UTC

Leave a reply

Due to maintance service there will be a short internet connection downtime for ALL CAcert internet services for about 5 min during the given time period. (see https://lists.cacert.org/wws/arc/cacert-sysadm/2013-11/msg00003.html)

We appologize for any inconvience.

 

 

Information about an email regarding the certificate renewal through a reseller / Information über E-Mails zur Zertifikatserneuerung durch einen Reseller

Leave a reply

[German version below]

A German CAcert Community member received an email from a German certificate reseller, in which the reseller offered to do the renewal of the CAcert certificate through his website. Furthermore he offered a discount of 5% of the price.

This email is incorrect as the reseller is not able to renew the certificate nor is he able to grant a discount on the price as CAcert certificates are already free of costs.

CAcert was able to find an agreement with the reseller that he will not send these kind of emails anymore.

If you receive a similar email please inform CAcert via support@cacert.org so that the appropriate steps can be taken.

[Deutsche Version]

Ein CAcert Community Mitglied hat eine E-Mail von einem deutschen Zertifikats-Reseller erhalten, in der dem Member angeboten wurde, das CAcert Zertifikate über die Webseite des Reseller zu verlängern. Des Weiteren will der Reseller 5% Rabatt auf den Preis des Zertifikats gewähren.

Diese E-Mail ist inhaltlich falsch, da der Reseller weder das Zertifikat verlängern noch einen Rabatt auf den Preis gewähren kann, da die CAcert Zertifikate schon kostenfrei sind.

CAcert hat erreicht, das der Reseller sich verpflichtet hat, das Versenden solcher E-Mails in Zukunft zu unterlassen.

Sollten weitere E-Mails dieser Form auftauchen, informiert bitte CAcert über support@cacert.org darüber, so dass die entsprechenden Schritte eingeleitet werden können.

Sicherheit der privaten Schlüssel von CAcert-Zertifikaten / Safety of private keys of CAcert-Certificates

2 Replies

[English Version below]

In den Medien[1] wurde jetzt bekannt, dass US-Regierungsbehörden zur Entschlüsselung der verschlüsselten Kommunikation möglicherweise die privaten Schlüssel von Dienstanbietern fordert.

Bei der Zertifikatserstellung mit CAcert-Zertifikaten verlassen die privaten Schlüssel niemals den Rechner des Anwenders und werden damit nicht etwa an CAcert übertragen. CAcert kann deshalb die privaten Schlüssel auch nicht weitergeben. Dadurch stellen Zertifikate von CAcert ein Verfahren dar, mit dem sichere Kommunikation gewährleistet werden kann.

Pressemitteilung Schlüsselsicherheit

[1] http://heise.de/-1924012

[English Version]
Currently US press[1] spreads information that government organizations demand private keys from service providers for decrypting secret communications.

When creating certificates with CAcert, private keys never leave the system of the user, and therefore are not transmitted to CAcert. Hence, private keys cannot be disclosed by CAcert and thus certificates from CAcert provide a means to safeguard a secure communication.

Pressrelease Key Safety

[1] http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-on-web-firms-for-master-encryption-keys/