Let's Encrypt DST Root CA X3 a expiré. Que faire pour les anciens appareils et sites Web ?

Ce n'est pas l'apocalypse des appareils électroniques mais certains produits peuvent afficher des messages d'erreur à partir de jeudi. En cause : l'expiration d'un certificat de sécurité numérique Let's Encrypt prévue le 30 septembre 2021 à 16h01.

Ce fichier, nommé « IdentTrust DST Root CA X3 », est un certificat racine de Let's Encrypt CA , une organisation à but non lucratif qui œuvre depuis plusieurs années à la démocratisation du chiffrement gratuit sur Internet. Après vingt ans de sécurisation des connexions entre appareils et sites web, son utilisation est progressivement abandonnée.

Il en résulte qu'à la fin du mois, certains appareils pourraient rencontrer des difficultés d'accès à Internet. Des messages d'erreur indiquant une connexion non sécurisée pourraient s'afficher. Toutefois, l'accès à Internet ne sera pas interrompu . Tout comme lors de la navigation avec un navigateur obsolète ou sur une page non sécurisée, il sera possible de forcer la connexion en choisissant de ne pas faire confiance au certificat, en utilisant le navigateur Firefox (qui émet ses propres certificats) ou en mettant à jour son système.

AVERTISSEMENT : Nous avons reçu plusieurs messages d’utilisateurs non techniques nous demandant la signification de ce message en langage clair. Sachant que beaucoup d’utilisateurs ne sont pas familiarisés avec l’informatique, voici un bref résumé : si vous utilisez un navigateur ancien sur un système d’exploitation ou un appareil ancien, vos autorités de certification ne sont pas à jour (essayez d’utiliser Firefox sur mobile et ordinateur pour résoudre ce problème si vous ne pouvez pas mettre à jour votre appareil).

Si vous possédez un site web, malheureusement, une partie de vos utilisateurs ne pourra pas y naviguer et risque de passer à côté de revenus, de ventes, de contacts et d'autres opportunités importantes. Cela dépend en grande partie de votre public cible. Si vous visez un public jeune, il est probable qu'il possède les derniers smartphones, et vous n'aurez pas à vous en soucier outre mesure.

Si au contraire vous ciblez des personnes plus âgées, des ménagères pas trop expérimentées ou des professionnels qui peuvent tomber dans la tranche moins "technologique", vous risquez de perdre jusqu'à 10% de trafic avec évidemment un manque à gagner.

Si vous souhaitez résoudre directement le problème sans vous plonger dans une terminologie destinée à un public technique / développeurs / webmasters / administrateurs système, nous vous invitons à nous contacter via cette page.

Cependant, cette situation ne devrait pas affecter un grand nombre de personnes.

Comme le souligne Scott Helme , chercheur en sécurité qui a mis en lumière ce problème sur son blog, seuls les appareils les plus anciens encore en circulation sont concernés. Chez Apple, les iPhone visés sont ceux qui n'ont pas été mis à jour depuis cinq ans et qui n'ont pas encore reçu la version iOS 10. Tous les modèles à partir de l'iPhone 5 peuvent être mis à jour vers cette version pour corriger le problème.

Les utilisateurs d'appareils plus anciens sont susceptibles de rencontrer des problèmes sur le Web à partir d'aujourd'hui, le 30 septembre, à 16h01. L'expiration d'un certificat racine empêchera en effet presque tous les navigateurs de charger des sites Web sur ces terminaux. Les iPhones et Mac plus anciens sont potentiellement concernés.

