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.

Cryptography, digital signature or data integrity – any ideas?

The PR team is working on creating new public relation material. One of the projects is to have new rollups and posters for events.basic layout for event rollup
The idea is to have a set of themes / designs to visualize the topics in one picture / drawing each:
– cryptography
– digital signature
– data integrity

The size of your picture should be max. width 70cm / 26.6″ and height 120cm / 47.2″.
See the basic layout for the rollup on the right.

If you have any ideas please send them preferably as svg, png, or jpg to licenced as CC-BY-SA until 2015-04-06.

CAcert at Chemnitzer Linux-Tage 2015

Logo Chemnitzer Linux-tage 2015CAcert wird auch in diesem Jahr auf den Chemnitzer Linux-Tagen (CLT) am 22. und 23. März 2015 mit einem Stand vertreten sein. Dieser befindet sich rechts hinter der Information.

Es wird ein Präsentation der “New Software” am Stand geben, bei der die aktuelle Entwicklung direkt gezeigt wird und jeder die Möglichkeit erhält, diese einmal auszuprobieren und mit den Entwicklern zu diskutieren.

Auf jeden Fall kann man auch am Stand Informationen rund um CAcert erhalten und assured werden.

Näheres ist auf der CAcert Wiki-Seite zum CLT 2015 und auf der Homepage des CLT und dem Plan zu finden.

New Software: Modernising the Web Frontend

With today’s post we continue the blog series about our “New Software”.
1. Rewriting the software driving our site
2. Modernising the Web Frontend
3. The Heart of Gold
As outlined in the previous post there were quite a few things to decide upfront, which doesn’t make actual implementation any easier as we will see today when going into more details with the web front end. Beware of the details though as this (and the next part) are going to be much more technical.

Modernising the Web Frontend

With the last post New Software: Rewriting the software driving our site you got a glimpse of why we are rewriting our software. Today we’re going to elaborate a bit more on the front-end part and will provide more in-depth information on the technical changes and news to expect. The main aim of the rewrite is to strengthen the security and to improve maintainability of the source code. On the other hand we aim to avoid showing too much changes to our users.

With choosing Java as the language for the front end we are taking the advantage to develop a modular design based on Object Orientated Programming. This should help to get a better transparency of the source code, which the old PHP source both was lacking. In addition to these basic aspects the use of Java allows for easier packaging of the final application as well as for reworking the code when there is need to do so. This can be aided with several refactoring and code management tools available for Java as the general tooling support is quite good here. One such example is the nice integration of static analysis using tools such as FindBugs to automatically find issues that a static analysis of the code can find, e.g. null-pointer dereferences, misused APIs, thread safety issues, …

As a continuous integration process units test are introduced to test all new features directly while writing the source code. Our tool for this is Jenkins. The unit tests do not only cover the new applied features, the whole source code is tested as well, so that side effects can be discovered in an early stage of the development. Right now there are about 250 test cases running, with many more still to come.

Another important change is the separation from the source logic and the HTML output. While PHP encourages you to intermix HTML templates and executable source, it threatens you to bite you whenever you are not cautious enough. To make it harder to be careless we decided to reduce the power our templates have: The templates are reduced to simply printing values and very easy conditions and loops. An additional safety measure with the template engine is the implicit escaping that is caused for every string that should be printed – if you need to output preprocessed HTML to the template you have to explicitly state so in the template.
The HTML output is based on HTML5 and formatted with CSS3 using LESS to support responsive design patterns and accessibility. Additionally we completely switched to use Unicode, having UTF-8 as our standard encoding.

There is also a change in the URL structure. The new URL concept is based on REST and can easily be scaled to a RESTful API in the future. No more ?id=42 or other meaningless numeric IDs for the various actions.

To avoid SQL injections we opted to use implicit escaping for all data sent to or retrieved from the database; similar to the implicit escaping used with all inputs to the template engine. This way we can process raw data internally and have the necessary conversions and escaping operations whenever the context of the information changes allowing us to concentrate on the actual processing and logic instead of caring about the security implications.

Looking at security we invested some work in reworking the way authentication is handled. While the old system only supported password-based authentication and client certificate login using X.509 there was no chance of combining multiple factors as a requirement for successful login to an account. This lack of multi-factor authentication caused some trouble in the past. To avoid this and to provide more flexibility for our users we want to change the authentication to allow for any combination of login methods, as long as at least one “strong” authentication (like password login, secure token, client certificate) in addition to an optional “multi-factor” authenticator is provided (additional factors may be older TOTPs, single access tokens, ping tokens).

To raise the security level of the password storage we will use with SHA2-256 to store passwords in a save manner. This ensures an attacker can’t easily parallelise brute-forcing or attacking the password hashes as SCrypt guarantees through its design that an attacker needs a certain memory and amount of computational power to calculate the hash value. A switch to SCrypt-SHA2-512 or other even more secure methods later on is already laid out in the source code and can be activated transparently upon next successful password login of the user.

