La nouvelle durée de validité des certificats TLS – AVANTEC

À propos de cette offre

À l'avenir, les certificats ne seront valables que pendant 47 jours, ce qui rend l'automatisation indispensable. Avant cette proposition d'Apple, Google avait soutenu une durée maximale de validité de 90 jours, mais a pratiquement immédiatement rejoint l'avis d'Apple. Le calendrier : La durée maximale de validité des certificats sera réduite : Entre aujourd'hui et le 15 mars 2026, la durée maximale de validité d'un certificat TLS est de 398 jours. À partir du 15 mars 2026, la durée maximale de validité des certificats TLS sera de 200 jours. À partir du 15 mars 2027, la durée maximale de validité des certificats TLS sera de 100 jours. À partir du 15 mars 2029, la durée maximale de validité des certificats TLS sera de 47 jours. Je vais expliquer ici, avec l'aide du blog de DigiCert, quel est l'état actuel et comment nous, chez AVANTEC, percevons et abordons ce sujet. Pourquoi 47 jours ? 47 jours peuvent sembler arbitraires, mais ils s'expliquent simplement : 200 jours = nombre maximal de jours dans 6 mois (184 jours) + la moitié d'un mois de 30 jours (15 jours) + 1 jour supplémentaire 100 jours = nombre maximal de jours dans 3 mois (92 jours) + environ un quart d'un mois de 30 jours (7 jours) + 1 jour supplémentaire 47 jours = nombre maximal de jours dans 1 mois (31 jours) + la moitié d'un mois de 30 jours (15 jours) + 1 jour supplémentaire La justification d'Apple pour ce changement Lors du vote, Apple a avancé de nombreux arguments, dont un mérite d'être souligné. Le forum CA/B a clairement indiqué depuis des années, par la réduction constante des durées maximales, que l'automatisation est essentielle pour une gestion efficace du cycle de vie des certificats. Le vote indique que des durées plus courtes sont nécessaires pour plusieurs raisons : Les informations contenues dans les certificats perdent en fiabilité avec le temps, un problème qui ne peut être amélioré que par une revalidation fréquente des informations. La révocation via CRL et OCSP est peu fiable. En réalité, les navigateurs ignorent souvent ces fonctions. Il existe de nombreuses lacunes dans la révocation des certificats. Une durée plus courte réduit les impacts liés à l'utilisation de certificats potentiellement compromis. En 2023, le forum CA/B a encore renforcé sa position en approuvant des certificats éphémères sans CRL ni OCSP, expirant sous 7 jours. Explication de la nouvelle réglementation Deux points de la nouvelle réglementation pourraient prêter à confusion : Les règles changent en 2026, 2027 et 2029, avec un intervalle de deux ans entre les deux dernières années. À partir du 15 mars 2029, la durée maximale de vie d'un certificat TLS sera de 47 jours, mais la réutilisation maximale des informations de validation de domaine ne sera que de 10 jours. Une revalidation manuelle reste techniquement possible, mais entraînera inévitablement des erreurs. Les autorités de certification et nous, chez AVANTEC, sommes souvent interrogés par les clients sur le fait que des renouvellements plus fréquents entraîneraient des coûts plus élevés. La réponse est non. Il s'agit d'un abonnement annuel et nous avons constaté que les utilisateurs remplacent souvent volontairement leurs certificats plus rapidement dès qu'ils passent à l'automatisation. C'est pourquoi, et parce que même les changements concernant les certificats de 100 jours en 2027 ne pourront plus être gérés manuellement, nous prévoyons une transition rapide vers l'automatisation bien avant l'entrée en vigueur des changements en 2029. La déclaration d'Apple sur la gestion automatisée du cycle de vie des certificats est juste et c'est quelque chose pour lequel nous nous sommes préparés depuis longtemps. DigiCert propose avec Trust Lifecycle Manager et CertCentral différentes solutions d'automatisation, y compris le support du protocole ACME. Le protocole ACME de DigiCert permet l'automatisation des certificats DV, OV et EV et inclut le support des ACME Renewal Information (ARI). À propos d'ARI : « ARI est une norme associée par laquelle le serveur peut suggérer un calendrier afin que le client sache renouveler le certificat avant son expiration. Bien configuré, ARI peut ordonner au client de renouveler si le certificat a été révoqué, évitant ainsi une interruption de service ». Le défi De nombreux fabricants d'appliances et de logiciels ne disposent pas encore d'un échange automatique de certificats sur leurs appareils. Il ne reste donc plus beaucoup de temps pour une intégration adéquate. DigiCert propose déjà une variante avec hébergement DNS et automatisation. Nous savons que SwissSign y travaille. Sur le marché libre, « Let’s Encrypt » est déjà présent depuis longtemps avec le support d'ACME ou d'autres mises à jour automatiques. Ce qui me dérange ici, c'est une approche où je dois autoriser l'accès au port 80 d'un serveur web pour le processus automatique. De nos jours, je suis partisan de « toutes les connexions sortantes » et non entrantes. La vérification via une entrée DNS-TXT est donc beaucoup plus sympathique pour moi. Mais comment puis-je automatiquement créer une entrée TXT ? Tous les hébergeurs ne le permettent pas. Si j'ai accès au DNS, la soi-disant DNS-01-Challenge de « Let’s Encrypt » fonctionne également : https://letsencrypt.org/de/docs/challenge-types/#dns-01-challenge. Il y a encore beaucoup de potentiel d'amélioration dans ce domaine. DigiCert procède de manière à héberger directement les domaines et peut ainsi gérer cela « en interne ». Dans la section Compléments, nous voyons qu'on n'est pas obligé d'utiliser leur DNS. C'est assez sympathique. Automatisation Ce sujet mériterait un article de blog à part entière. Peut-être y en aura-t-il un prochainement. Selon https://docs.digicert.com/en/trust-lifecycle-manager/enroll-and-manage-certificates/enrollment-protocols-and-apis.html, il existe différents protocoles et API. Chez quels fabricants trouve-t-on un support pour CMP, EST, SCEP et REST API ? Souvent, ACME est malheureusement la limite. Sur le thème des « solutions d'automatisation gérées », nous trouvons beaucoup d'informations chez DigiCert. https://docs.digicert.com/en/trust-lifecycle-manager/automate-management-of-certificates/managed-automation-solution.html Cela nous laisse avec beaucoup de questions ouvertes. Nous souhaitons automatiser autant que possible toutes les phases du cycle de vie des certificats. Cela est expliqué plus en détail dans le lien. Il reste encore beaucoup de travail ! En résumé : Une grande vague arrive et personne ne veut vraiment l'admettre. Nous restons vigilants et cherchons continuellement des approches possibles afin d'être prêts dans un avenir proche à mettre en œuvre des solutions adaptées avec nos produits. Fin de l'EKU d'authentification client pour les certificats TLS publics DigiCert Je souhaite également mentionner cette information importante. Selon cet article, l'« EKU d'authentification client » sera complètement supprimée d'ici le 1er mai 2026. Les exigences du programme racine Google Chrome demandent des hiérarchies racines TLS spécifiques dont les politiques ne supportent plus, pour des raisons de sécurité, « l'authentification client » et la « signature de code ». Le lien mentionné est un document où les statuts les plus récents sont ajustés et où les étapes temporelles ainsi que le « pourquoi » sont expliqués plus en détail. Complément Ce qui est souvent mentionné dans le contexte de la cryptographie résistante à la QC (cryptographie quantique) : on gagne aussi en agilité cryptographique pour la transition vers les algorithmes PQC. Il ne doit pas forcément s'agir uniquement du DNS chez DigiCert. Beaucoup d'autres sont supportés. Liens complémentaires https://www.digicert.com/de/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days https://www.avantec.ch/loesungen/swisssign/ https://www.avantec.ch/loesungen/digicert/ https://thesmartbug.com/blog/integrating-acme-renewal-information-ari-into-existing-clients/ L'article La nouvelle durée de validité des certificats TLS est initialement paru sur Tec-Bite.