Expiration du certificat racine Let's Encrypt
Le 30 Septembre 2021 le certificat racine DST Root CA X3 utilisé par Let's Encrypt est arrivé à expiration.
Le certificat racine ISRG Root X1 à donc pris le relais en remplacement de DST Root CA X3.
Il s'agissait de quelque chose de prévu et d'anticipé, à la fois par les équipes de Let's Encrypt, par cPanel et les équipes techniques d'o2switch.
Néanmoins cette expiration de certificat racine à pu causer des perturbations ou des incompréhensions.
Nous allons clarifier cela dans cet article et fournir des procédures pour les personnes étant impactées par cela.
Chaine de confiance
Afin de comprendre les raisons pour lesquelles l'expiration d'un certificat racine peut causer des perturbations, il est nécessaire d'évoquer rapidement le concept de chaîne de confiance et le rôle d'un certificat racine.
Ces explications se veulent volontairement simple, des approximations et raccourcis seront utilisés, dans la réalité c'est un plus compliqué et d'autres mécanismes entrent en jeu (l'ocsp par exemple).
Comment un navigateur web fait pour savoir si un certificat SSL est de confiance (HTTPS vert) ou non (HTTPS rouge) ?
Pour savoir si un certificat SSL est reconnu comme de confiance ou non, le navigateur web procède à une série de vérifications.
Ce processus de validation se base sur un fonctionnement hiérarchique et une chaîne de confiance.
La chaîne de confiance correspond à une liste de certificats SSL, qui commencent par le certificat d'entité finale (plus simplement le certificat SSL lié au nom de domaine), suivi d'un ou plusieurs certificats d'autorités de certifications. Le dernier certificat de la liste est le certificat racine.
Cette chaîne de confiance est un système hiérarchique :
- le certificat d'entité (celui lié au domaine) est signé par un certificat intermédiaire de l'autorité de certification
- le certificat intermédiaire de l'autorité de certification est signé par le certificat racine de l'autorité
- le certificat racine n'est pas signé mais c'est un certificat qui est déjà considéré de confiance car installé nativement dans le système d'exploitation ou dans la bibliothèque des certificats SSL de confiance d'un navigateur web
Un certificat est reconnu comme valide par le navigateur web si toutes cette chaîne de confiance est validée. C'est-à-dire que les les certificats ont bien été signés les uns avec les autres.
Cela peut être visualisé avec des outils de tests en ligne comme celui de ssllabs.
Les certificats racines correspondent aux certificats qui sont installés de base sur les ordinateurs et qui sont considérés comme de confiance. La liste des certificats racines à qui on peut faire confiance est le résultat d'un consensus établi. On retrouve plus ou moins la même liste sur tous les systèmes d'exploitations et navigateurs web. La gestion de cette liste est la responsabilité des mainteneur des navigateurs web ainsi que des mainteneurs de systèmes d'exploitation. C'est évidemment un point très critique car à la base de la chaîne de confiance.
Au niveau du serveur web, pour permettre ce processus de validation par le navigateur web (client), le serveur web retourne le certificat d'entité (celui du domaine donc) suivi d'au moins le certificat intermédiaire qui à servi à signer le certificat d'entité. Il peut ajouter d'autres certificats intermédiaires, le chemin de certification est donc plus au moins long.
Ainsi le navigateur web reçoit :
- le certificat d'entité (celui du nom de domaine consultée), qu'il vérifie avec le certificat intermédiaire
- il reçoit également le certificat intermédiaire, qu'il vérifie avec un des certificats racines qu'il a dans sa bibliothèque de certificats de confiance
C'est encore une fois visible sur un outil comme ssllab :
- deux certificats sont envoyés par le serveur (sent by server dans la capture d'écran)
- le dernier est celui considéré comme sûr de base car il s'agit d'un certificat racine
Cela à son importance pour comprendre l'un des problèmes expliqué un peu plus loin.
En quoi ça peut poser problème
ISRG Root X1 n'est pas reconnu
Le premier problème, le plus évident à expliquer, est le cas ou le certificat racine ISRG Root X1 n'est pas reconnu car n'est pas installé dans la liste des certificats de confiance dans le système d'exploitation utilisée ou dans la bibliothèque SSL du navigateur web.
Dans ce cas, la chaîne de confiance ne peut pas être validé, le certificat est considéré comme pas de confiance.
Cela peut arriver sur les vieux appareils, qui ne sont pas à jour.
Malheureusement dans ce cas présent, il n'y a pas vraiment de solution hormis voir s'il est possible de mettre à jour l'appareil, de telle sorte à télécharger une liste de certificat racine de confiance plus récente et à jour.
Compatibilité Android
Une autre source de problèmes est un mécanisme qu'à mis en place Let's Encrypt pour préserver la compatibilité avec d'anciens appareils android.
Cela est expliqué en détails dans cet article :
Cette solution consiste à préserver DST Root CA X3 dans la chaîne de certification, en plus d'avoir ISRG Root X1.
Cela a été mis en place car :
- une subtilité sur les appareils Android fait que la date d'expiration de DST Root CA X3 est ignorée
- ISRG Root X1 n'est pas reconnu sur tous les appareils (notamment les anciens) donc ajouter DST Root CA X3 permet de palier à ce problème
Le problème avec cette solution est que d'autres appareils n'apprécient pas le fait de voir DST Root CA X3 (qui est expiré) dans la liste des certificats retournés par le serveur web.
C'est cela qui cause la majorité des problèmes avec les certificats Let's Encrypt et l'une des solutions envisagée par cPanel est d'enlever le certificat DST Root CA X3 expiré de la chaîne de certificat renvoyé. Cette solution consiste à passer par un chemin alternatif, comme résumé sur cette image :
Cela n'est pas parfait, chaque solution à ces avantages et inconvénients :
- Le premier chemin le plus à gauche est celui qui n'est plus utilisé, l'ancienne version par défaut
- Le chemin au milieu est celui qui préserve la compatibilité avec les anciens appareils Android mais cause des problèmes sur d'autres appareils (ancienne version de OpenSSL)
- Le chemin le plus à droite, le plus court car il n'y a plus DST Root CA X3, est celui qui réduit la compatibilité avec Android mais augmente la compatibilité avec des versions plus ancienne de OpenSSL
Chez l'hébergeur web français o2switch, nous avons fait le choix d'utiliser le chemin le plus court, c'est-à-dire celui qui n'utilise plus du tout DST Root CA X3.
Si vous désirez conserver une compatibilité avec les anciens appareils Android, vous pouvez utiliser l'outil Let's Encrypt dans cPanel et son option “réinstaller” qui vous permet de choisir la liste des certificats à retourner.
Problème SSL Email
Un autre bug, cette fois-ci lié à cPanel et sans rapport direct avec le changement de racine de certificat a causé un problème avec les logiciels de messagerie qui utilisaient une adresse de serveurs POP, IMAP, SMTP de la forme : mail.nom-de-domaine.com.
Le certificat SSL installé sur le nom de domaine était ignoré et le certificat SSL principal du serveur était utilisé à la place.
Un patch est en cours de déploiement à ce sujet et cela sera corrigé rapidement.
Pour éviter ce problème, vous pouvez définir l'adresse principale du serveur en adresse POP, IMAP, SMTP dans vos logiciels de messagerie.
L'adresse principale est celle de la forme : quelquechose.o2switch.net