COMPTOIR
register

Un "Root Certificate" de Let's Encrypt arrive à expiration : pour quels soucis en pratique ?

Depuis quelque temps déjà, la fondation Mozilla — ainsi que d’autres acteurs du web — poussent pour la popularisation du HTTPS, c’est à dire l’utilisation d’une surcouche TLS pour accéder à nos bonnes vieilles pages web en HTTP. Vous l’avez peut-être remarqué, mais le Comptoir est passé l’an dernier en HTTPS, histoire de vous épargner un message d’avertissement pas du tout flippant de votre navigateur quant à une communication non sécurisée. Car le rôle de cette couche TLS est multiple : d’un côté, la confidentialité puisque les paquets sont chiffrés, empêchant ainsi un individu mal intentionné qui aurait un accès à votre réseau de le sniffer et d’obtenir des identifiants, et, de l’autre, la sécurité, puisque la procédure de chiffrement permet au passage de certifier que le site avec lequel vous communiquez est bien authentique — contrant ainsi les attaques du type « homme dans le milieu ».

 

Avec ces avantages vient un inconvénient : celui de la mise en place du schmilblick. En effet, le TLS fonctionne avec un système de clefs de chiffrement — rien de bien nouveau là-dedans, c’est le même principe que le SSH. D’un côté, le serveur envoie une clef publique que le client utilise pour chiffrer ses messages ; messages qui sont par la suite déchiffrés par le serveur à l’aide d’une clef privée, secrète. De cette manière, clients et serveurs conviennent d’une clef unique, qui sera par la suite réutilisée pour toute la durée de la connexion. Sauf qu’il faut tout d’abord s’assurer que le serveur est authentique, et c’est là que se déroule notre affaire de certificats : toujours sur fond de chiffrement, ces fichiers servent à garantir qu’un site est bien celui qu’il prétend être (et que votre trafic n’est pas rerouté par un pirate), en se basant sur une autorité de certification (ou CA en anglais), c’est-à-dire un certificat racine qui a préalablement déposé sa marque pour le certificat du site accédé. Ces CA sont peu nombreux et sont directement présents dans les OS, navigateurs et autres logiciels susceptibles d’aller sur le web, faisant de l’obtention d’une certification de leur part une opération souvent coûteuse.

 

Souvent, mais pas toujours, puisque, depuis 2016, Let’s Encrypt propose gratuitement des certificats valables 3 mois sous condition de vérification d’un serveur web sur le port 80 de votre nom de domaine, une méthode qui est justement celle permettant de vous servir un Comptoir en HTTPS moyennant une coupure tous les trois mois faute de stagiaire pour renouveler le bousin.

 

letsencrypt logo

 

Cependant, Let’s Encrypt ne possédait jusqu’alors pas sa propre autorité de certification : derrière elle se cache un IdenTrust DST Root CA X3, un certificat racine qui est arrivé à expiration hier, le 30 septembre : oups. De quoi casser le net ? Pas vraiment : un nouveau est d’ores et déjà utilisé pour le remplacer, cette fois-ci fait maison, le ISRG Root X1, qui est valide jusqu’au 4 juin 2035. Le souci provient en fait des clients (téléphones portables, ordinateurs, consoles de jeux, etc.), car, pour que le nouveau certificat racine soit reconnu comme de confiance, il faut avoir fait les dernières mises à jour — vous comprenez le souci, encore faut-il en avoir ! Or, pour bon nombre d’appareils, ce n’est plus le cas : citons pèle-mêle la PS3, les téléphones Android avant la 7.1.1, les iBidules avant iOS 10, Ubuntu avant la version 2016, Windows avant XP Service Pack 3 (!,)... la liste complète étant disponible ici. De suite, les choses paraissent plus graves... Sauf que, pour certains d’entre eux, la date de validité des root certificates n’est en fait pas testée, ce qui permet donc d’utiliser un certificat cross-signé par l’IdenTrust DST Root CA X3 pour que les sites soient in fine considérés comme valides : ouf ! Pour bien rajouter du flou à cette histoire, ce cross-signé est également nommé ISRG Root X1 — tout comme le certificat auto-signé de Let’s Encrypt — est n’est valable que jusqu’en 2024 (ce qui reste plus lointain que la limite initiale d’hier).

 

Au niveau des conséquences, nul ne sait encore ce qui va arriver. Les mauvaises surprises ont été légion lors d’expiration de certificats passés, mais il faut dans ce cas précis qu’un site Let’s Encrypt soit encore contacté par des appareils non mis à jour depuis une dizaine d’années. En tout cas, si jamais un vieux bousin connecté à Internet ne fonctionne plus sur certains sites, voilà une piste de réflexion !

