Tag Archives: Certificate

Certificate renewing is pending (update & help)

Some of our community members (users) get a problem while they try to renew an existing certificate. The issue is: Certificate renewal is pending for days/weeks.

First of all, CAcert is not a service provider or a company, but a community. We are all in the same boat. We can only achieve our goals together, with your the cooperation of all of us (of all users=members).

One of our volunteer support engineers, a retired gentleman somewhere in Bohemia, wrote, after he watererd the flowers in the garden:
1. Many users use CAcert without any assurance. Until now, their CSRs were signed by Class 1 Root (–> serial # 1xxxxx) and their CSRs/renewals are stuck in a queue now.
2. These users know absolutely nothing about existence Class 1 & Class 3 Roots, as they don’t remember installing root(s), and when creating a new cert, they cannot see the choice Class 1/3, because with <50 assurance points (trust points) it isn’t displayed.
3. Many users do not know about the existence of Wiki, bugs, blog, CATS… websites. Our education possibly fails in this direction.

And from Alsace, a baker who is also CAcert volunteer writes after putting the children to bed: There is a lot of information and many tutorials are at the FAQ at https://wiki.cacert.org How to create a certificate can be found at: https://wiki.cacert.org/HowTo/ClientCertCreate/

Another help message was sent by a CAcert volunteer who works as a bus driver from his mobile phone during the short break at the terminus: To get assurance points, the easyest way is to meet with two (or three) experienced assurers who can then credit you with the assurance (trust) points you need (you need 50 and get 10-35 per assurer). When you are on cacert.org in your account, go to the Web Of Trust: https://www.cacert.org/wot.php?id=12 (here you can enter your town and search for assurers in the area) or: https://www.cacert.org/wot.php?id=1 (here you can click through to choose from about 6000 assurers worldwide).

Thank you very much to all our active community members who helps here and there and gives other community members a hand. Even very little help is helpfull. If e.g. each of the 6000 assurers from the assurer directory helps with something small for 10 minutes per month, that is already 1000 hours of work. That would solve (almost) all problems. Here is how you too can give your CAcert community a hand: https://wiki.cacert.org/engagement

And another volunteer from Sweden points out, that the issue will not go away till the interface is fixed, which is a work that has been started, but not finished. Furthermore, renewing old incorrectly signed certificates will never work again, as we have said we will not fix the broken code for that, as no certificates should ever have been signed that way. We can’t continue signing them incorrectly.

Re-signed Class-3-Certificate – take action now!

English | Deutsch | Français | Español | Fingerprints

English | We already reported here in January that our Class 3 certificate is being re-signed. This was done a few weeks ago in our data centre in the Netherlands and subsequently tested extensively by our volunteers.

The new Class 3 certificate can now be downloaded here. In some days we will update the fingerprints and publish the other formats here. We recommend that all users use the new Class 3 certificate immediately, as the old certificate is approaching its expiry date and will no longer be valid after May 20th. Download the new certificate today and install it in your browser, e-mail program or certificate server as required.

All this exciting work (planning, re-signing, testing, communication) was done by volunteers from the CAcert community. They have acquired a lot of expertise over time and have worked their way up in the community. CAcert continues to offer such opportunities to interested and committed people today.

Alles neu macht der Mai – Neuerungen bei CAcert

Deutsch | Wir haben bereits im Januar an dieser Stelle darüber berichtet, dass unser Class-3-Zertifikat neu signiert wird. Dies ist vor einigen Wochen in unserem Rechenzentrum in den Niederlanden geschehen und anschliessend ausführlich von unseren Freiwilligen getestet worden.

Das neue Class-3-Zertifiat kann jetzt hier heruntergeladen werden. In wenigen Tagen werden wir die Fingerprints als auch die anderen Formate hier an gewohnter Stelle veröffentlichen. Wir empfehlen allen Nutzern, ab sofort das neue Class-3-Zertifikat zu verwenden, da das alte Zertifikate seinen Ablaufdatum entgegenschreitet und dann nicht mehr gültig ist. Laden Sie heute noch das neue Zertifikat herunter und installieren Sie es je nach Bedarf in Ihrem Browser, e-Mailprogramm oder Zertifikatsserver.

Alle diese spannenden Arbeiten (Planung, neu signieren, testen, Kommunikation) wurden von Freiwilligen der CAcert-Gemeinschaft erledigt. Sie haben sich im Laufe der Zeit viel Fachwissen angeeignet und sich in der Gemeinschaft hochgearbeitet. CAcert bietet auch heute interessierten und engagierten Leuten solche Möglichkeiten.

Changez vers le nouveau certificat class 3
Français | Nous avons déjà signalé ici en janvier que notre certificat de classe 3 était en cours de re-signature. Cela a été fait il y a quelques semaines dans notre centre de données aux Pays-Bas et a ensuite été testé de manière approfondie par nos volontaires.

Le nouveau certificat de classe 3 (comme l’ancien) peut être téléchargé ici. L’empreinte digitale va être publié dans les jours à venir ici. Nous recommandons à tous les utilisateurs d’utiliser le nouveau certificat de classe 3 à partir de maintenant, car l’ancien certificat approche de sa date d’expiration et ne sera plus valide. Téléchargez le nouveau certificat aujourd’hui et installez-le dans votre navigateur, votre programme de messagerie ou votre serveur de certificats, selon vos besoins.

Tout ce travail passionnant (planification, re-signature, tests, communication) a été réalisé par des bénévoles de la communauté CAcert. Ils ont acquis une grande expertise au fil du temps et ont gravi les échelons au sein de la communauté. CAcert continue aujourd’hui à offrir de telles opportunités aux personnes intéressées et engagées.

Español | Hace unas semanas, nuestro certificado de clase 3 se volvió a firmar en nuestro centro de datos de los Países Bajos y, a continuación, nuestros voluntarios lo probaron exhaustivamente. El nuevo certificado de clase 3 puede descargarse aquí. La huella dactilar y los demás formatos estarán disponibles en los próximos días aquí. Recomendamos a todos los usuarios que utilicen el nuevo certificado de clase 3 a partir de ahora, ya que el antiguo dejará de ser válido en breve. Instale el nuevo certificado de clase 3 hoy mismo.

Todo este apasionante trabajo ha sido realizado por voluntarios de la comunidad CAcert. CAcert ofrece interesantes oportunidades a las personas interesadas y dedicadas.

Fingerprints | SHA1 Fingerprint = D8:A8:3A:64:11:7F:FD:21:94:FE:E1:98:3D:D2:5C:7B:32:A8:FF:C8
SHA256 Fingerprint = 1B:C5:A6:1A:2C:0C:01:32:C5:2B:28:4F:3D:A0:D8:DA:CF:71:7A:0F:6C:1D:DF:81:D8:0B:36:EE:E4:44:28:69

Browser manufacturers shorten certificate lifetime to one year

From September onwards, HTTPS certificates may only be issued for a maximum of one year.

Reading time: 1 min.

CAcert will adapt the free certificates

The maximum validity of certificates for proof of identity on the web will be further reduced – in the next step to one year. Although a vote on this issue in the CA/Browser Forum failed in September due to resistance from the certification authorities, it is still being discussed. But in March Apple came forward and declared that Safari will only accept certificates issued after September 1, 2020 if they are not valid for more than one year.

Now Mozilla and Google are following suit and creating facts. In the past, terms of 5 years were not unusual. Currently, certificates may still be issued for 2 years (more precisely: 825 days — i.e. plus some grace period). With the renewed tightening, Chrome, for example, delivers an ERR_CERT_VALIDITY_TOO_LONG if a certificate was issued after September 1, 2020 and is valid for more than 398 days.

Revocation broken

The main reason for the constant shortening of the certificate lifetime is the fact that there is no generally functioning revocation mechanism by which a certificate could be revoked. Revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) have proven to be unsuitable and are now switched off by default.

