Tag Archives: Software

Creating client certificates with CSR now possible for Org Accounts

A fix for a long standing issue has recently been installed at the CAcert main server: Now finally it’s possible to create a client certificate from a Certificate Signing Request (CSR) in the user interface for Organisation (Org) Accounts.

For those who don’t have an idea what I am talking about, an Org Account is a user interface for administrators of companies and other organisations who got themselves assured with a CAcert Org Assurance.

Until recently, client certificates in an Org Account could only be created by using the browser feature to create a key pair and signing request in one go. This usually has the consequence that the administrator has access to the private key of the certificate, and has to send the private key and a password (hopefully secure) to the user the certificate is intended for.

While this is not that unusual in an organisation environment, it is not considered a clean solution.

The new feature to create a certificate from a CSR now allows much better solutions. Not only that the administrator does not need access to the end user’s private key at all, it’s now possible to create solutions where an organisation end user can create her own keys and CSR at the organisation’s website, while the administrator only confirms the validity of the request, gets the certificate from CAcert and posts it on a website for the user to download into her browser.

Especially in company settings CAcert certificates can productively used even though the root certificate is not included in browsers by default. Many companies use private CAs, for example to issue certificates which allow employees to securely log on to web applications. Now it’s possible to outsource the CA management to CAcert and just use an Org Account to issue certificates.

In my opinion CSR certificate creation is an important step to make CAcert certificates much more practical to use in company settings! Thanks to everyone involved in implementing this feature!

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.

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.

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;

