LetsEncrypt envisage de révoquer ses certificats en raison d'un bug logiciel.

La société LetsEncrypt, qui propose des certificats SSL gratuits pour le cryptage, est contrainte d'annuler certains certificats.

Le problème est lié à une erreur logicielle dans le logiciel de gestion Boulder, utilisé pour établir l'AC. En général, la vérification de l'enregistrement DNS CAA se fait en même temps que la confirmation de la propriété du domaine, et la plupart des abonnés reçoivent le certificat immédiatement après la vérification. Cependant, les développeurs du logiciel ont configuré le système de manière à ce que le résultat de la vérification soit considéré comme réussi pendant les 30 jours suivants. Dans certains cas, il est possible de vérifier les enregistrements une deuxième fois, juste avant la délivrance du certificat, notamment une vérification répétée de la CAA dans les 8 heures précédant la délivrance, donc tout domaine vérifié avant cette période doit être revérifié.

Quelle est donc l'erreur ? Si la demande de certificat contient N domaines nécessitant une nouvelle vérification CAA, Boulder en sélectionnait un et le vérifiait N fois. En conséquence, il était possible de délivrer un certificat, même si par la suite (dans les 30 jours suivants) un enregistrement CAA était établi interdisant la délivrance du certificat LetsEncrypt.

Pour vérifier les certificats, la société a préparé un outil en ligne, qui fournira un rapport détaillé.

Les utilisateurs avancés peuvent tout faire eux-mêmes en utilisant les commandes suivantes :

# проверка https
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# вариант проверки от @simpleadmin 
echo | openssl s_client -connect example.com:443 |& openssl x509 -noout -serial
# проверка почтового сервера, протокол SMTP
openssl s_client -connect example.com:25 -starttls smtp -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол SMTP
openssl s_client -connect example.com:587 -starttls smtp -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол IMAP
openssl s_client -connect example.com:143 -starttls imap -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол IMAP
openssl s_client -connect example.com:993 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# в принципе аналогично проверяются и другие сервисы

Il faut ensuite vérifier ici son numéro de série, et s'il figure sur la liste, il est recommandé de mettre à jour le(s) certificat(s).

Pour mettre à jour les certificats, vous pouvez utiliser certbot :

certbot renew --force-renewal

Le problème a été identifié le 29 février 2020, et la délivrance des certificats a été suspendue de 3h10 UTC à 5h22 UTC. Selon une enquête interne, l'erreur a été introduite le 25 juillet 2019, un rapport plus détaillé sera fourni par la société ultérieurement.

UPD : le service de vérification des certificats en ligne peut ne pas fonctionner avec des adresses IP russes.

Source : habr.com