The browser manufacturers still maintain their own internal revocation lists, which they can use to react to acute incidents. But this is a quasi manual procedure that can only cover significant problem cases. Ultimately, the browser manufacturers are now focusing on damage limitation: if, for example, the secret key of a certificate is stolen, an expiration date that is approaching as soon as possible should solve the problem.

No need for action for users

Lets Encrypt, which meanwhile dominates the market, is the pioneer and only issues certificates for 3 months anyway. Renewal is then automated via ACME. According to Mozilla, however, the other certification authorities have also agreed to only issue certificates for 398 days from September 1. In view of the demonstration of power of the browser manufacturers, they probably don’t have much choice.

As a web site operator, you don’t have to do anything else – even if you still have a certificate with a longer validity in operation. The new rule only applies to certificates issued after September 1, 2020.

Les fabricants de navigateurs ramènent la durée de vie des certificats à un an

À partir de septembre, les certificats HTTPS ne peuvent être délivrés que pour une durée maximale d’un an.

CAcert adaptera ses certificats

Temps de lecture: 1 min.

La validité maximale des certificats pour la preuve d’identité sur le Web est encore réduite – dans l’étape suivante à un an. Un vote à ce sujet au sein du CA/Browser Forum en septembre a échoué en raison de la résistance des autorités de certification. Mais en mars, Apple s’est manifesté et a déclaré que Safari n’acceptera les certificats émis après le 1er septembre 2020 que s’ils ne sont pas valables plus d’un an.

