Tag Archives: Certificate

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;

[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.

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.
PM-Sichere-Emails-de

[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.
PR-Secure-Emails-en

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

Members with Lavabit email accounts remember to change address

Lavabit has closed down its services as announced on Lavabit homepage, Silent Circle and maybe others have followed or will follow. Since CAcert requires members to be reachable by their primary email address we ask our members with Lavabit account to change their email address quickly. Just setup a second email address if you have not already done so and choose this to become the primary one. Do not delete your old email address because it will automatically revoke all your client certificates which contain this email address.