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 – 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 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 and verify the SHA2-256 fingerprint given at Fingerprints are always uppercase and without any delimiters.

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


Availability of CAcert Root Certificates on Linux Distributions

After the inclusion of CAcert in Debian has been a quite complicated story for the past few years we are glad to announce that there’s a new package in the Debian Sid (unstable) branch: ca-cacert. This package has been created and will be maintained by Dmitry Smirnov. This package became necessary after Debian decided to remove CAcert from its main certificate store provided by the package ca-certificates in early 2014 [1].

Our goal is to promote awareness and education on computer security through the use of encryption, specifically by providing cryptographic certificates. These certificates can be used to digitally sign and encrypt email, authenticate and authorize users connecting to websites and secure data transmission over the internet. Any application that supports the Transport Layer Security (TLS) or the somewhat older Secure Socket Layer Protocol (SSL) can make use of certificates signed by CAcert, as can any application that uses X.509 certificates, e.g. for encryption or code signing and document signatures.

The re-inclusion – even if just as a supplementary package – allows users of Debian and its many derivatives to securely access and install our certificates. Using this path for installation of our root certificates a major attack vector during installation has been mitigated by providing an additional, verified means to get an authenticated copy of our root certificates. Another possibility to verify our certificates after download has been prepared recently and will be documented soon.

CAcert is still pursuing to become audited and thus available in the default browser and OS trust stores.

We thank all people who were involved in creating and providing this package and hope for a constructive future development. Furthermore we like to thank the maintainers of the openSUSE package who made sure our root certificates have been available for the past years [2]. Also we want to thank all other package maintainers for other OS helping to provide a safe anchor for our certificates[3].

Currently our Wiki editors are working on HowTo documents [4, 5].


CAcert does NOT allow video assurances

Recently support received a question if video assurance can be used to replace a face-to-face meeting in an assurance. The short answer is that currently the rules of CAcert do NOT allow video assurances. [1, 2]

One aspect of the face-to-face meeting why you need to meet the assuree in person is such that you can check security features of the presented documents. This check can not be done with video communication like e.g. FaceTime, Google+ Hangout, Jitsi, Skype [3] as verifying documents includes getting a feel for the presented documents as well as checking security features, that are not or not easily transferable with video conferencing.

In case CAcert sees any signs of assurance entries that hint to having been conducted as video assurances these cases will be reviewed (by arbitration) AND removed from the system if they are found to be invalid.


Assurer Training Event in Dresden 2015-05-12

Am Dienstag, 12. Mai 2015 findet in den Räumen der Chaos Computer Club Dresden 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-Bremen findet statt:

Chaos Computer Club Dresden im robotron-Bürokomplex
Starts: 2015-05-12 18:00
Duration: 3 hours:
Lingnerallee 3
Dresden, Sachsen

Registrierung: Ich moechte am ATE-Dresden teilnehmen

Vielleicht treffen wir uns ja da.

Mit bestem Gruß vom Events Team!

Weitere Infos:
ATE Dresden im CAcert Wiki

CAcert bei den Linuxwochen Wien 2015 (7.-9. Mai)

CAcert wird dieses Jahr auf den Linuxwochen mit einem Stand vertreten sein.

Dort können Fragen rund um CAcert und zur Nutzung von Zertifikaten gestellt sowie Assurancen durchgeführt werden.

Am 7. bis 9. Mai wird CAcert in der Fachhochschule FH Technikum Wien, Hochstädtplatz 6, 1200 Wien Brigittenau zu finden sein.

CAcert bei der VHS Amberg-Sulzberg am 8. Mai 2015

CAcert wird sich anlässlich der Eröffnung des Stützpunkts für Verbraucherbildung
an der VHS Amberg-Sulzbach am 8. Mai 2015 präsentieren.
Dazu wird Daniel Salcher einen Kurzvortrag zu CAcert halten.
Des Weiteren wird es eine Stand zur Information und zum Assuren geben.

Freitag, 8. Mai 2015, ab 14:30 Uhr
in der Volkshochschule Amberg-Sulzbach (LCC),
Obere Gartenstraße 3, Sulzbach-Rosenberg