Aujourd’hui, Mozilla et Google suivent le mouvement et créent des faits. Dans le passé, des mandats de 5 ans n’étaient pas inhabituels. Actuellement, les certificats peuvent encore être délivrés pour 2 ans (plus précisément : 825 jours — c’est-à-dire plus un certain délai de grâce). Avec le nouveau resserrement, Chrome, par exemple, délivre un ERR_CERT_VALIDITY_TOO_LONG si un certificat a été délivré après le 1er septembre 2020 et est valable plus de 398 jours.

Révocation cassée

La principale raison de la réduction constante de la durée de vie des certificats est le fait qu’il n’existe pas de mécanisme de révocation généralement opérationnel permettant de révoquer un certificat. Les listes de révocation (CRL) et le protocole OCSP (Online Certificate Status Protocol) se sont révélés inadaptés et sont désormais désactivés par défaut.

Les fabricants de navigateurs tiennent toujours leurs propres listes de révocation internes, qu’ils peuvent utiliser pour réagir à des incidents graves. Mais il s’agit d’une procédure quasi manuelle qui ne peut couvrir que les cas problématiques importants. En fin de compte, les fabricants de navigateurs se concentrent maintenant sur la limitation des dommages: si, par exemple, la clé secrète d’un certificat est volée, une date d’expiration qui approche le plus tôt possible devrait résoudre le problème.

Pas de nécessité d’action pour les utilisateurs

Lets Encrypt, qui domine entre-temps le marché, est le pionnier et ne délivre de toute façon des certificats que pour 3 mois. Le renouvellement est ensuite automatisé via ACME. Selon Mozilla, cependant, les autres autorités de certification ont également accepté de ne délivrer des certificats que pour 398 jours à partir du 1er septembre. Compte tenu de la démonstration de puissance des fabricants de navigateurs, ils n’ont probablement pas beaucoup de choix.

En tant qu’exploitant de site web, vous n’avez rien d’autre à faire – même si vous disposez toujours d’un certificat d’une durée de validité plus longue en service. La nouvelle règle ne s’applique qu’aux certificats délivrés après le 1er septembre 2020.

Liebe Frau Merkel

Liebe Frau Merkel, liebe CDU, liebe SPD, liebe gehackten deutschen Politiker

Wie konnte das nur passieren mit diesem Datenklau im Dezember? Da hatten Sie doch die besten Services und die teuerste Software – und nun das! Das ist ärgerlich, in der Tat. Dabei müssen wir uns zwei Dinge bewusst sein:

  • Erstens: Weil eine Mehrheit der Wähler Ihnen das Vertrauen geschenkt hat, heißt das nicht zwingend, dass Sie in IT-Fragen den besseren Durchblick haben, als die Mehrheit der Wähler. Nur, wenn Herr Kreti oder Frau Pleti gehackt werden, interessiert das niemanden einen alten Hut, bei Ihnen kommt es groß in den Nachrichten und ist womöglich von strategischer Bedeutung.
  • Zweitens: Die großen Anbieter sind amerikanische Großfirmen, wie Microsoft, welche von ihrer Regierung verpflichtet sind, denen eine Hintertür offen zu lassen. Hintertüren sind jedoch immer Schwachstellen.