While discussing the authentication of the user let’s take a short break to look at some other security features the new system will implement. As one of the most critical parts with transmitting any information on a secure channel is getting the channel secured we’ll be activating HSTS or also known as HTTP Strict Transport Security. Using HSTS as a baseline we ensure that everyone visiting the site to access sensitive information can benefit of protection from eavesdroppers for future visits. Even if this brings no security on its own – except for mitigating SSL stripping attacks, it sets up the stage for the second mechanism: HPKP. Using Public Key Pinning we not only enforce browsers who had a once good, encrypted channel, to enforce encryption on subsequent visits (as HSTS does), but in addition also tell what valid keys for such a good connection are. Like with HSTS also HPKP suffers the issue of being inline to the connection and thus vulnerable to a determined attacker. With DNS-based Authentication of Named Entities (or for short: DANE) we introduce a second vector for verification a browser can use when determining acceptable security certificates. And even with these mechanisms deployed there is still a lot of room for determining if the connection is secure, some of which will sure follow in a later step.

But apart from ensuring the browser of the user talks to the correct server it is equally important to secure the display of information against mistakes our systems might be doing. One of the options we choose to implement was restricting ourselves using CSP (Content Security Policy) and a separation of our content delivery hosts. Basically to avoid an attacker executing any JavaScript not authorized we split execution of scripts to a subdomain which only carries static script files, while all content that might be under control of the attacker (e.g. the field containing the user name) is delivered on a strictly No-JavaScript subdomain. Thus even XSS was possible it would harden ourselves ill side-effects. To additionally avoid being framed (no pun intended) we will be including various HTTP headers like X-Frame-Options to explicitly prohibit loading within a frame on the attackers website. Also we ask the user’s browser to handle files in the way we specify which, among others, includes disabling of MIME type sniffing. With these security mechanisms in place it raises the bar for an attacker quite a lot and – on the other side – allows us self-testing the application as CSP allows for reporting violations on its rule set. Explicitly triggering such reports can even test the browser and thus determine the protection level the application can expect from the client (e.g. if images which are included for the sole purpose of triggering a report are loaded rather than ignored we know that the client does not properly implement CSP).

Another change will be introduced for the registration of domain names. In the future there are at least 2 ownership checks required to activate a new domain with our system. There will be a choice between the long known email pings, the verification with a DNS-TXT entry, verification with reading HTTP-content from a special addressed file and the verification with CAcert server certificates securely running on internet based services like HTTP, SMTP or XMPP. The way those tests were designed ensures that someone just observing traffic might notice the checks taking place, but won’t gain any information from such observations. All identifiers in these tests are chosen randomly thus simply searching for a particular filename or content of a file with an internet search engine won’t provide you any means to impersonate that domain.

In addition to the checks during the registration of a domain there will be continuous checks to check a domain is still active. If less then two tests succeed the account owner will be informed that there is a verification problem that should be solved within a grace period before all certificates containing that domain will be revoked automatically.

All posts send from the new software will be digitally signed using S/MIME to ensure that these messages are really generated by the CAcert systems and are not SPAM. This has been planned for a long time for the existing code but we did not manage to introduce it there due to complexity and security when realising this function in PHP.

One last but not least interesting feature to be mentioned is the rework of the certificate issuing process in the front end. While in the old software the process was to get all data from the database and check it against the values given in the CSR, this is turned around for the new software: Now first the given CSR is checked and the data gained from the CSR is checked against the records in the database to pre-fill the certificate request form. Changing the way the issuing works we were able to simplify the interface while allowing for new features to come.

After the discussion on why we choose our coding framework and today’s post about the ideas for the new front end the next post will have a closer look at the details of the ideas of the new signer.

CAcert at CeBIT 2015

German version below

On the world’s largest computer fair, the CeBIT in Hannover, DE, CAcert should not be missing out. From March 16th through March 20th Assurers and Assurees are meeting each other at 12:00 CET outside Hall 2 in direction of the green. In case of bad weather the assurances take place directly at the glass front of Hall 2 outside under the roofing.

More details can be found in the Wiki.
CeBIT meeting point

Further events with attendance of CAcert — with a booth at OpenSource events — can be reviewed in the CAcert wiki at

Auf der weltgrößten Computermesse, der CeBIT in Hannover, darf auch CAcert nicht fehlen. Vom 16. bis 20. März treffen sich Assurer und Assurees täglich ab 12 Uhr vor Halle 2 in Richtung der Grünfläche. Bei schlechtem Wetter finden die Assurances direkt an der Glasfront von Halle 2 außen unter der Überdachung statt. Mehr Informationen finden sich im Wiki.

Weitere Veranstaltungen mit CAcert-Beteiligung – mit eigenem Stand auf OpenSource-Veranstaltungen – sind im CAcert-Wiki unter einsehbar.