[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 enforces rules for signing certificates / CAcert verschärft die Regeln beim Signieren von Zertifikaten

[German version below]

The software team released a patch which forces the user to use a key strength of at least 2048 bit for the certificate. The key strength is given by the CA/Browser forum baseline requirements [1].
During the test prior of the implementation it showed up, that keys using DSA with at least 2048 bit are not processed by the used OpenSSL configuration.
Since there is no easy way to verify the used key parameters for ECDSA are in conformance with the needed security level it has been decided not to support the singing of ECDSA keys until there is a proper solution.
Therefore no keys using DSA or ECDSA will currently be signed.
If a certificate is renewed and an error pointing to the key strength is given you need to create a new certificate with the apropriate key strength and method which is currently only RSA with at least 2048 bit key strength.

[German]
Das Software-Team hat einen Patch veröffentlicht, der den Anwender auffordert, bei der Erstellung eines neuen Zertifikats mindestens eine Schlüsselstärke von 2048 Bit zu verwenden. Diese Einschränkung beruht auf den Baseline Requirements des CA/Browser Forum [1].
Während des Testens vor der Auslieferung ist aufgefallen, dass mit der benutzten OpenSSL-Konfiguration DSA-Schlüssel mit einer Schlüsselstärke von mindestens 2048 Bit nicht korrekt signiert werden können.
Da ferner für ECDSA keine einfache Möglichkeit besteht, die verwendeten Schlüsselparameter auf das Sicherheitsniveau hin zu überprüfen, wurde entschieden, bis eine vertretbare Lösung gefunden ist, keine weiteren ECDSA-Schlüssel zu signieren.
Daher können bis auf weiteres keine DSA- und ECDSA-Schlüssel signiert werden.
Falls beim Erneuern eines Zertifikates ein Fehlerhinweis mit dem Thema nicht ausreichende Schlüsselstärke angezeigt wird, muss ein neuer Schlüssel mit der passenden Methode und Schlüsselstärke erzeugt werden. Zur Zeit sind das nur RSA Schlüssel mit mindestens 2048 Bit Schlüsselstärke.

[1] https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf

CAcert software development reaches milestone for CCA rollout

[Dutch, French, German, Italian, Spanish versions below]
The CAcert Software Development Team completed work on the important milestone for the rollout of the CAcert Community Agreement (CCA) [1]. The agreement of the CCA is recorded throughtout the software ([2], [3].

Therefore each member needs to agree to the CCA within the software on the following occasions:
– creating a new member account
– assuring another member, getting assured
– creating a new client certificate, a new server certificate or a new gpg certificate

Sometime in the future the software will prompt each user, who did not accept the CCA until up to that date while logging into the system. After that date you only will be able to log into the software after accepting the CCA.

[Dutch version]
Het CAcert Software Development Team heeft een belangrijke mijlpaal
bereikt voor het uitrollen van de CAcert Community Agreement (CCA) [1].
Aanvaarding van de CCA wordt nu door middel van de software systematisch
vastgelegd ([2], [3]).

Daarom moet elk CAcert lid nu de CCA aanvaarden in de software op de
volgende momenten:
– bij het maken van een nieuwe account;
– bij het invoeren van een assurance;
– bij het aanmaken van een nieuw client certificaat, een nieuw
server certificaat of een nieuw gpg certificaat.

Binnenkort zal de software aan elke gebruiker die tot dat moment de CCA
nog niet aanvaard heeft, bij het inloggen verzoeken om in te stemmem met
de CCA. Vanaf dat moment kan er alleen nog ingelogd worden door leden
die expliciet de CCA aanvaarden.

[French version]
L’equipe de développement de logiciels CAcert a franchit une nouvelle étape pour le déploiement de l’Accord de la Communauté CAcert.

L’équipe de développement de logiciel CAcert a achevé ses travaux sur l’étape importante pour le déploiement de l’accord de la Communauté CAcert (CCA) [1]. L’acetptance du CCA est maintenant enregistré par le logiciel. [2], [3]

Par conséquent, chaque membre doit accepter le CCA dans le logiciel sur un des cas suivants:
– lors de la création d’un nouveau compte de membre
– après l’accréditation d’un autre membre, en l’inscrivant dans le système
– lors de la création d’un nouveau certificat de client, un nouveau certificat de serveur ou d’un
nouveau certificat GPG

Dans les jours à venir, le logiciel invitera chaque utilisateur, qui n’a pas encore accepté le CCA lors d’une connection au système, de confirmer qu’il accèpte le CCA. Après cette date, se peut connecter au logiciel que celui qui a accepté le CCA.

[German version]
Das CAcert Software Development Team hat den wichtigen Meilenstein für das CAcert Community Agreement (CCA) [1] Rollout erreicht. [2, 3]

Daher müssen alle Community Member nun an folgenden Stellen innerhalb der Software zustimmen:
– beim Anlegen eines neuen Accounts
– bei der Eintragen der Assurance
– beim Erstellen eines neuen Client Zertifikat, eines neuen Server Zertifikats oder eines neuen GPG Zertifikats

In der näheren Zukunft wird die Software beim Login jeden User, der bis dahin nicht der CCA zugestimmt hat, auffordern der CCA zustimmen. Ab diesem Zeitpunkt wird man sich in der Software nur anmelden können, wenn man der CCA zugestimmt hat.

[Italian version]
Il Team di Sviluppo Software di CAcert ha completato il lavoro su un aspetto
cruciale per il lancio dell’Accordo della Comunità CAcert (CCA) [1].
L’accettazione del CCA è registrata ovunque all’interno del software ([2],[3]).

D’ora in poi ogni membro deve accettare la CCA all’interno del software nelle
seguenti occasioni:
* creazione dell’account di un nuovo membro
* accertamento di un altro membro, accertamento da parte di un altro membro
* creazione di un nuovo certificato client, nuovo certificato server o nuovo
certificato gpg

In futuro il software chiederà ad ogni utente, che non lo avesse ancora fatto,
di accettare la CCA all’accesso nel sistema.
Da quel momento in poi sarà possibile accedere nel software solo dopo aver
accettato la CCA.

[Spanish Verison]
El equipo de desarollo de software terminó el trabajo para alcanzar el importante hito del despliegue del CAcert Community Agreement (CCA) , Acuerdo de la Comunidad CAcert. [1] El acuerdo CCA se registra mediante el software. [2], [3]

Por ello, cada miembro necesita confirmar que acepta el CCA mediante el software en las siguientes ocasiones:
* En la creación de una nueva cuenta de miembro
* Cuando se asegura/certifica a otro miembro, cuando se es asegurado/certificado
* Creando un nuevo certificado de cliente, de servidor o GPG

En un futuro, el software preguntará a cada usuario que no lo haya aceptado hasta ese momento, cuando entre en el sistema. Después de dicho momento, solo se le permitirá el acceso después de aceptar el CCA.

[Links]
[1] http://www.cacert.org/policy/CAcertCommunityAgreement.php
[2] http://svn.cacert.org/CAcert/Events/Public/pics/Big-Masterplan-To-Become-Audit-Ready-20130806.jpg
[3] http://wiki.cacert.org/Software/Assessment

Improvement in CAcert Software

Starting with the recent update there is a field to enter a comment to better identify the different certificates within one’s list of certificates. This comment is only for internal and personal use and it will thus not be available in the certificate.
The comment can be added during the creation process as well as modified for any existing certificates.

CAcert is proud to announce that the Trusted Third Party Programme is back to life

The software team was able to finish the last fixes so that the Trusted Third Party (TTP) programme is working again. At present there are two restrictions:

  • the TTP programme is only rolled out for Australia, Puerto Rico and USA. This means you can only take part if you can visit a TTP in these countries. (All other requests will not be processed)
  • the TTP programme is only able to grant up to 70 assurance points. The TTP TOPUP programme that closes the gap between 70 and 100 assurance points is still under development.)

You find more about TTP in on this wiki page at https://wiki.cacert.org/TTP/TTPuser