Category Archives: Systems

CAcert erneuert Stammzertifikate

CAcert hat endlich die Stamm- und Class 3-Zertifikate von der alten MD5-Kodierung auf die moderne SHA-256 aktualisiert. Ihre Browser werden uns wieder mögen! Die neuen Zertifikate wurden am 10. April an “den üblichen Orten” installiert. Sie können auf unsere Homepage https://www.cacert.org gehen, und auf der rechten Seite, drei Zeilen von oben, finden Sie “Root Certificates”. Der kurze Weg dorthin ist https://www.cacert.org/index.php?id=3.v

Wir möchten uns bei allen Mitgliedern des Softwareteams für die geleistete Arbeit bedanken. Alle Teams bestehen aus Freiwilligen. Wenn Sie die Arbeit des Software-Teams, einschließlich der Überprüfung, unterstützen möchten, spenden Sie bitte, um diesen Service weiter zu betreiben. Danke.

Stability of e-mail verification strongly improved

The e-mail verification on the CAcert web server has recently led to repeated support requests. An analysis of the log files in our data center showed that the corresponding error occurred more frequently. So we have to conclude that many CAcert users have been negatively affected. In order to avoid further negative effects, an emergency
patch was deemed necessary by the Critical System Administrator Team.

The standardised review and testing of the emergency patch implemented yesterday is carried out by the regular teams in the aftermath, which can result in a formal blessing for this patch or a request for additional code or configuration changes. We would like to thank the Critical System Administrator Team for their quick and decisive action. All teams consist of volunteers. If you want to support the work done by the Critical System Administration Team and the review by the Software Team, please donate, to continue to run this service. Thank you.

E-Mails signieren ist eine sichere Sache

Nach Angaben des deutschen Bundesamtes für Sicherheit in der Informationstechnik sind die von CAcert propagierten Methoden der digitalen Signatur und der E-Mail-Verschlüsselung eine sichere Sache – selbstverständlich bei korrekter Implementierung und Konfiguration.

Sicherheit von e-Mail Clients (Stand Sommer 2018)

Sicherheit von e-Mail Clients (Stand Sommer 2018)

Die nebenstehende Übersicht zeigt die Sicherheitsstufe der bekanntesten E-Mail-Clients. Aber was ist, wenn Ihr Korresponenzpartner eine Software mit einer roten Flagge verwendet? Kennen Sie denn die Software, die andere benutzen? Diese Fragen zeigen einmal mehr, wie wichtig das Vertrauen in der Kommunikation ist. Weitere Informationen über das Vertrauensnetz (Web of Trust) von CAcert.

Neben dem sorgfältigen Umgang mit dem geheim zu haltenden privaten Schlüssel kann auch die Sicherheit der verwendeten E-Mail-Programme und deren Konfiguration entscheidend.

  • Lassen Sie E-Mails im HTML-Format grundsätzlich nicht anzeigen oder generieren.
  • Insbesondere die Ausführung von aktiven Inhalten, d.h. die Anzeige von E-Mails im HTML-Format und das Nachladen von externen Inhalten, sollte ausgeschaltet werden.
  • Bietet ein E-Mail-Anbieter über die Einstellungen seiner Webmail-Anwendung die Möglichkeit dazu, sollten auch hier entsprechende Maßnahmen ergriffen werden.

Für sensible Informationen, die per E-Mail versendet werden müssen, kann das folgende Verfahren angewendet werden: Entschlüsseln Sie S/MIME- oder PGP-E-Mails in einer separaten Anwendung außerhalb Ihres E-Mail-Clients. Entschlüsseln Sie eingehende verschlüsselte E-Mails durch Kopieren und Einfügen des Chiffretextes in eine separate Anwendung, die die Entschlüsselung für Sie übernimmt. Auf diese Weise können die E-Mail-Clients keine Exfiltrationskanäle öffnen. Dies ist derzeit die sicherste Option mit dem Nachteil, dass der Prozess stärker involviert wird.

Auch Webmail ist sicher, wenn Sie Mailvelope oder PEP verwenden.

CAcert.org ist eine gemeinschaftsgeführte Zertifizierungsstelle, die kostenlos Zertifikate für die breite Öffentlichkeit ausstellt. Diese Zertifikate können verwendet werden, um E-Mails digital zu signieren und zu verschlüsseln, Benutzer zu authentifizieren und zu autorisieren, die sich mit Websites verbinden, und um die sichere Datenübertragung über das Internet zu gewährleisten. CAcert hat mehr als 360 000 Nutzer, wird von Freiwilligen betrieben und durch Spenden finanziert.