Un poil avant ?

Pour ASML, la loi de Moore n'est pas morte, loin de là !

Un peu plus tard ...

Alléluia, Noctua tease les NF-A12x25 chromax.black !

Les 8 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Nicolas D., le Dimanche 03 Octobre 2021 à 15h29  
par fofo le Dimanche 03 Octobre 2021 à 09h40
Bah ce fait tout seul quand le certificat est modifié certbot relance tout seul les serveurs web: à noter le crontab peut se faire tous les jours !
Si tu l'as bien paramétré avant et ca devient plus complexe avec des VMs .
par chambolle, le Dimanche 03 Octobre 2021 à 14h00  
Bon article, bien ecrit. Ce qui est rare sur ce genre de sujet. Ca mérite d'être souligné
par fofo, le Dimanche 03 Octobre 2021 à 09h40  
par Nicolas D. le Vendredi 01 Octobre 2021 à 17h19
Sauf qu'il faut aussi relancer les services qui dépendent du certificat sinon ils conservent les données de l'ancien :-), bouger les certificats avec les bonnes permissions pour chacun, et s'assurer que le certbot renew demande pas un port déjà trusté par... le serveur web, justement .
Bah ce fait tout seul quand le certificat est modifié certbot relance tout seul les serveurs web: à noter le crontab peut se faire tous les jours !
par Nicolas D., le Vendredi 01 Octobre 2021 à 17h39  
par Un ragoteur des lumières en Communauté Valencienne le Vendredi 01 Octobre 2021 à 17h26
Les services ? Je ne suis pas calé en web, j'ai un reverse proxy dans un container LXC (alpine linux pour le style ) qui centralise tous mes certificats webs et redirige les connexions sur les LXC idoines, dans mes logs j'ai :
"Renewing an existing certificate for ******.net
Reloading nginx server after certificate renewal"

J'imagine que dans mon cas c'est bien suffisant ?
Yes, il restart nginx automatiquement, mais ce n'est pas le cas dans des installations plus complexes .
par Un ragoteur des lumières en Communauté Valencienne, le Vendredi 01 Octobre 2021 à 17h26  
Les services ? Je ne suis pas calé en web, j'ai un reverse proxy dans un container LXC (alpine linux pour le style ) qui centralise tous mes certificats webs et redirige les connexions sur les LXC idoines, dans mes logs j'ai :
"Renewing an existing certificate for ******.net
Reloading nginx server after certificate renewal"

J'imagine que dans mon cas c'est bien suffisant ?
par Nicolas D. le Vendredi 01 Octobre 2021 à 17h19
Sauf qu'il faut aussi relancer les services qui dépendent du certificat sinon ils conservent les données de l'ancien :-), bouger les certificats avec les bonnes permissions pour chacun, et s'assurer que le certbot renew demande pas un port déjà trusté par... le serveur web, justement .
par Nicolas D., le Vendredi 01 Octobre 2021 à 17h19  
par Un ragoteur des lumières en Communauté Valencienne le Vendredi 01 Octobre 2021 à 16h55
Je ne sais pas si c'est propre ou autre mais personellement je lance "/usr/bin/certbot renew" une fois par mois via la crontab, a priori le script vérifie quel certificat à besoin d'être renouvelé et le fait tout seul si besoin (moins d'un mois de validité de mémoire).

Comme ça le stagiaire peut se concentrer sur sa tache principale, ça serait balot de ne pas avoir son café chaud quand on en a besoin.
Sauf qu'il faut aussi relancer les services qui dépendent du certificat sinon ils conservent les données de l'ancien :-), bouger les certificats avec les bonnes permissions pour chacun, et s'assurer que le certbot renew demande pas un port déjà trusté par... le serveur web, justement .
par Un ragoteur des lumières en Communauté Valencienne, le Vendredi 01 Octobre 2021 à 16h55  
Je ne sais pas si c'est propre ou autre mais personellement je lance "/usr/bin/certbot renew" une fois par mois via la crontab, a priori le script vérifie quel certificat à besoin d'être renouvelé et le fait tout seul si besoin (moins d'un mois de validité de mémoire).

Comme ça le stagiaire peut se concentrer sur sa tache principale, ça serait balot de ne pas avoir son café chaud quand on en a besoin.
par $k d'Occitanie, le Vendredi 01 Octobre 2021 à 08h36  
Mon Windows 7 accompagné de Chrome m'a fait cette erreur, je suis passé sous Firefox qui lui utilise ses propres chiffrements (un truc du genre) et tout remarche.

(Les gens qui ont ce problème ne pourront pas me lire, mais tant pis)