ClickCease Un correctif ELS est disponible pour le certificat Let's Encrypt | tuxcare.com

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Un correctif ELS est disponible pour les changements de certificat de Let's Encrypt

1er octobre 2021 - L'équipe de relations publiques de TuxCare

Let's Encrypt est un moyen pratique d'obtenir des certificats et de mettre en œuvre le cryptage TLS dans un large éventail d'applications. Si l'on considère le nombre de certificats émis, il s'agit de la plus grande autorité de certification (AC) au monde. Elle est également largement utilisée dans les scénarios d'automatisation en raison de son mécanisme de renouvellement pratique.

La récente expiration d'un certificat racine dans la chaîne de certification par défaut de Let's Encrypt (30 septembre 2021) entraîne de graves problèmes avec les anciennes versions d'OpenSSL. Cependant, des correctifs pour les versions d'OpenSSL présentes dans Centos 6/Oracle Linux 6/CloudLinux 6 sont déjà disponibles et devraient être déployés dès que possible pour tous les systèmes affectés.

Le certificat racine qui a expiré dans la chaîne de certification de Let's Encrypt (DST Root CA X3) restera dans la chaîne jusqu'en 2024. Les versions récentes d'OpenSSL ignorent correctement le certificat expiré et valident en utilisant les certificats alternatifs présents dans la chaîne, mais les versions plus anciennes d'OpenSSL échoueront la vérification. Cela pose de sérieux problèmes, car les connexions TLS échouent alors qu'elles ne devraient pas l'être. Par un malheureux coup du sort, l'utilitaire "certbot" lui-même, par défaut, ne mettra pas à jour la chaîne et ne renouvellera pas les certificats Let's Encrypt (ce qui résoudrait le problème).

Ce problème affecte de nombreuses distributions Linux et leurs versions, mais les versions couvertes par notre support étendu du cycle de vie disposent déjà de correctifs pour OpenSSL qui corrigent le problème. La façon de procéder consiste à activer l'indicateur X509_V_FLAG_TRUSTED_FIRST dans OpenSSL par défaut, ce qui signifie essentiellement que la validation doit d'abord essayer les "bons" certificats lorsqu'ils sont disponibles plutôt que d'échouer lorsqu'elle trouve un "mauvais" certificat (lire : expiré). En corrigeant le problème de cette manière, on évitera également que des événements similaires se produisent à l'avenir lorsque d'autres certificats expirent, que ce soit dans Let's Encrypt ou dans toute autre chaîne de certification.

Si vous souhaitez traiter le problème d'une manière alternative qui ne corrige pas le problème sous-jacent dans OpenSSL mais qui contourne simplement le problème actuel, vous pouvez exécuter "certbot" comme suit:

certbot renew -dry-run -preferred-chain "ISRG Root X1"

Ou, dans /etc/letsencrypt/renewal/, ajoutez

preferred_chain = ISRG Root X1

Cela permettra à certbot de récupérer les certificats en ignorant la chaîne de certification qui contient le certificat racine expiré. Mais, encore une fois, cela ne résout pas le problème de l'échec d'OpenSSL dans une situation où il devrait procéder, donc les événements futurs où un certificat racine ou intermédiaire sont expirés (que ce soit lié à Let's Encrypt ou à toute autre chaîne de certification) continueront à causer des problèmes.

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information