Spenden Sie die Kosten für 25 Zertifikate (5€)                 Spenden Sie einen freien Betrag          Spenden Sie die Betriebskosten des Rechenzentrums für 1 Woche (50€)                             IBAN DE50 2019 0003 0008 5478 07 “CAcert”

Updates for blog and bugs

We just updated some of our servers to the latest updates:

https://blog.cacert.org/ to the latest WordPress-release.

https://bugs.cacert.org/ to the latest mantis-release.

Furthermore the client certificate login on https://bugs.cacert.org was activated by today for Class-3 certificates. To login you have to enter your username or email-adress of your mantis-account.

Trying to login to https://bugs.cacert.org/ using an unknown email-adress will NOT create a new account: You have to create an account first using the email-adress, which is listed in your client certificate. If you already have an account at https://bugs.cacert.org/ you may change the email-adress of your account to the first email-adress in your client-certificate.

If the certificate-authentication fails (no matter, if you use no client certificate, an expired one or a certificate, which does not match your email-adress) you can use the normal “classic” username/password-credentials to login.

If you try to use a Class-1-client certificate, you currently will may probably receive an error-message like “ERR_BAD_SSL_CLIENT_AUTH_CERT”. In this case please login without a client certificate or create a Class-3-certificate.

In case you face any issues don’t hesitate to contact us for help.

Kind regards,

dirk astrath (CAcert blog admin/CAcert software assessor)

Certificate Login for CAcert wiki

Within the last days I ran some tests using the certificate login for https://wiki.cacert.org/.

This evening I activated this function on our wiki server.

Trying to login to https://wiki.cacert.org/ using an unknown email-adress will NOT create a new account: You have to create an account first using the email-adress, which is listed in your client certificate.

If the certificate-authentication fails (no matter, if you use no client certifcate, an expired one or a certificate, which does not match your email-adress) you can use the normal “classic” username/password-credentials to login.

While installing the client certificate login for CAcert wiki I updated the root-certificate there to the resigned one.

Kind regards,

Dirk Astrath (CAcert wiki admin)

Successful Root-Re-Sign

On March 12th 2016 CAcert performed the Root Re-Signing at our data center in Ede, NL. After the initial attempt[1] had to be postponed on short notice.

The process followed the procedures that are available in the Wiki[2]/SVN[3] along with the tooling[4] used.

The re-signing was conducted by two CAcert critical administrators, a secure-u access engineer, and supervised by CAcert’s internal auditor.
Its execution has been announced on the cacert-systemlog mailing list[5]. The execution report by the critical team has been published there too[6]. The report of the auditor is published in our Wiki[7].

We want to send special thanks to all who helped in preparing and testing the procedures and tools for the process and thus made this smooth execution possible.

CAcert Inc. board tried to have the part for creation of the needed software to be held in public but was overruled by some of the involved teams.

As the re-signed root certificates are available to CAcert the next steps are to publish them to the public. This will need some time as the software team needs to prepare the code changes[8][9][10] and have them reviewed. Once this is done the publishing of the re-signed root certificates will be announced on the blog and all community members will get informed via e-mail.

[1] https://blog.cacert.org/2015/12/re-signing-root-certificate/
[2] https://wiki.cacert.org/Roots/Class1ResignProcedure
[3] https://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/implementation.txt
[4] https://github.com/CAcertOrg/cacert-procedures/tree/root-resign-sha256/rootResignSHA256
[5] https://lists.cacert.org/wws/arc/cacert-systemlog/2016-03/msg00001.html
[6] https://lists.cacert.org/wws/arc/cacert-systemlog/2016-03/msg00002.html
[7] https://wiki.cacert.org/Audit/Results/session2016.1
[8] https://bugs.cacert.org/view.php?id=1305
[9] https://bugs.cacert.org/view.php?id=1254
[10] https://bugs.cacert.org/view.php?id=1194

CAcert fingerprints via DNSSEC

Recently we got several questions about automated installers for our certificates. While the new ca-cacert package in Debian Testing is a nice way for a verified installation it isn’t perfect. One issue is the initial download of the certificates when the source package is built by the maintainer; the second issue is that not everybody is using Debian.

As for a long time there was no way to automate the check of the trust anchor with tools you already have we used cryptography to make it work: DNSSEC. While you can’t directly download the certificates directly from DNS – the information would be to huge and hardly manageable – you still get enough information to bootstrap the verification from DNS. All you need is a way to query and validate TXT RRs from DNS, a way to download files via HTTP and a way to calculate some hashes.

