There was a issue with ocsp.cacert.org on Mozilla Firefox browsers. We published a work around last year. In between a volunteer detected, that a script on ocsp.cacert.org was not running as expected. Therefore the CRL expired for OCSP-Daemon, hence giving the OLD_RESPONSE-error. We restarted the script allready in 2020 and changed our internal monitoring.
The OCSP responder has been restored to a proper working state and is monitored properly now. As it worked now for more than 3 months properly, the work around is no more needed.
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.
À 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.
The CAcert OCSP and CRL services are temporarily unavailable due to a problem with our firewall, which cannot be fixed remotely. Therefore a site visit has been planned to remedy the problem.
The problem started on May 4 around 8:20 CEST, and will hopefully be fixed by May 6 around 15:30 CEST.
To verify the validity of a certificate issued by CAcert, the recommended method is to consult the OCSP responder running at ocsp.cacert.org. Many software packages have integrated support for the OCSP protocol, which is quite efficient in two ways:
very little data needs to be exchanged between client and server
the answer is always up-to-date because the server has the most recent Certificate Revocation List (CRL) on hand
Fall-back method: CRL
However, sometimes older software versions may lack working support for the OCSP protocol. But they often do have the ability to verify a given certificate against the Certificate Revocation List (CRL) published by the certificate issuer (CAcert in our case). For this to work, the client software requires a fairly recent copy of the CRL. Traditionally, such a copy can be obtained by an HTTP request for http://crl.cacert.org/revoke.crl and/or http://crl.cacert.org/class3-revoke.crl. Doing this regularly causes a lot of network traffic because the CRLs are quite large: revoke.crl is currently 5.6 MB, while class3-revoke.crl is 0.6 MB.
Improved fallback method: RSYNC
As of today a much more efficient method is available for maintaining a reasonably up-to-date local copy of the CAcert CRLs: the rsync protocol. After the initial retrieval of the full CRL, subsequent updates are orders of magnitude faster because only the small differences with the previous version need to be transmitted. The service can be used like this:
Only if you cannot use OCSP and really do need local up-to-date copies of CAcert’s CRLs, please consider the use of the rsync method outlined above. By saving bandwidth use on the crl.cacert.org server everybody benefits from better response times. Your cooperation is appreciated!