Assurer Training Event in Bremen 2015-05-05

Logo of Embassy of Nerdistan in BremenAm Dienstag, 5. Mai 2015 findet in den Räumen der Embassy of Nerdistan in Bremen 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-Bremen findet statt:

Embassy of Nerdistan in den Räumen des AUCOOP Bremen e.V. (2. OG)
Starts: 2015-05-05 19:00
Duration: 3 hours:
Weberstr. 18
Bremen, Bremen

Registrierung: Ich moechte am ATE-Bremen teilnehmen

Vielleicht treffen wir uns ja da.

Mit bestem Gruß vom Events Team!

Weitere Infos:
ATE Bremen im CAcert Wiki

Certification de clés PGP et CAcert à Paris 1er, le 20 avril 2015

Date: lundi, le 20 avril 2015, à 19:00 heures

Lieu: Hôtel Novotel Les Halles, 8, place Marguerite de Navarre, 75001 Paris

  • Métro :
    Ligne Station
    1 Châtelet, sortie n°6
    11 Châtelet, sortie n°6
    14 Châtelet, sortie n°6
    4 Châtelet, sortie n°6
    A Châtelet-les-Halles
    B Châtelet-les-Halles
    D Châtelet-les-Halles
  • Bus :
    Ligne Station



Nous vous proposons le 20 avril comme date de rencontre pour valider vos identités CAcert.

3 accréditeurs pouvant donner 105 points présent. Si vous pouvez aussi donner des points, manifestez vous.

Pour plus de détails, voir

CAcert auf den Grazer Linuxtagen am 24.-25. April

CAcert wird dieses Jahr auf den Grazer Linuxtagen mit einem Stand vertreten sein.

Dort können Fragen rund um CAcert und zur Nutzung von Zertifikaten gestellt sowie Assurancen durchgeführt werden.

Das Programm:
Freitag, 24. April 2015, 14:00–19:00 Uhr (Workshops)
Samstag, 25. April 2015, 9:00–19:00 Uhr (Vorträge & Projektstände)
Wo findet es statt:
FH Joanneum, Alte Poststraße 149, 8020 Graz
Anfahrt: Straßenbahnlinie 1 oder 7 (Haltestelle: Alte Poststraße)
Eintritt: frei

New Software: The Heart of Gold

Today’s post is the last part the blog series about our “New Software”.
1. Rewriting the software driving our site
2. Modernising the Web Frontend
3. The Heart of Gold
This part will conclude our small blog series on the “New Software” and will provide some more details especially regarding the signer and some aspects regarding the certificate issuance not further mentioned before.

The Heart of Gold

With the last two posts and we talked about why we are rewriting our software and what the main changes on the user side will be. In today’s post we’re going to look behind the scenes to see how the signer “the heart of the system” works.

While looking at the existing Perl code the developing team decided that it is worth to do a code rewrite and refactoring for the signer too. This decision was made after analysis showed that the current code will most likely not be easily adjustable to satisfy our future requirements. Even with the most basic requirements that were layed out for the new software the code was failing several aspects and thus, instead of heavily rewriting things, it makes less work to ignore the existing code base and start anew. Going that way also allowed the team to freely choose the language best suited their needs. So for the signer C++ was chosen as coding language.

One aspect of immediate interest is and will be the new root structure which is currently under development in a separate project called “NRE” (New Root and Escrow). This structure requires the signer side to work with sub roots to sign the certificates. The primary root will be only used to sign the intermediate and sub (“profile”) roots. There will be a set of sub roots for the different kinds of certificates that CAcert is offering. One sub root for email, signing and login client certificates, one for code singing certificates, one for server certificates, one for organisation client certificates, one for organisation server certificates and so on. This also removes the differentiation between different “Classes” as they have never fit the CAcert model perfectly (see also ) Instead the use of these certificates will be defined by certificate profiles selected in the front end which are passed onto the signer.

To avoid the problem with large CRL files, we are facing with the existing roots, there is the idea of having all the sub roots signing a set of further sub roots which will be used for a shorter time span of e.g. three to six months so that the CRL files will stay a reasonable size of below 1 MiB. That is also an additional complexity for the signer to handle, as the signer has to choose the correct sub root to sign the current task automatically. Also the management of the different CRLs would be hard with something similar to the current signing software.