The information about the fingerprints is stored in the DNS zone _fp.cacert.org – the underscore indicates non-host information. For each generation of root certificates a new sub-directory will be created. The current one is “g1”. To list all available certificates of a specific generation you can query the label _certs for that sub-directory given a DNS query for _certs.g1._fp.cacert.org yielding the two names “root class3” as the certificates. Each of those references in turn provides both an URL (“_url”) and a set of fingerprints (_md5, _sha1, _sha256) needed for the verified download of that certificate. To download the current (g1) root certificate you’d thus look for the download URL at _url.root.g1._fp.cacert.org and verify the SHA2-256 fingerprint given at _sha256.root.g1._fp.cacert.org. Fingerprints are always uppercase and without any delimiters.

For further technical details have a look into the Wiki [1]

[1] https://wiki.cacert.org/HowToDocuments/FingerprintsViaDNSSEC

Next language translated to 100%

Special thanks to alaks who made Czech the sixth language which is now available with a 100% translation rate. In addition I want to thank all translators who did a tremendous work over the past years.

To show how far the various languages have been translated here a short statistic overview covering languages with more than 30% of progress

Language Progress
Spanish 100%
German 100%
French 100%
Italian 100%
Dutch 100%
Czech 100%
Portuguese (Brazil) 83%
Swedish 64%
Hungarian 43%
Finnish 37%
Japanese 36%

It would be great if even more people could be helping to translate the software. We are especially looking for Portuguese (Brazil), Swedish, Hungarian, Finnish, Japanese. Of course any help for the other languages that CAcert is offering is appreciated.

If you want to help just create an account on CAcert’s translation server
http://translations.cacert.org

For more information look at
https://wiki.cacert.org/Translations
or join the translation mailing list
https://lists.cacert.org/wws/info/cacert-translations

Thanks to all who already helped with the translation!

CAcert Community Agreement (CCA) Rollout finished

[German Version below]
A long lasting software project – the CCA rollout – is nearing its end!

With today’s software update the last step for the CCA Rollout was deployed.

From now on every member who wants to use his CAcert account needs to have his CCA acceptance recorded.

The software has already been tracking this for some time which means that most active members will have their acceptance recorded by now. The CCA acceptance is recorded when:
– creating a new account
– entering an assurance for the assurer and the assuree
– creating a new certificate (client, server, GPG)

THE NEWS is that, for all users for whom no acceptance is yet recorded, a redirect to the CCA acceptance page is now forced. Once the CCA acceptance is recorded, this page will not be shown again.

Some historical facts:
The foundation was laid in 2007 by developing the policies and the CCA. The rollout started in 2009 by introducing the CCA to the community. In summer 2009 the acceptance of the CCA was required for creating a new account but it was not recorded.
In 2012 the acceptance of the CCA was required while entering an assurance but it was not recorded.
Starting from September 2013 the acceptance is recorded both on creating an account and while issuing a new certificate.
Since January 2014 the acceptance is recorded when entering an assurance too.
In September 2014 a new CCA was accepted by Policy Group.

[German Version]
Ein lange währendes Software-Projekt – der CCA-Rollout – nähert sich dem Ende!

Mit dem heutigen Software-Update wurde der letzte Schritt des CCA-Rollouts vollzogen.

Ab sofort wird für jedes Mitglied beim Login abgefragt, ob die Zustimmung zur CCA vorliegt. Falls nicht wird diese beim Anmelden erfragt und eingetragen.

Die Software zeichnet schon seit einiger Zeit bei diversen Aktionen die CCA-Zustimmung auf:
– Anlegen eines neuen Benutzerkontos
– Beim Eintragen einer Assurance sowohl für den Assurer und den Assuree
– Beim Erstellen eines neuen Zertifikats (Client, Server, GPG)

Wichtig: ab jetzt muss jeder User, dessen Zustimmung zur CCA noch nicht aufgezeichnet wurde, der CCA einmalig explizit zustimmen. Liegt bereits eine aufgezeichnete Zustimmung zur CCA vor, entfällt die explizite Aufforderung zur Zustimmung.

Einige historische Angaben:
Gestartet wurde das Projekt im Jahr 2007 mit dem Erstellen der Policy-Dokumente und der CCA. Das Rollout wurde 2009 mit der Veröffentlichung der CCA begonnen.
Ab dem Sommer 2009 wurde die Zustimmung zur CCA beim Anlegen eines neuen Kontos verpflichtend. Diese Zustimmung wurde allerdings nicht aufgezeichnet.
Seit 2012 wurde die Zustimmung zur CCA Bestandteil der Assurance. Diese Zustimmung wurde nicht in der Software aufgezeichnet.
Ab September 2013 wurde die Zustimmung zur CCA beim Anlegen eines neuen Kontos und bei der Erzeugung eines Zertifikats aufgezeichnet.
Seit Januar 2014 wird die Zustimmung auch beim Eintragen einer Assurance protokolliert.
Im September 2014 wurde eine neue Version der CCA durch die Policy Gruppe verabschiedet.