Corriger l’expiration de DST Root CA X3 (Let’s Encrypt) sur les téléphones Yealink

Le certificat DST Root CA X3 de Let’s Encrypt a expiré le 30 septembre 2021. Pour la plupart des utilisateurs, cette expiration est passée inaperçue. Pour les appareils embarqués comme les téléphones Yealink, toutefois, elle peut empêcher la validation TLS auprès des serveurs qui utilisent des certificats Let’s Encrypt : le provisionnement échoue, le téléphone refuse de se connecter à son serveur de configuration ou les boîtes de dialogue HTTPS ne sont pas validées. Cet article explique pourquoi, et comment corriger le problème côté serveur en ajoutant une seule option à votre client ACME.

Une chaîne de problèmes

De nombreux systèmes embarqués (dont les téléphones Yealink) sont livrés avec un magasin de certificats racines intégré qui est rarement mis à jour. Ils contiennent toujours le certificat racine expiré DST Root CA X3 et s’y rabattent pour la validation. Lorsqu’un serveur présente un certificat Let’s Encrypt valide dont la chaîne remonte ultimement à DST Root CA X3, le téléphone considère la chaîne comme expirée et la validation échoue — même si le certificat final lui-même est valide.

Ce qui rend la situation déroutante, c’est que la plupart des appareils touchés possèdent déjà le certificat plus récent ISRG Root X1 (émis en 2015, valide jusqu’en 2035). On s’attendait à ce qu’ils utilisent simplement ISRG Root X1 pour valider les certificats Let’s Encrypt et ignorent l’ancienne racine. Malheureusement, la chaîne par défaut de Let’s Encrypt passe encore par DST Root CA X3 — et c’est justement la racine que nos téléphones rejettent.

Le problème n’est pas le certificat racine DST expiré, même si je sais que beaucoup de gens le croient. Le problème, c’est que le certificat intermédiaire R3 fourni par Let’s Encrypt, même avec les nouveaux certificats, a été délibérément signé de façon croisée avec le certificat DST expiré, afin que les vieux clients Android qui ne vérifient pas l’expiration de leurs certificats DST et qui n’ont pas la racine ISRG dans leur magasin de certificats continuent de fonctionner.

— Ted Mittelstaedt, sur la communauté FreePBX

Un message publié le 31 mars 2021 sur le forum par un ingénieur de Let’s Encrypt a confirmé le changement à l’origine du problème :

Le 4 mai, nous mettrons à jour notre API pour que les clients ACME téléchargent et utilisent une chaîne de certificats plus longue. Cette chaîne plus longue permettra à nos certificats de rester compatibles avec presque tous les appareils Android, même après l’expiration de DST Root CA X3 le 30 septembre. La plupart des abonnés n’ont aucun changement à faire. Cette chaîne comprendra trois certificats, au lieu des deux actuels :

• Certificat d’entité finale (aussi appelé certificat final), signé par R3
• R3, signé par ISRG Root X1
• ISRG Root X1, signé par DST Root CA X3

Notre API offrira aussi une chaîne « alternative », que vous pouvez plutôt faire sélectionner par votre client ACME :

• Certificat d’entité finale, signé par R3
• R3, signé par ISRG Root X1

Nous pensons que la chaîne longue convient à la plupart des sites Web. Si vous savez que vous n’avez pas à prendre en charge les utilisateurs d’Android, vous voudrez peut-être choisir la chaîne courte.

En bref : depuis le 4 mai 2021, Let’s Encrypt émet des certificats dont la chaîne par défaut se termine par DST Root CA X3. C’est ce certificat que les téléphones Yealink et les appareils embarqués semblables rejettent comme expiré — la validation échoue donc du côté de l’appareil, même si le certificat final est valide.

La solution : utiliser la chaîne courte ISRG Root X1

Configurez votre client ACME pour qu’il demande la chaîne alternative (courte), dont la racine est ISRG Root X1 plutôt que DST Root CA X3. Avec Certbot, Dehydrated et la plupart des clients ACME modernes, il suffit d’une seule option :

--preferred-chain "ISRG Root X1"

Émettez de nouveau votre certificat avec cette option, puis rechargez le serveur Web (nginx, Apache, etc.) pour qu’il présente la nouvelle chaîne. Les téléphones Yealink valident directement avec ISRG Root X1 et la connexion réussit.

Vérifier la nouvelle chaîne

Vous pouvez confirmer quelle chaîne votre serveur présente à l’aide de l’outil de vérification de SSL Shopper :

https://www.sslshopper.com/ssl-checker.html

Chaîne longue par défaut (avec la racine X3 expirée)

Chaîne courte après --preferred-chain "ISRG Root X1"

Autres pièges

• Ce changement peut toucher les très vieux clients Android ou tout client qui n’a pas ajouté ISRG Root X1 — mais comme cette racine existe depuis 2015, ce n’est pas un souci pour la plupart des appareils modernes.
• Certains clients ACME ne prennent pas en charge --preferred-chain. Dehydrated l’a ajoutée à la version 0.7.0 ; certains utilisateurs ont signalé des problèmes avec Certbot sur CentOS 7. Mettez votre client ACME à jour au besoin.
• Les appareils trop anciens pour avoir ISRG Root X1 dans leur magasin de confiance ne pourront plus jamais valider les certificats Let’s Encrypt, à moins que leur magasin de racines soit mis à jour. Il n’existe aucune solution côté serveur dans ce cas.

FAQ

Yealink finira-t-elle par mettre à jour son magasin de racines ?

Yealink publie de temps à autre des mises à jour de micrologiciel qui incluent des magasins de certificats racines actualisés, mais leur déploiement dépend des modèles encore pris en charge et de la version du micrologiciel de votre téléphone. Vérifiez si un micrologiciel à jour est disponible avant de présumer que la racine X3 est toujours en cause. Consultez les guides d’utilisation des téléphones Yealink.

Ce problème touche-t-il directement les services d’EMAK Telecom ?

Non — les serveurs de provisionnement d’EMAK Telecom présentent des chaînes de certificats que les téléphones Yealink peuvent valider. Cet article s’adresse aux administrateurs qui exploitent leurs propres services que les téléphones Yealink (ou des clients embarqués semblables) doivent joindre par TLS — par exemple, un tableau de bord de rapports autohébergé ou un serveur d’intégration tiers.

Pourquoi Let’s Encrypt utilise-t-elle la chaîne longue par défaut si elle cause des problèmes à ces appareils ?

Parce que la chaîne longue permet aux très vieux appareils Android de continuer à fonctionner, et qu’Android représente de loin le plus grand parc d’appareils. Let’s Encrypt recommande explicitement la chaîne courte seulement si vous savez que vous n’avez pas à prendre en charge ces anciens clients.

Ce problème touche-t-il d’autres appareils embarqués ?

Oui — les caméras IP, les imprimantes plus anciennes, les décodeurs et divers appareils IoT peuvent rencontrer le même problème, pour la même raison. La même solution côté serveur, --preferred-chain "ISRG Root X1", le règle pour tous ces appareils.

Existe-t-il une solution du côté du téléphone ?

En principe, vous pourriez téléverser un magasin de certificats racines à jour sur le téléphone, mais c’est risqué et rarement pris en charge par le fabricant. Corrigez plutôt le problème côté serveur.