Apart from the actual certificates used for signing there is the actual technology to handle all the cryptography. One aspect here is to be able to switch the crypto backend to what we think will be the best one at that time, i.e. OpenSSL, GnuTLS, WolffSSL or whatever provides the security guarantees we require. This will allow CAcert to react quickly if severe problems are found in a crypto backend. Currently only the use of OpenSSL is implemented, but interactions with OpenSSL have been kept together so that in implementation of another crypto backend is feasible.

Being able to switch out parts of the signer software with other libraries provides us with more flexibility at compile time and for reusing the code for testing. Together with the use of unit tests, that are run under Jenkins, there is a good change to see problems in the source code before things hit the life system. Also having the continuous integration aspect with Jenkins it allows us to check that current changes won’t break existing behaviour unless we want to have that behaviour actually changed.

Furthermore a new protocol for the communication between the signing system and the database has been developed. First of all, all communication gets wrapped into TLS to have an encrypted and authenticated connection, where both sides identify themselves to each other. Inside this secure channel a record-based protocol – similar to what is used to flash firmware to microcontrollers and EPROMs – is used to transmit all information required for the signing task. Building on the information received in those records the signer rebuilds the signing request and verifies the information (and their proofs of freshness) to be correct.

After a few further checks the signer hands this data to the crypto backend. This way all user entered data (common name, subject alternative names, organisation name, etc) stays UTF-8 encoded during the whole process. Also, due to the integrated library, there is no need to re-encode user input in specific formats for an external tool to process the signing task.

The protocol also contains several safety checks to make sure that only verifiable and properly embedded information is sent to and processed on the signer. One of them is a “proof” protocol to transmit facts about the state of the data affecting the signing task. On the other hand the protocol has been kept scalable so that it can be easily extended for future needs, e.g. if additional information or commands need to be processed.

For issuing a new certificate the signer client fetches all necessary information from the database. It then opens a connection to the signer and transmits all data for the certificate starting with the CSR or SPKAC-request for the certificate. When all data is transmitted the client asks the signer to sign the current certificate (“sign”). The signer checks the requests and signs it, but instead of returning the resulting certificate, it answers with a log over the current signing session (“setLog”). When the client confirms that the log has been saved (this could be implemented with a hash over the log beeing transmitted back in the “logSaved”-record) the signer transmits the new certificate (“respondCertificate”) and a code name of the sub CA that was actually used to sign this request (“signingCA”). Now the signer client writes the certificate, its serial, issuance and expiry date and possibly more data back to the database and closes this signing session.

For revoking certificates the signer client fetches serials of the same sub-ca (the certificate that actually signed the certificate to be revoked) and sends them ( with “addSerial”) over a fresh connection with the information which CA it is (as argument to “revoke”) to the signer. The signer fetches the current date and time, marks all given certificates as revoked on that instant, resigns the CRL and returns the exact revocation date and time, the X509_Algorithm Structure used to resign the CRL, the actual signature and the “lastUpdate” and “nextUpdate” fields from the CRL (as argument to “revoked”). That data is ASN1 encoded so it can easily be split afterwards. The client updates his local CRL accordingly with the given dates and the given signature and verifies that the signature is valid again. If the updated CRL validates the revocation process has successfully completed and both CRLs (on the signer, and on client) are in sync again. If the CRL validation fails, the client requests the full CRL to be transmitted in order to get the CRLs back in sync. This is not expected to happen in normal production service.

The internal code names for the various parts of the new software are based on the characters of the Michael Ende’s novel MOMO. Based on the story we are calling our web front end Gigi, as – like in the story – it leads your way. Cassiopeia on the other hand is a wise, trusty turtle with a hard shell to protect its secrets and thus the perfect name for our signer.

If you are interested in our work you can find the source code of the new software as well as other CAcert projects mirrored on . To help with development of our software please contact the development mailing list
There will be a live presentation with the new software as well as the possibility to discuss the ideas with the core developers of the new software at the CAcert booth on the CLT2015.