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, appelé « IdentTrust DST Root CA X3 », est un certificat racine de Chiffrons l'AC, une organisation à but non lucratif qui contribue à démocratiser gratuitement le cryptage Internet depuis plusieurs années. Il est sur le point de sortir après vingt ans de sécurisation des connexions entre les appareils et les sites Web.

La conséquence est qu'à la fin du mois, certains appareils auront des difficultés à accéder à Internet. Vous pouvez voir des messages d'erreur indiquant que la connexion n'est pas sécurisée. Cependant, les utilisateurs ne seront pas privés de l'Internet. En plus de naviguer avec un navigateur obsolète ou sur une page non sécurisée, ils devraient pouvoir 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 leur système.

ATTENTION: nous avons reçu plusieurs messages d'utilisateurs « non experts » qui nous ont demandé ce que ce message signifie « en bref ». Sachant qu'il existe de nombreux non-techniques, nous pouvons brièvement résumer que si vous utilisez un navigateur trop ancien sur un système d'exploitation ou un appareil trop ancien, vous ne disposez pas des autorités de certification mises à jour (essayez d'utiliser Firefox sur les deux mobiles et le bureau pour résoudre si vous ne pouvez pas mettre à jour votre appareil).

Si vous êtes propriétaire du site Web cela signifie que malheureusement une tranche d'utilisateurs ne pourra pas naviguer sur votre site et éventuellement perdre des gains/ventes/contacts et dans tous les cas des opportunités plus ou moins importantes. Cette éventualité dépend beaucoup de la cible de vos clients. Si vous ciblez un public jeune, il aura sûrement le dernier smartphone tendance et vous n'aurez pas trop à vous soucier de cet aspect.

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 entrer dans des terminologies destinées à un public technique / développeurs / webmasters / ingénieurs système, nous vous invitons à contactez-nous sur cette page.

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

Comme souligné Scott Helmé, le chercheur en sécurité qui a souligné cet événement sur son blog, seuls les appareils plus anciens encore en circulation sont menacés. Chez Apple, ils sont ciblés iPhones qui n'ont pas été mis à jour depuis cinq ans et n'ont pas encore été mis à jour vers iOS 10. Tous les modèles lancés depuis l'iPhone 5 peuvent migrer 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 avec des versions plus anciennes de leurs systèmes d'exploitation auront des problèmes sur Internet à partir de demain. Pour les Mac, vous pouvez toujours modifier le certificat "à la main", depuis l'application Keychain Access. Il est nécessaire de remplacer leIdentTrust DST Root CA X3 avec ISRG Root X1, fourni par Let's Encrypt, dont la date d'entrée en vigueur est jusqu'à ce que 2035. De plus amples informations techniques sont disponibles sur 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

On dirait une prise sans vergogne, mais si tu veux vraiment en savoir plus sur le fonctionnement des autorités de certification (CA) et des chaînes de certification, vous devriez envisager de me rejoindre dans la formation TLS et PKI pratiques que je propose et qui a été créé par Ivan Ristic , le créateur de SSL Labs et auteur de SSL et TLS à l'épreuve des balles . Pour tous les autres, cet article de blog et les détails vers lesquels je vais créer un lien devraient suffire à comprendre ce qui va se passer et pourquoi.

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 dans le cadre du processus de mise à jour normal de votre système d'exploitation. Le certificat ici qui posera problème est celui-ci, IdenTrust DST racine 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

Sopra Android, les appareils concernés sont ceux qui n'ont pas Version 7.1 système, également lancé il y a cinq ans. Mais un accord signé entre Google et une autorité de certification permettra à certains appareils encore plus anciens d'utiliser le certificat. Les appareils lancés il y a dix ans devraient continuer à fonctionner normalement, selon Let's Encrypt. Comme le cycle de renouvellement du smartphone oscille entre deux et cinq ans selon les marchés, la grande majorité des utilisateurs ne verra aucun changement jeudi.

En plus des smartphones, l'expiration du certificat pourrait causer des problèmes aux personnes qui jouent encore aux versions du PS4 qui n'ont pas été mis à jour depuis la version 5 de leur firmware, qui a été lancée fin 2017. Les utilisateurs de Mac qui n'ont pas été mis à jour depuis macOS 10.12.1 et PC même avec Windows XP Service Pack 3 sont affecté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.

A Septembre 2020 Let's Encrypt avait une nouvelle fois reporté la transition. Ils ont cité 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, quelque chose d'un peu inattendu s'est produit qui ne pouvait que réduire l'impact grave de cet événement et le rendre un peu plus agréable au goût. Étant donné que les anciens appareils Android ne vérifient pas la date d'expiration d'un certificat racine lors de son utilisation, Let's Encrypt peut continuer à enchaîner le certificat racine expiré sans aucun problème sur ces appareils plus anciens. Cela introduit une certaine complexité à l'avenir, mais en fin de compte l'objectif est étendre la compatibilité des appareils Android pour les certificats Let's Encrypt .

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 documents de Let's Encrypt contient une liste de clients qui font confiance uniquement au certificat IdenTrust DST Root CA X3 et ensuite, il y a la liste des plates-formes qui font confiance à ISRG Root X1. J'ai fusionné ces deux listes pour produire la liste suivante de clients qui échoueront après l'expiration d'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 a la question « Que se passera-t-il lorsque la racine IdenTrust expire ? » dépend de l'étendue des types de clients énumérés ci-dessus. Je ne sais pas ce qui circule sur le Web, et je ne sais même pas ce qui dépend de ces choses. Une chose que je sais, cependant, c'est qu'au moins quelque chose, quelque part, va se casser.

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 avez un site Web et que vous souhaitez conserver la compatibilité avec ces anciens appareils, le meilleur conseil que nous puissions vous donner est de passer à un certificat Domaine SSL DV commercial validé tel que Comodo, Verisign, 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 décidé de miser sur une solution rapide et économique ainsi que robuste et compatible SSL positif de Comodo acheté pendant deux ans à environ 5 $ 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 voulez pas dépenser un seul euro mais que vous savez comment, vous pouvez activer CloudFlare en mode Reverse Proxy et leur chaîne de certificats qui il n'est pas basé sur LetsEncrypt.

CloudFlare met en cache le contenu statique du site et le distribue sur un réseau de centaines de serveurs à travers le monde, sur un CDN mondial alimenté par 30 centres de données. Lorsque l'utilisateur visite le site Web, il n'a pas besoin d'atteindre le serveur d'origine, car le contenu mis en cache lui est livré par le serveur Cloudflare le plus proche de lui, chargeant deux fois plus vite ! la charge sur les 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.