Die Alternative ist quelloffene Software. Fairerweise nicht einfach irgendwo heruntergeladen und gratis genutzt, sondern sowohl finanziell, als auch in der Weiterentwicklung unterstützt. Spielen wir einmal mit den Gedanken und stellen alle IT-Spezialisten des Bundes und der Länder einen haben Tag pro Woche frei, um an einem spezifischen Projekt mitzuentwickeln. Das können Standardanwendungen sein wie LibreOffice (statt Microsoft Office) oder dienstspezifische Spezialsoftware. Wer der Einfachheit halber – wie Ihre Kollegen in Bern – seine Verwaltung mit Skype telefonieren lässt, kann gerade so gut jedes e-Mail per CC an Donald Trump senden lassen.

Sie haben Recht, wenn Sie einwenden, dass quelloffene Software nicht per se sicherer ist, als kommerzielle Angebote; aber da die Quellen offen liegen, ist die Wahrscheinlichkeit wesentlich höher, dass Mängel entdeckt werden – vor allem auch, wenn Ihre besten Spezialisten regelmäßig danach suchen und wie oben skizziert Zeit haben, mit anderen Spezialisten sie dann umgehend zu beheben. Da sparen Sie nicht viel Geld, bekommen jedoch einen wesentlich höheren Mehrwert für die eingesetzten Steuergelder.

In einigen Schweizer Kantonen sind Clouddienste für Schulen aus Sicherheitsgründen verboten. Auch wenn wir keine Freund von Verboten sind, ist der Ansatz insofern bedenkenswert, den Mehrwert der ständigen Erreichbarkeit gegen die Sicherheit aufzuwiegen. Die Antwort wird ebenso unbequem sein, wie bei den Passwörtern: je einfacher, desto unsicherer (oder umgekehrt: Sicherheit kann man nicht aus dem Ärmel schütteln).

Freundliche Grüße vom anderen Ende des Erdballs

PS. Wenn Sie uns im Rahmen Ihrer Opensourcestrategie für eine gewisse Zeit einen Auditor und einen Programmierer abdetachieren, wird Ihre Regierung schon bald über die sichersten Zertifikate verfügen.


Unterstützen Sie unsere Freiwilligen, indem Sie sich an den laufenden Kosten unseres Rechenzentrums in den Niederlanden beteiligen. Mehr Sicherheit, weniger Phishing dank digitaler Signatur mit kostenlosem X.509-Zertifikat.

Spenden Sie die Kosten für einen knappen 1 Tag (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”

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)

Safer Internet Day 2016

On 2016-02-09 is this year’s Safer Internet Day[1] asking its participants to “Play your part for a better internet!”

The Safer Internet Day was first celebrated in 1999 to strengthen the awareness for security within and on the internet.

CAcert’s share in this effort is providing everybody the means to protect their communication by sending encrypted emails or using free client certificates for authentication.

So take a moment and think about taking part in one of the several events and help to promote email encryption with CAcert S/MIME certificates.

And stay safe on the internet!

[1] https://www.saferinternetday.org/

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;

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.

Sichere E-Mails mit Zertifikaten von CAcert / Secure emails with certificates from CAcert

[English Version below]

Sicherer Mailverkehr ist zurzeit in aller Munde. Mittlerweile stehen mehrere kostenpflichtige Dienste zur Verfügung mit denen Anwender größtenteils pseudo-sichere oder bei einigen Angeboten teilweise auch sichere Mails versenden können.
Tatsächlich sichere E-Mails bedeutet den Einsatz von Ende-zu-Ende-Verschlüsselung, doch auch die kostenpflichtigen Anbieter bieten an dieser Stelle auch keine Hilfestellung für den Benutzer. Wichtig ist, dass die Verschlüsselung im E-Mail-Programm des Anwenders eingerichtet wird.
Übersehen wird dabei oft, dass Sicherheit kostenlos zu haben ist. Und dafür braucht auch kein neues E-Mail-Konto eingerichtet werden: Client-Zertifikate von CAcert integrieren sich nahtlos in alle gängigen E-Mail-Programme unter Windows, Mac und Linux.

[English Version]
Secure sending and receiving of email is currently highly demanded. There are a number of paid services nowadays offering pseudo-secure (which turns finally out to be non-secure) or sometimes even secure mails.
But secure mails actually mean end-to-end-encryption. But even services with costs are not able to support users at this point. Important is, that encryption is set up in the mail program of the user.
It is often overseen, that security is available for free. And it even works with the email provider of your choice: client certificates of CAcert integrate seamlessly into most well-known mail programs under windows, mac and linux.

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.

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