Tout d'abord, il faut savoir que pour la grande majorité des internautes, ce 30 septembre sera un jeudi comme les autres. Ceux qui possèdent un Mac avec MacOS 10.12.1 (Sierra) et supérieur, ainsi que ceux qui ont un iPhone au-delà d'iOS 10 (l'iPhone 5 peut accueillir cette version) seront épargnés, ainsi que les utilisateurs d'Android 7.1.11 et supérieur, ainsi que ceux exécutant Windows XP SP3 et versions ultérieures.

Cela signifie que les utilisateurs de produits dotés d'anciennes versions de leur système d'exploitation rencontreront des problèmes de connexion Internet dès demain. Sur Mac, vous pouvez modifier le certificat manuellement via l'application Trousseau d'accès. Vous devez remplacer le certificat IdentTrust DST Root CA X3 par le certificat ISRG Root X1 , fourni par Let's Encrypt et valide jusqu'en 2035. Pour plus d'informations techniques, consultez le site web d'OpenSSL.

Autre solution : utilisez Firefox qui vient avec sa propre liste de certificats racines, souvenez-vous de Let's Encrypt. Pour tous les autres appareils, il n'y aura aucun problème s'ils sont mis à jour régulièrement.

Il y a un long fond

Cela peut paraître un peu direct, mais si vous souhaitez vraiment approfondir vos connaissances sur le fonctionnement des autorités de certification (AC) et des chaînes de certificats, je vous recommande de suivre la formation pratique TLS et PKI que je propose. Cette formation a été conçue par Ivan Ristic , créateur de SSL Labs et auteur de « Bulletproof SSL and TLS » . Pour les autres, cet article et les liens que je vous fournirai devraient suffire à comprendre les mécanismes en jeu.

En fin de compte, tous les certificats qui alimentent HTTPS sur le Web sont émis par une autorité de certification, une organisation de confiance reconnue par votre appareil / système d'exploitation. Ici, vous pouvez voir la liste des « Autorités de certification racines de confiance » sur mon appareil Windows 10 actuel :

Ces certificats sont intégrés à votre système d'exploitation et sont généralement mis à jour automatiquement lors du processus de mise à jour normal de celui-ci. Le certificat qui pose problème ici est le suivant : IdenTrust DST Root CA X3.

Comme vous pouvez le voir, le temps presse et nous approchons de la date d'expiration du 30 septembre 2021 mais ce n'est pas seulement une date d'expiration, c'est un horodatage d'expiration que nous appelons notAfter:

Ceci est converti en BST pour moi, mais si j'analyse le certificat à l'aide d'OpenSSL X509, vous pouvez voir l'horodatage UTC pour l'expiration :

Cela nous donne un délai assez précis pour que ce certificat expire :

Validity
            Not Before: Sep 30 21:12:19 2000 GMT
            Not After : Sep 30 14:01:15 2021 GMT

Une fois que cette autorité de certification racine a expiré, les clients, tels que les navigateurs Web, ne feront plus confiance aux certificats émis par cette autorité de certification.

Le problème est généralement lié aux appareils qui n'ont pas été mis à jour depuis cinq ans

Sur Android , les appareils concernés sont ceux qui n'exécutent pas la version 7.1 , sortie il y a cinq ans. Cependant, un accord signé entre Google et une autorité de certification permettra à certains appareils encore plus anciens d'utiliser le certificat. Les appareils sortis il y a dix ans devraient continuer à fonctionner normalement, selon Let's Encrypt. Le cycle de renouvellement des smartphones variant de deux à cinq ans selon les marchés, la grande majorité des utilisateurs ne constatera aucun changement jeudi.

Outre les smartphones, l'expiration du certificat pourrait causer des problèmes aux personnes jouant encore à des versions PS4 qui n'ont pas été mises à jour depuis la version 5 de leur firmware, sortie fin 2017. Les utilisateurs de Mac qui n'ont pas effectué la mise à jour depuis macOS 10.12.1 et les PC , même avec Windows XP Service Pack 3, sont concernés.

Au final, on retrouve ici principalement des machines qui n'ont pas été mises à jour depuis au moins cinq ans, ce qui limite grandement la portée de l'événement.

Let's Encrypt est devenu populaire entre-temps

Au cours de la dernière année seulement, Let's Encrypt a considérablement augmenté sa part de marché et à mesure qu'une autorité de certification grandit, ses certificats permettent à une plus grande partie du Web de fonctionner et, par conséquent, lorsque quelque chose comme cela se produit, ils ont le potentiel de causer plus de problèmes. Cela n'a rien à voir avec ce que Let's Encrypt a fait ou n'a pas fait, mais cela pose toujours le même problème sous-jacent que les appareils de l'écosystème ne se mettent pas à jour comme ils le devraient.

Compte tenu de la différence de taille relative entre Let's Encrypt et AddTrust, j'ai le sentiment que l'expiration de la racine d'IdenTrust peut potentiellement causer plus de problèmes. Personne ne sait vraiment à quel point cela pourrait être un problème, cela pourrait avoir des conséquences similaires lorsque AddTrust a expiré, ou il pourrait y avoir des circonstances imprévues et cela pourrait être bien pire, votre supposition est aussi bonne que la mienne.

Que fait Let's Encrypt à ce sujet ?

Comme je l'ai dit ci-dessus, ce problème ne se produit pas en raison de quelque chose que Let's Encrypt a fait ou n'a pas fait, cela se produit parce que tous les certificats finissent par expirer et si les appareils ne sont pas mis à jour, ils ne recevront pas les nouveaux certificats de remplacement. Cela dit, Let's Encrypt ne s'est pas assis et n'a pas tordu les pouces à l'approche de la date d'expiration, ils ont travaillé dur pour essayer de trouver une solution.

En avril 2019, Let's Encrypt a proposé de passer à la racine ISRG, où Let's Encrypt avait prévu de passer de la racine IdenTrust à sa propre racine, ISRG Root X1, qui expire le 4 juin 2035, ce qui nous donne un certain nombre d'années. Le problème était que peu d'appareils avaient reçu les mises à jour nécessaires qui incluent ce nouveau ISRG Root X1, sorti 4 ans plus tôt en 2015 ! Si un grand nombre d'appareils n'ont pas reçu de mise à jour pour inclure ce nouveau certificat racine, ils ne lui feront tout simplement pas confiance. Il s'agit essentiellement du même problème que nous rencontrons actuellement avec l'expiration de la racine IdenTrust, car les périphériques clients n'ont pas été mis à jour et n'ont même pas reçu la nouvelle racine ISRG X1. La transition a été reportée.

En septembre 2020, Let's Encrypt a de nouveau reporté la transition . Ils ont invoqué les préoccupations suivantes :

En raison de préoccupations concernant la propagation insuffisante de la racine ISRG sur les appareils Android, nous avons décidé de déplacer la date à laquelle nous commencerons à servir une chaîne à notre racine au 11 janvier 2021.

Cela se traduit vaguement par des appareils Android qui n'ont pas reçu de mise à jour depuis plus de 4 ans, ce qui signifie que ces appareils n'avaient pas encore reçu ISRG Root X1, ce qui signifie qu'ils ne lui faisaient pas confiance. Let's Encrypt ne peut pas transmettre le problème à partir de la nouvelle racine, mais la racine IdenTrust a encore 1 an et le temps est vraiment court.

Finalement, un événement quelque peu inattendu est survenu, susceptible d'atténuer l'impact de cet incident et de le rendre plus acceptable. Les anciens appareils Android ne vérifiant pas la date d'expiration d'un certificat racine lors de son utilisation, Let's Encrypt pourrait continuer à chaîner les certificats racine expirés sans problème sur ces appareils. Cela complexifie certes le processus à terme, mais l'objectif final est d'étendre la compatibilité des certificats Let's Encrypt avec les appareils Android.

Pour que cela fonctionne, Let's Encrypt a dû obtenir une signature croisée pour son certificat racine ISRG X1 de la racine CA X3 IdenTrust DST expirante, mais cela n'aurait été d'aucune utilité à moins que la racine à signature croisée n'ait été valide plus longtemps que le racine de signature, c'est-à-dire. Le nouveau certificat ISRG Root X1 est valide plus longtemps que l'IdenTrust DST Root CA X3 qui l'a signé !

Cette page de documentation Let's Encrypt contient une liste de clients qui font uniquement confiance au certificat IdenTrust DST Root CA X3 , suivie d'une liste de plateformes qui font confiance au certificat ISRG Root X1. J'ai combiné ces deux listes pour obtenir la liste suivante de clients qui cesseront de fonctionner après l'expiration du certificat IdenTrust DST Root CA X3.

• OpenSSL <= 1.0.2
• Windows <XP SP3
• macOS <10.12.1
• iOS <10 (l'iPhone 5 est le modèle le plus bas pouvant aller à iOS 10)
• Android <7.1.1 (mais> = 2.3.6 fonctionnera si le signe croisé ISRG Root X1 est servi)
• Mozilla Firefox <50
• Ubuntu <16.04
• Debian <8
• Java 8 <8u141
• Java 7 <7u151
• NSS <3,26
• Amazon FireOS (navigateur Silk)

Les plates-formes dont je ne suis toujours pas sûr et qui nécessiteront une enquête plus approfondie pour voir si elles échoueront après l'expiration d'IdenTrust DST Root CA X3 sont :

• Cyanogène> v10
• Système d'exploitation Jolla Sailfish> v1.1.2.16
• Kindle> v3.4.1
• Mûre> = 10.3.3
• Console de jeu PS4 avec firmware> = 5.00
• IIS

La réponse à la question « Que se passera-t-il lorsque la racine IdenTrust expirera ? » dépend de la popularité des types de clients mentionnés ci-dessus. J'ignore ce qui circule sur Internet, et j'ignore même ce qui provoque ces problèmes. Une chose est sûre : quelque part, au moins, quelque chose va dysfonctionner.

Quels problèmes pour les hébergeurs dérivant de l'expiration du DST Root CA X3 Let's Encrypt ?

Certes, le problème n'est pas passé inaperçu compte tenu des dizaines et des dizaines d'appels téléphoniques que le système de billetterie en ligne et l'assistance téléphonique nous ont déjà pris d'assaut depuis le 16 septembre 30.

Certains utilisateurs avec des appareils obsolètes tels que certains Mac OS Yosemite et certains Chrome qu'ils utilisaient se sont immédiatement plaints de l'erreur du certificat expiré qui s'est produite lors de la tentative d'accès aux sites qui ont adopté les certificats gratuits Let's Encrypt.

Nous avons eu du mal à nous concentrer immédiatement sur le problème et à pouvoir discuter rapidement à la fois de la raison de cela et de la solution relative.

Cependant, ce n'était pas le seul problème.

Le plus difficile en apparence concernait en fait certains sites Web qui adoptaient des clients SMTP et qui utilisaient le protocole SSL ou TLS pour transférer le courrier sortant vers des serveurs de messagerie utilisant les certificats SSL de Let's Encrypt.

Imaginons ces formulaires Web classiques qui, une fois remplis et appuyés sur le bouton « Envoyer », s'efforcent d'envoyer un message électronique à une adresse. Normalement, ils utilisent la bibliothèque PHP PHPMailer qui, rencontrant un certificat SSL expiré, a refusé la connexion, évitant ainsi le transfert du courrier sortant vers le serveur de messagerie configuré.

Cependant, dans les systèmes les plus modernes tels que RedHat RHEL 7 et ultérieur que nous utilisons dans l'entreprise, il suffisait de mettre à jour les certificats de l'Autorité de Certification en lançant la commande :

yum update ca-certificats

Il a permis de mettre à jour la liste des Autorités de Certification qui excluaient logiquement le Let's Encrypt CA X3 expiré vers la dernière version.

Pour les systèmes les plus obsolètes maintenant en EOL depuis un certain temps (End Of Life), nous avons plutôt dû mettre sur liste noire l'AC expirée pour éviter de négocier avec un certificat qui n'est plus utile maintenant.

Quelles solutions pour les propriétaires de MacOS en cas d'erreur de certificat ?

La seule solution pour les anciennes versions de MacOS est de mettre à jour le système d'exploitation vers au moins la version El Captain.

Alternativement, vous pouvez installer le navigateur Firefox qui, comme nous l'avons déjà dit, utilise les autorités de certification stockées dans l'installation du navigateur et NON celles du système d'exploitation.

Quelle solution pour les hébergeurs et sites web ?

Si vous possédez un site web et souhaitez maintenir sa compatibilité avec ces appareils plus anciens, le meilleur conseil que nous puissions vous donner est de passer à un certificat SSL commercial à validation de domaine (DV) tel que Comodo, Verisign ou RAPIDSSL.

Par exemple, chez Managedserver.it, nous en tant que fournisseurs de fournisseurs d'hébergement et de services de messagerie avec leurs protocoles sécurisés et cryptés, notamment :

AUTH SMTP: Port 25 ou 587
SSL SMTP: port 465
SMTP DémarrerTLS: port 587
POP3: port 110
IMAP: port 143
SSL IMAP: port 993
IMAP DémarrerTLS: port 143

Nous avons opté pour un certificat SSL Positive SSL de Comodo, rapide, économique, robuste et compatible , acheté pour deux ans à environ 5 dollars par an sur SSLS.COM.

Le coût en lui-même est vraiment faible si vous travaillez sur un seul domaine, cependant la procédure d'installation sur Webserver et surtout SMTP Server et IMAP et POP3 Server peut ne pas être à la portée de tout le monde, surtout si un débutant peut-être avec un panneau de configuration amateur comme Plesk ou cPanel dont on a beaucoup parlé (mal) si adopté dans les milieux professionnels.

Cependant, nous parlons d'un certificat commercial qui, bien qu'extrêmement bon marché, peut ne pas être la solution idéale (ou simplement celle souhaitée), qui nécessite un certain temps, argent et énergie pour :

1. Achetez le certificat SSL en ligne et payez-le.
2. Générez le CSR afin de générer par la suite le certificat (normalement via l'utilitaire openssl)
3. Vérifiez la propriété du domaine via DNS ou en recevant du courrier à des adresses telles que admin@domainname.it
4. Attendre la validation et l'e-mail avec le certificat
5. Installez-le et configurez-le.

Bref, une série d'opérations qui nécessitent au mieux au moins 30 minutes pour un seul domaine. Si vous souhaitez opérer sur de gros volumes et de nombreux domaines comme dans le cas de clients qui ont de nombreux domaines, la solution la plus rapide est d'utiliser des certificats CloudFlare comme nous le verrons ci-dessous.

Utilisez les certificats SSL CloudFlare en mode proxy inverse.

Si vous ne souhaitez pas dépenser un seul euro mais savez comment faire, vous pouvez activer CloudFlare en mode proxy inverse et sa chaîne de certificats qui n'est pas basée sur LetsEncrypt.

Cloudflare met en cache le contenu statique de votre site web et le distribue sur un réseau de centaines de serveurs à travers le monde, grâce à un CDN global reposant sur 30 centres de données. Lorsqu'un utilisateur visite votre site, il n'a pas besoin d'accéder au serveur d'origine, car le contenu mis en cache est diffusé depuis le serveur Cloudflare le plus proche, ce qui permet un chargement deux fois plus rapide ! C'est l'un des moyens les plus simples d'améliorer les performances et de réduire la charge sur vos serveurs web.

Rien ne se passe au niveau des fichiers et du système de votre site, toutes les données qui transitent par le système DNS sont interceptées et gérées par le réseau CloudFlare qui applique ainsi des opérations d'optimisation importantes sur Javascript, images, contenus pour mobile, pour navigateurs.

• Cache de page statique
• CAN
• Optimisation des images
• Optimisation Javascript
• Optimisation mobile
• Contenu équilibré

Évidemment, ayez la prévoyance de connecter les API avec les modules associés pour le CMS principal.

Si vous ne savez pas comment procéder, veuillez nous contacter pour une consultation système. Nous allons résoudre le problème en quelques minutes.