C'est une délibération du CA/Browser Forum, un consortium qui rassemble la plupart des navigateurs Web et des autorités de certification qui délivrent les certificats TLS (que tout le monde continue d'appeler SSL), plus quelques autres.
Cette décision signifie donc probablement que presque toutes les CAs vont réduire la durée de validité maximale de leurs certificats, et que les navigateurs vont se mettre à refuser les certificats avec des durées plus longues.
Aujourd'hui, beaucoup de sites utilisent des certificats à durée de vie relativement longue, typiquement un an, obtenus de la part du registrar DNS, et renouvelés à la main en demandant un nouveau certificat au registrar et en uploadant le fichier qu'on obtient sur le serveur. Pour eux, ce ne sera plus vraiment tenable, s'il faut faire cette manip tous les mois, donc tout le monde va devoir basculer sur l'autre méthode, celle du renouvellement automatique, qui est déjà très commune parce que Let's Encrypt, la principale autorité de certification à être gratuite, ne fournit déjà que des certificats à durée de vie assez courte.
(Moi, ça m'embête un peu, parce que les outils de renouvellement automatique comme acme.sh et Certbot m'ont causé quelques misères. J'espère que ce sera plus au point pour mes usages d'ici-là.)
J'ai eu des difficultés avec Certbot parfois mais ça marche très bien depuis des années pour mon cas d'utilisation simple : site/API web avec challenge Apache/Nginx.
Pour les wildcards, c'est plus compliqué, il faut passer par l'API du provider, j'ai jamais fait.
Let's encrypt est très bien quand tu fais de la masse.
Quand tu déploies un truc à droite à gauche, à chaque fois avec/sur des outils différents, un certificat annuel acheté revient moins cher : pas de debug, pas de renouvellement qui foire … C'est manuel mais c'est une fois par an et sans maintenance dans l'intervalle et c'est un coût maîtrisé.
C'est le fameux sujet "Cattle vs Pets" : les stratégies les plus efficaces ne sont pas les mêmes selon l'échelle d'industrialisation, et la gestion des certificats en fait partie
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Un certificat, soit tu le demandes / renouvelles à la main, soit automatiquement (protocole ACME, l'utilisation la plus connue est Let's Encrypt).
Il faut s'assurer qu'il marche au déploiement (ie. bien déployé, correctement, et initialement valide).
Ensuite il est souvent stocké quelque part, et utilisé. Et donc il faut surveiller les certificats stockés (fichier, dans git, etc.) pour voir s'ils vont expirer et agir en amont, mais aussi les certificats actifs, pour savoir si on a bien déployé les bons et s'ils vont bientôt expirer. Et réagir à l'expiration à venir doit être suffisamment rapide pour gérer la demande du nouveau certificat (validation éventuelle, paiement, etc.) et son déploiement avant l'expiration.
Et si tout est automatisé, il faut surveiller l'automatisation pour s'assurer que ça marche.
Quand les périodes de validité sont longues, on se retrouve avec des incidents tous les ans ou les deux ans car l'automatisation n'est pas en place, que les équipes ont changé entre-temps, etc. Plus les périodes sont courtes, plus soit tu automatises, soit tu as une armée de personnes pour suivre la cadence, soit tu as beaucoup d'incidents.
(et des certificats il y en a utilisés par des tas de logiciels différents pour des protocoles différents, donc la supervision peut être assez variée aussi, et puis il y a plein de cas plus compliqués comme le même domaine avec une IP intranet et un certificat d'une autorité interne et aussi une IP internet et un certificat d'une autorité publique, et il faut superviser les deux du coup, etc.).
Pour revenir à la question : des sites pas visibles (au sens ton navigateur ne voudra pas y aller sauf à lui dire que tu sais ce que tu fais), éventuellement des pertes financières et des données (oups on n'a pas effectué le virement car votre certificat était expiré et que notre client n'a pas voulu transmettre, oups on n'a pas reçu vos données car notre certificat était expiré et que votre client n'a pas voulu transmettre, etc.). Et un besoin de mettre "plus souvent" à jour les certificats de autorités aussi, donc potentiellement une fin de vie plus rapide des vieux téléphones mobiles (et autres équipements devenus sans suivi) si personne ne peut leur fournir des mises à jour.
En fait le certificat ne concerne pas que le serveur https que l'on voit dans son navigateur. Il y a aussi les API Rest, mais aussi un tas d'autres outils d'échanges (je pense par exemple à des outils comme Kafka mais il y en a d'autres). Ceux qui peuvent utiser les outils de Let's encrypt (autrement dit ceux qui ont un site accessible depuis l'extérieur) ne seront pas trop embêtés, mais ceux qui utilisent des certificats sur leur intranet et qui n'ont pas mis en place de PKI as Service vont pleurer, parce que faire du let's encrypt dans ce cas c'est pas possible.
Posté par gUI (Mastodon) .
Évalué à 5 (+3/-1).
Dernière modification le 15 avril 2025 à 17:05.
Pas aussi chiant que le jour où Trump déclarera que Let's Encrypt fait de l'export de matériel militaire et que du coup il coupe les vannes de Let's Encrypt pour le reste du monde.
Là oui ça va piquer.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Pour le cas des certificats des sites internes, tu as trois grandes situations :
Certif autosigné sans CA racine interne. Tu peux le générer en local et le renouveler autant que tu veux. Tu as seulement le chiffrement, sans le tiers de confiance.
Certif avec CA racine interne connue du navigateur/du client, et une PKI interne. Tu peux l'automatiser (par exemple avec le module ACME d'EJBCA ou un procesus interne).
Certif wildcard avec CA racine externe (Let's encrypt). Tu peux l'automatiser avec Certbot et avoir un process qui distribue le wildcard aux services internes.
Pour ce dernier cas, avoir un protocole de distribution standard, un peu comme un "proxy ACME" serait génial, est-ce que ça existe ?
je bosse dans une boite ou le 3 se fait via des tickets avec formulaires excel à remplir, avec livraison des certificats une fois par semaine maximum sauf urgence ou il te faut la validation de x personnes.
Merci pour l’explication détaillée. J’ose espérer que mon hébergeur va se mettre à jour (voilà pour mes petits besoins personnels).
En revanche, ce que je ne comprends pas c’est l’intérêt de cette diminution de la durée de la validité des certificats. Qu’est-ce que ça apporte, à part des enquiquinements ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
L'idée derrière, c'est de limiter l'impact de la compromission d'un serveur, du vol de la partie privée du certificat (la clé), et l'usurpation d'identité du site qui s'ensuit. Le vol d'une telle clé pour un certificat valable 10 ans permet au voleur de se faire passer pour le site pendant 10 ans. Pour un certificat valable pendant 10 jours, le voleur n'aura que 10 jours.
Ça permet aussi aux sites ou autres services abandonnés d'être repérés plus vite.
Voilà pour la théorie.
En pratique, les attaquants vont sans doute s'adapter, et mettront en place un bidule technique qui permettra de recevoir la nouvelle version du certificat à chaque renouvellement. Ce genre d'attaque dans laquelle le voleur reste en place sans se faire repérer est plus complexe à mettre en œuvre. Ça ne changera rien pour les structures mal sécurisées, qui se feront piquer leurs certifs encore et encore sans s'en rendre compte.
Au final, ça relève la barre pour les attaquants, ce qui est bien, mais ça relève aussi un peu la barre pour les attaqués, ce qui est moins sympa.
Ça va aussi sans doute pousser à déployer DNSSEC pour authentifier les réponses DNS, car le protocole ACME repose en partie sur le DNS.
Mon cœur est arc-en-ciel sur le sujet, je ne sais pas si je trouve ça bien ou pas ;)
Posté par nud .
Évalué à 4 (+2/-0).
Dernière modification le 15 avril 2025 à 15:37.
Alors premièrement, l'annonce ne concerne que les navigateurs web. Aujourd'hui un navigateur n'accepte déjà plus un certificat avec une durée de validité supérieure à 398 jours (cf le titre).
Ensuite il existe d'autres façons de vérifier si un certificat est toujours valide :
Il y a aussi les Certificate Revocation Lists (CRLs), qui sont des fichiers qui contiennent les identifiants de tous les certificats révoqués dont la durée de validité n'est pas dépassée. Let's encrypt est passé à cette technique qui ironiquement a été dépréciée dans Firefox 28 au profit de OCSP. L'inconvénient c'est que plus la durée de validité est longue et plus ces listes sont lourdes.
There are other things that could have been done, such as full support for OCSP Must Staple.
Mon opinion personnelle est qu'ils auraient mieux fait de faire ça et (en tout cas pour Let's encrypt) d'imposer Must-Staple plutôt que de supprimer le support d'OCSP totalement.
Comment on va faire pour les certificats de méga confiance eIdas RGS généré à la main après validation sécurisée par dépôt de dossier dans une mallette en cuir de confiance par une personne physique de confiance dans un bureau de confiance ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Il me semble avoir vu que ce problème est déjà résolu : tu montres tes papiers une fois par an (ou tous les deux ans), et tu peux renouveler tous les x jours. Dommage, ça aurait été une bonne occasion de se débarrasser de ce business juteux.
# Des explications ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6 (+4/-1).
Merci pour le lien, mais j'ai rien compris. La validité de quels certificats ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Des explications ?
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 14 avril 2025 à 15:26.
pas le certificat de naissance a priori :-)
en l'occurrence, les certificats SSL utilisés par TLS :-) (des services web, mais pas que…)
[^] # Re: Des explications ?
Posté par jeanas (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
C'est une délibération du CA/Browser Forum, un consortium qui rassemble la plupart des navigateurs Web et des autorités de certification qui délivrent les certificats TLS (que tout le monde continue d'appeler SSL), plus quelques autres.
Cette décision signifie donc probablement que presque toutes les CAs vont réduire la durée de validité maximale de leurs certificats, et que les navigateurs vont se mettre à refuser les certificats avec des durées plus longues.
[^] # Re: Des explications ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3 (+1/-1).
Concrètement, ça va aboutir à quoi ? Des sites pas visibles ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Des explications ?
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
oui, si rien n'est implémenté pour l'automatisation à la let's encrypt. Mais aussi le chiffrement des données par openSSL.
[^] # Re: Des explications ?
Posté par jeanas (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Aujourd'hui, beaucoup de sites utilisent des certificats à durée de vie relativement longue, typiquement un an, obtenus de la part du registrar DNS, et renouvelés à la main en demandant un nouveau certificat au registrar et en uploadant le fichier qu'on obtient sur le serveur. Pour eux, ce ne sera plus vraiment tenable, s'il faut faire cette manip tous les mois, donc tout le monde va devoir basculer sur l'autre méthode, celle du renouvellement automatique, qui est déjà très commune parce que Let's Encrypt, la principale autorité de certification à être gratuite, ne fournit déjà que des certificats à durée de vie assez courte.
(Moi, ça m'embête un peu, parce que les outils de renouvellement automatique comme acme.sh et Certbot m'ont causé quelques misères. J'espère que ce sera plus au point pour mes usages d'ici-là.)
[^] # Re: Des explications ?
Posté par jihele . Évalué à 6 (+4/-0).
J'ai eu des difficultés avec Certbot parfois mais ça marche très bien depuis des années pour mon cas d'utilisation simple : site/API web avec challenge Apache/Nginx.
Pour les wildcards, c'est plus compliqué, il faut passer par l'API du provider, j'ai jamais fait.
[^] # Re: Des explications ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 6 (+5/-1).
Let's encrypt est très bien quand tu fais de la masse.
Quand tu déploies un truc à droite à gauche, à chaque fois avec/sur des outils différents, un certificat annuel acheté revient moins cher : pas de debug, pas de renouvellement qui foire … C'est manuel mais c'est une fois par an et sans maintenance dans l'intervalle et c'est un coût maîtrisé.
C'est le fameux sujet "Cattle vs Pets" : les stratégies les plus efficaces ne sont pas les mêmes selon l'échelle d'industrialisation, et la gestion des certificats en fait partie
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Des explications ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 9 (+6/-0).
Un certificat, soit tu le demandes / renouvelles à la main, soit automatiquement (protocole ACME, l'utilisation la plus connue est Let's Encrypt).
Il faut s'assurer qu'il marche au déploiement (ie. bien déployé, correctement, et initialement valide).
Ensuite il est souvent stocké quelque part, et utilisé. Et donc il faut surveiller les certificats stockés (fichier, dans git, etc.) pour voir s'ils vont expirer et agir en amont, mais aussi les certificats actifs, pour savoir si on a bien déployé les bons et s'ils vont bientôt expirer. Et réagir à l'expiration à venir doit être suffisamment rapide pour gérer la demande du nouveau certificat (validation éventuelle, paiement, etc.) et son déploiement avant l'expiration.
Et si tout est automatisé, il faut surveiller l'automatisation pour s'assurer que ça marche.
Quand les périodes de validité sont longues, on se retrouve avec des incidents tous les ans ou les deux ans car l'automatisation n'est pas en place, que les équipes ont changé entre-temps, etc. Plus les périodes sont courtes, plus soit tu automatises, soit tu as une armée de personnes pour suivre la cadence, soit tu as beaucoup d'incidents.
(et des certificats il y en a utilisés par des tas de logiciels différents pour des protocoles différents, donc la supervision peut être assez variée aussi, et puis il y a plein de cas plus compliqués comme le même domaine avec une IP intranet et un certificat d'une autorité interne et aussi une IP internet et un certificat d'une autorité publique, et il faut superviser les deux du coup, etc.).
Pour revenir à la question : des sites pas visibles (au sens ton navigateur ne voudra pas y aller sauf à lui dire que tu sais ce que tu fais), éventuellement des pertes financières et des données (oups on n'a pas effectué le virement car votre certificat était expiré et que notre client n'a pas voulu transmettre, oups on n'a pas reçu vos données car notre certificat était expiré et que votre client n'a pas voulu transmettre, etc.). Et un besoin de mettre "plus souvent" à jour les certificats de autorités aussi, donc potentiellement une fin de vie plus rapide des vieux téléphones mobiles (et autres équipements devenus sans suivi) si personne ne peut leur fournir des mises à jour.
[^] # Re: Des explications ?
Posté par totof2000 . Évalué à 6 (+4/-0).
En fait le certificat ne concerne pas que le serveur https que l'on voit dans son navigateur. Il y a aussi les API Rest, mais aussi un tas d'autres outils d'échanges (je pense par exemple à des outils comme Kafka mais il y en a d'autres). Ceux qui peuvent utiser les outils de Let's encrypt (autrement dit ceux qui ont un site accessible depuis l'extérieur) ne seront pas trop embêtés, mais ceux qui utilisent des certificats sur leur intranet et qui n'ont pas mis en place de PKI as Service vont pleurer, parce que faire du let's encrypt dans ce cas c'est pas possible.
[^] # Re: Des explications ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4 (+3/-1).
C'est ce que j'allais dire : toutes les infras ne sont pas en ligne ou connectées et dans ce cas de figure ça va être bien ch…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Des explications ?
Posté par gUI (Mastodon) . Évalué à 5 (+3/-1). Dernière modification le 15 avril 2025 à 17:05.
Pas aussi chiant que le jour où Trump déclarera que Let's Encrypt fait de l'export de matériel militaire et que du coup il coupe les vannes de Let's Encrypt pour le reste du monde.
Là oui ça va piquer.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Des explications ?
Posté par cg . Évalué à 2 (+0/-0).
Pour le cas des certificats des sites internes, tu as trois grandes situations :
Certif autosigné sans CA racine interne. Tu peux le générer en local et le renouveler autant que tu veux. Tu as seulement le chiffrement, sans le tiers de confiance.
Certif avec CA racine interne connue du navigateur/du client, et une PKI interne. Tu peux l'automatiser (par exemple avec le module ACME d'EJBCA ou un procesus interne).
Certif wildcard avec CA racine externe (Let's encrypt). Tu peux l'automatiser avec Certbot et avoir un process qui distribue le wildcard aux services internes.
Pour ce dernier cas, avoir un protocole de distribution standard, un peu comme un "proxy ACME" serait génial, est-ce que ça existe ?
[^] # Re: Des explications ?
Posté par totof2000 . Évalué à 6 (+4/-0).
je bosse dans une boite ou le 3 se fait via des tickets avec formulaires excel à remplir, avec livraison des certificats une fois par semaine maximum sauf urgence ou il te faut la validation de x personnes.
[^] # Re: Des explications ?
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Ben ils vont mettre en place une pki et circulez y'a rien à voir.
[^] # Re: Des explications ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Merci pour l’explication détaillée. J’ose espérer que mon hébergeur va se mettre à jour (voilà pour mes petits besoins personnels).
En revanche, ce que je ne comprends pas c’est l’intérêt de cette diminution de la durée de la validité des certificats. Qu’est-ce que ça apporte, à part des enquiquinements ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Des explications ?
Posté par cg . Évalué à 5 (+3/-0).
L'idée derrière, c'est de limiter l'impact de la compromission d'un serveur, du vol de la partie privée du certificat (la clé), et l'usurpation d'identité du site qui s'ensuit. Le vol d'une telle clé pour un certificat valable 10 ans permet au voleur de se faire passer pour le site pendant 10 ans. Pour un certificat valable pendant 10 jours, le voleur n'aura que 10 jours.
Ça permet aussi aux sites ou autres services abandonnés d'être repérés plus vite.
Voilà pour la théorie.
En pratique, les attaquants vont sans doute s'adapter, et mettront en place un bidule technique qui permettra de recevoir la nouvelle version du certificat à chaque renouvellement. Ce genre d'attaque dans laquelle le voleur reste en place sans se faire repérer est plus complexe à mettre en œuvre. Ça ne changera rien pour les structures mal sécurisées, qui se feront piquer leurs certifs encore et encore sans s'en rendre compte.
Au final, ça relève la barre pour les attaquants, ce qui est bien, mais ça relève aussi un peu la barre pour les attaqués, ce qui est moins sympa.
Ça va aussi sans doute pousser à déployer DNSSEC pour authentifier les réponses DNS, car le protocole ACME repose en partie sur le DNS.
Mon cœur est arc-en-ciel sur le sujet, je ne sais pas si je trouve ça bien ou pas ;)
[^] # Re: Des explications ?
Posté par nud . Évalué à 4 (+2/-0). Dernière modification le 15 avril 2025 à 15:37.
Alors premièrement, l'annonce ne concerne que les navigateurs web. Aujourd'hui un navigateur n'accepte déjà plus un certificat avec une durée de validité supérieure à 398 jours (cf le titre).
Ensuite il existe d'autres façons de vérifier si un certificat est toujours valide :
Il y a OCSP, qui résout le problème mais avec certaines limitations pour la plupart résolues par le "stapling" (agrafage OCSP) mais qui n'est plus supporté par Let's Encrypt depuis janvier 2025) car mal supporté par les navigateurs d'après eux.
Il y a aussi les Certificate Revocation Lists (CRLs), qui sont des fichiers qui contiennent les identifiants de tous les certificats révoqués dont la durée de validité n'est pas dépassée. Let's encrypt est passé à cette technique qui ironiquement a été dépréciée dans Firefox 28 au profit de OCSP. L'inconvénient c'est que plus la durée de validité est longue et plus ces listes sont lourdes.
D'après la proposition:
Mon opinion personnelle est qu'ils auraient mieux fait de faire ça et (en tout cas pour Let's encrypt) d'imposer Must-Staple plutôt que de supprimer le support d'OCSP totalement.
[^] # Re: Des explications ?
Posté par Voltairine . Évalué à 7 (+5/-0).
Une explication sans doute plus accessible :
https://blog.nameshield.com/blog/2024/10/17/ssl-tls-certificate-duration-reduced-to-45-days-by-2027apple-takes-the-first-step/
# Onoz !
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Comment on va faire pour les certificats de méga confiance eIdas RGS généré à la main après validation sécurisée par dépôt de dossier dans une mallette en cuir de confiance par une personne physique de confiance dans un bureau de confiance ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Onoz !
Posté par cg . Évalué à 2 (+0/-0).
Il me semble avoir vu que ce problème est déjà résolu : tu montres tes papiers une fois par an (ou tous les deux ans), et tu peux renouveler tous les x jours. Dommage, ça aurait été une bonne occasion de se débarrasser de ce business juteux.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.