Que sont les certificats de 47 jours : ce qui change, pourquoi c'est important et comment s'y préparer

LeCertification Authority/Browser (CA/B) Forum a officiellement approuvé une réduction de la durée de validité maximale TLS publics de confiance à seulement 47 jours d'ici 2029. Ce changement représente une évolution fondamentale dans la manière dont les organisations doivent aborder la gestion du cycle de vie des certificats (CLM). Si les avantages en matière de sécurité sont évidents, les implications opérationnelles sont considérables. Les organisations qui s'appuient sur des processus manuels trouveront cette nouvelle réalité insoutenable, faisant de l'automatisation et de la gouvernance non seulement des pratiques recommandées, mais aussi des nécessités opérationnelles. 

Que sont les certificats de 47 jours et quels sont les certificats concernés ?

L'obligation relative aux certificats de 47 jours s'applique spécifiquement aux TLS reconnus par le public, c'est-à-dire les identifiants numériques qui sécurisent les sites Web, les applications accessibles au public et certaines infrastructures périphériques. Ces certificats authentifient les serveurs et chiffrent les données en transit, constituant ainsi l'épine dorsale des communications Internet sécurisées. 

• TLS reconnus publiquementsont émis par des autorités de certification (CA) que les navigateurs et les systèmes d'exploitation reconnaissent par défaut. Ils permettent des connexions HTTPS sécurisées pour les utilisateurs externes sans nécessiter de configuration manuelle de confiance. La limitation de 47 jours s'applique exclusivement à ces certificats. 

• Les certificats privés ou internes, émis par PKI privée d'une organisation, ne sont pas directement concernés par cette obligation. Les organisations peuvent continuer à émettre des certificats internes avec des durées de vie plus longues si leurs cas d'utilisation le justifient. Cependant, de nombreuses organisations soucieuses de la sécurité choisissent de reproduire les meilleures pratiques en matière de certificats publics dans leur PKI privée PKI maintenir une posture de sécurité et des processus opérationnels cohérents. 

Le déploiement se fera de manière progressive plutôt que d'un passage immédiat à 47 jours : 

• Mars 2026: la durée maximale de validité passe à 200 jours. 

• 2027: nouvelle réduction à 100 jours 

• 2029: dernière étape vers une durée de validité maximale de 47 jours 

Ces périodes de validité comprennent des fenêtres de renouvellement intégrées. Le certificat de 47 jours, par exemple, est conçu pour une durée de vie opérationnelle d'environ 30 jours, plus une marge de 17 jours pour les activités de renouvellement. Cette structure signifie que les organisations devront renouveler leurs certificats environ tous les mois, ce qui se traduira par 8 à 12 cycles de renouvellement par an et par certificat, en fonction de la marge de temps qu'elles maintiennent. 

Les certificats concernés par ce changement font souvent partie des actifs les plus critiques d'une organisation. Ils ne sont pas isolés sur un seul serveur web. Un déploiement type peut inclure : 

• Serveurs Web et serveurs d'applications 

• Équilibreurs de charge qui terminent TLS 

• Charges de travail dans le cloud et applications conteneurisées 

• Infrastructure périphérique et réseaux de diffusion de contenu 

• Passerelles API et points de terminaison de microservices 

Un certificat peut être déployé simultanément à plusieurs endroits : un équilibreur de charge, plusieurs serveurs d'applications et des systèmes de sauvegarde. Cette multiplicité amplifie le défi opérationnel que représentent les renouvellements fréquents. 

Comment le secteur est-il passé de certificats d'une durée de 10 ans à des certificats d'une durée de 47 jours ?

Le cheminement vers les certificats de 47 jours s'étend sur plus d'une décennie de réductions progressives : 

• Avant 2012: les certificats pouvaient être valables pendant 10 ans. 

• 2012: durée de validité maximale réduite à 5 ans 

• 2015: nouvelle réduction à 3 ans 

• 2018: Réduction à 2 ans (825 jours) 

• 2020: norme actuelle de 398 jours (environ 13 mois) 

• 2026-2029: réduction progressive à 47 jours 

La transition vers 398 jours en 2020 offre des enseignements importants pour le changement actuel. Google a initialement proposé de raccourcir la durée de vie des certificats et a soumis cette mesure au vote du CA/B Forum. La proposition a été rejetée. Cependant, Apple a annoncé de manière indépendante que son navigateur natif, Safari, n'accepterait pas les certificats dont la durée de validité dépasserait 398 jours, forçant ainsi l'ensemble du secteur à suivre le mouvement. Les autorités de certification n'ont eu d'autre choix que de se conformer, et les autres navigateurs ont emboîté le pas. 

Le passage actuel aux certificats de 47 jours suit un schéma différent. Cette fois-ci, le changement est impulsé par les autorités de certification (CA) dans le cadre d'un processus de vote officiel, plutôt que d'être imposé unilatéralement par un fournisseur de navigateur. Apple a présenté le projet de résolution SC081v3, qui proposait un calendrier de réduction progressive, et celui-ci a été adopté par le forum CA/B. Étant donné que les autorités de certification ne délivreront pas de certificats dépassant ces nouvelles limites de validité, les organisations n'ont pas d'autre choix que de s'adapter. 

La réaction du secteur a été mitigée. Alors que les fournisseurs de solutions de sécurité et les autorités de certification soutiennent généralement ce changement, les administrateurs système et PKI expriment de vives inquiétudes. Les discussions en ligne révèlent la tension entre les idéaux de sécurité et les réalités opérationnelles. Un administrateur s'est demandé si la prochaine étape logique serait les « certificats d'une seconde », soulignant sa frustration face au rythme du changement. D'autres ont souligné que de nombreux systèmes hérités et infrastructures actuelles ne prennent pas en charge les protocoles de renouvellement automatisé prêts à l'emploi, ce qui crée un problème important de dette technique. 

Pourquoi les navigateurs et les autorités de certification poussent-ils pour des certificats valables 47 jours ?

La tendance vers des certificats valables 47 jours découle de trois objectifs interdépendants qui vont au-delà de simples améliorations en matière de sécurité. 

Sécurité renforcée et rayon d'action réduit 

La réduction de la durée de vie des certificats réduit directement la fenêtre d'opportunité dont disposent les pirates pour exploiter les certificats ou les clés privées compromis. Ce principe de sécurité reflète les politiques de rotation des mots de passe : plus les identifiants changent fréquemment, moins les adversaires ont de temps pour exploiter les identifiants volés ou compromis. 

Cela devient particulièrement pertinent dans le contexte des attaques de type « récolter maintenant, déchiffrer plus tard ». Les adversaires disposant de ressources suffisantes peuvent aujourd'hui intercepter et stocker le trafic chiffré, en pariant qu'ils finiront par obtenir les clés de déchiffrement ou que les ordinateurs quantiques rendront les algorithmes de chiffrement actuels vulnérables. Une rotation plus fréquente des clés rend cette stratégie beaucoup plus difficile à mettre en œuvre avec succès. Chaque nouveau certificat utilise une nouvelle paire de clés, ce qui limite la quantité de trafic historique qu'une seule clé compromise peut décrypter. 

Lorsque des certificats sont compromis (à la suite d'une violation du serveur, d'une mauvaise configuration ou d'une attaque de la chaîne d'approvisionnement), leur durée de vie plus courte limite les dommages. Un certificat compromis valable pendant 47 jours présente un risque bien moindre qu'un certificat valable pendant un an. 

Accélérer le passage à l'automatisation et PKI modernes 

Apple et Google utilisent explicitement la réduction de la durée de vie des certificats comme un mécanisme visant à pousser le secteur versCLM automatiséeCLM. Les processus de renouvellement manuels, qui peuvent être tolérables avec des certificats annuels, deviennent totalement intenables lorsque les certificats doivent être renouvelés toutes les quelques semaines. 

Cette fonction contraignante est intentionnelle. La gestion manuelle des certificats à grande échelle introduit des erreurs humaines, crée des goulots d'étranglement opérationnels et expose les organisations à des pannes dues à l'expiration des certificats. En rendant les processus manuels opérationnellement impossibles, le secteur oblige effectivement les organisations à adopter des pratiques d'automatisation modernes. 

Les avantages de la transition vont au-delà de la simple prévention des pannes. La gestion automatisée des certificats permet : 

• Application cohérente des politiques pour tous les certificats 

• Réduction des frais généraux opérationnels et de l'épuisement professionnel des équipes 

• Meilleure visibilité sur l'inventaire et l'utilisation des certificats 

• Réponse plus rapide aux incidents de sécurité nécessitant le remplacement d'un certificat 

• Fondation pour la gestion des futures transitions cryptographiques 

Se préparer à l'ère post-quantique et à la crypto-agilité 

La date butoir de 2029 n'est pas le fruit du hasard. Le NIST a établi un calendrier pour la transition vers la cryptographie post-quantique (PQC), 2030 étant l'année où les algorithmes actuels tels que RSA et ECC commenceront à être abandonnés au profit d'alternatives résistantes à la cryptographie quantique. 

Les organisations qui auront automatiséCLM 2029 seront bien mieux placées pour gérer la transition post-quantique. Le remplacement des algorithmes cryptographiques sur des milliers, voire des millions de certificats nécessite la même infrastructure d'automatisation que celle requise pour les renouvellements fréquents. L'obligation de renouvellement des certificats tous les 47 jours donne essentiellement aux organisations un délai de cinq ans pour mettre en place les capacités d'automatisation dont elles auront besoin pour la transition quantique. 

La crypto-agilité, c'est-à-dire la capacité à modifier rapidement les algorithmes cryptographiques et les types de clés sur l'ensemble d'une infrastructure, devient un avantage concurrentiel et une nécessité en matière de sécurité. Les organisations qui attendront 2030 pour se pencher sur la question de l'automatisation devront faire face à une course chaotique pour remplacer les algorithmes tout en gérant simultanément des certificats à courte durée de vie. 

Quels changements les certificats de 47 jours apporteront-ils au quotidien pour les équipes PKI sysadmin ?

L'impact opérationnel des certificats valables 47 jours va bien au-delà du simple renouvellement plus fréquent des certificats. Ce changement affecte de manière fondamentale les flux de travail, la dynamique des équipes, les processus de validation et la gestion des infrastructures. 

La fréquence des renouvellements explose 

Le changement le plus évident est l'augmentation spectaculaire de la fréquence de renouvellement. Les organisations qui renouvellent actuellement leurs certificats chaque année passeront à des renouvellements toutes les quelques semaines. Un certificat qui nécessitait auparavant une attention annuelleexigera désormais8 à 12 cycles de renouvellement par an. 

Une étude de Gartnerindique que le renouvellement complet d'un certificat, depuis la génération de la paire de clés jusqu'à la vérification finale du déploiement, nécessite généralement entre 3 et 6 heures de travail humain lorsqu'il est effectué manuellement. Cela comprend : 

• Génération de la paire de clés sur le système cible 

• Création et soumission de la demande de signature de certificat (CSR) 

• Obtenir l'accord des parties prenantes concernées 

• En attente de validation et de délivrance par l'autorité de certification 

• Téléchargement et installation du nouveau certificat 

• Vérification de l'installation et du bon fonctionnement 

• Redémarrage potentiel des services pour activer le nouveau certificat 

Multipliez ces 3 à 6 heures par 8 à 12 cycles de renouvellement par certificat, puis multipliez le résultat par le nombre total de certificats publics de confiance dans votre environnement. Pour les organisations qui possèdent des centaines ou des milliers de certificats publics, le calcul devient impossible sans automatisation. 

Charge opérationnelle et risque d'épuisement professionnel 

La gestion des certificats incombe rarement uniquement à PKI . Le processus de bout en bout implique généralement : 

• Équipes PKI de sécurité gérant les relations et les politiques des autorités de certification 

• Propriétaires d'applications qui comprennent les dépendances des services 

• Équipes chargées de l'infrastructure qui gèrent les serveurs et les équilibreurs de charge 

• Équipes réseau chargées de DNS 

• Équipes de gestion du changement qui coordonnent les fenêtres de maintenance 

Chaque cycle de renouvellement nécessite une coordination entre ces différents groupes. Le processus de renouvellement des certificats comporte plusieurs étapes (génération de clés, création de CSR, validation par l'autorité de certification, émission, déploiement, vérification et redémarrage éventuel des services), ce qui crée de multiples points où des retards ou des erreurs peuvent survenir. 

Le coût humain ne se limite pas au temps consacré aux renouvellements. Les changements constants de contexte, les demandes de renouvellement urgentes et le stress lié à la prévention des pannes contribuent à l'épuisement des équipes. Lorsque le renouvellement des certificats devient une tâche hebdomadaire ou bihebdomadaire plutôt qu'un événement annuel, il peut accaparer toute la bande passante de l'équipe et empêcher le travail sur des initiatives stratégiques. 

La fenêtre de validation rétrécit 

Les exigences en matière de validation de domaine (DV) sont également renforcées, tout comme la durée de validité des certificats. Actuellement, la validation de la propriété d'un domaine reste généralement valable pendant un an. Dans le nouveau cadre, la validité DV est réduite à environ 10 jours. 

Cela signifie que les organisations doivent gérer les enregistrements DNS ou les fichiers de validation HTTP beaucoup plus fréquemment. Pour les organisations disposant d'un portefeuille de domaines important, cela se traduit par une campagne de validation continue plutôt qu'un événement annuel. Le processus de validation doit être automatisé, sinon il devient une autre tâche manuelle impossible à gérer. 

Les déploiements hérités et multi-sauts sont exposés 

De nombreux déploiements de certificats sont plus complexes qu'il n'y paraît. Un seul certificat peut devoir être installé sur : 

• Un équilibreur de charge qui termine TLS 

• Plusieurs serveurs d'applications derrière l'équilibreur de charge 

• Systèmes de sauvegarde ou de basculement 

• Environnements de développement et de test qui reflètent la production 

Les renouvellements partiels, où un certificat est mis à jour sur 9 serveurs sur 10, créent des risques cachés d'interruption de service. Le dixième serveur continue d'utiliser l'ancien certificat jusqu'à son expiration, puis tombe en panne. Avec les renouvellements annuels, ces déploiements partiels peuvent passer inaperçus pendant des mois. Avec les renouvellements mensuels, la probabilité de déploiements partiels et d'interruptions de service qui en résultent augmente considérablement. 

Le mandat de 47 jours mettra en évidence ces modèles de déploiement complexes à plusieurs étapes et obligera les organisations à les documenter et à les automatiser correctement. 

Quels sont les principaux risques si vous ne vous adaptez pas ? 

Les organisations qui ne se préparent pas à l'expiration des certificats de 47 jours s'exposent à plusieurs types de risques, allant des perturbations opérationnelles aux vulnérabilités stratégiques. 

Pannes dues à des certificats expirés ou partiellement renouvelés 

Les pannes liées à l'expiration des certificats suivent un schéma prévisible : un système critique cesse de fonctionner, les utilisateurs ne peuvent plus se connecter, l'entreprise subit des pertes de revenus et les équipes s'efforcent d'identifier la cause du problème. Finalement, quelqu'un découvre qu'un certificat a expiré. À ce stade, toutes les personnes impliquées dans la réponse à l'incident ont perdu un temps précieux et l'entreprise a subi des dommages financiers et une atteinte à sa réputation. 

Le « jeu des reproches en cas de panne de certificat » est devenu une blague courante dans les milieux informatiques : lorsqu'un système tombe en panne, tout le monde se cache pour essayer de déterminer qui est responsable. Inévitablement, PKI est mise en cause, même lorsque la cause profonde est un manque de processus, une documentation insuffisante ou une responsabilité mal définie. 

Avec des certificats valables 47 jours, la fréquence des interruptions potentielles augmente proportionnellement si les processus restent manuels. Les certificats les plus importants, ceux qui sécurisent les services destinés aux clients et les applications métier critiques, sont ceux qui sont les plus susceptibles de provoquer des interruptions visibles et coûteuses lorsqu'ils expirent. 

Informatique fantôme et achats non autorisés de certificats publics 

Lorsque les processus officiels d'obtention de certificats sont lents ou fastidieux, les unités commerciales les contournent souvent complètement. Les propriétaires d'applications qui « ne peuvent pas attendre l'équipe PKI s'adressent directement à une autorité de certification publique et achètent des certificats à l'aide de cartes de crédit d'entreprise. 

Ces certificats fantômes existent en dehors des systèmes officiels d'inventaire et de gestion. Ils sont soumis aux mêmes limites de validité de 47 jours que les certificats gérés officiellement, mais ils ne bénéficient d'aucune automatisation ni visibilité. Lorsqu'ils expirent, personne ne reçoit d'alerte et aucun processus de renouvellement n'existe. 

Ce mandat de 47 jours entraînera probablement une augmentation initiale des achats de certificats informatiques parallèles, les équipes recherchant des solutions rapides pour répondre aux exigences de renouvellement fréquentes. Les organisations doivent rendre l'achat officiel de certificats rapide et facile, sinon elles perdront la visibilité sur une partie importante de leur inventaire de certificats. 

Les certificats génériques comme points de défaillance uniques 

Les certificats génériques, qui sécurisent tous les sous-domaines d'un domaine (*.exemple.com), sont pratiques sur le plan opérationnel, mais créent un risque concentré. Un seul certificat générique peut être déployé sur des centaines de serveurs et de services. 

Lorsqu'un certificat générique expire, tous les systèmes qui l'utilisent tombent simultanément en panne. Un fournisseur de jeux vidéo a documenté son expérience avec l'expiration d'un certificat générique qui a mis hors service l'ensemble de son infrastructure backend, affectant des milliers d'utilisateurs. Cet incident est devenu un cas d'école public illustrant ce qu'il ne faut pas faire avec les certificats génériques. 

Le mandat de 47 jours amplifie le risque lié aux certificats génériques. Plus un certificat doit être renouvelé fréquemment, plus les risques d'échec du renouvellement sont élevés. Un certificat générique déployé sur 100 sites doit être renouvelé et déployé avec succès sur l'ensemble des 100 sites chaque mois. Si vous en manquez un seul, vous vous retrouvez avec un déploiement partiel susceptible de provoquer une panne. 

Le bouleversement post-quantique en 2030 

Les organisations qui n'auront pas mis en place l'automatisation du cycle de vie des certificats d'ici 2029 seront confrontées à une crise en 2030, lorsque la transition vers la cryptographie post-quantique commencera. Il est tout simplement impossible de remplacer des milliers de certificats par de nouveaux algorithmes tout en gérant manuellement leur durée de vie de 47 jours. 

Les organisations qui investissent aujourd'hui dans l'automatisation considéreront la transition post-quantique comme un simple changement de configuration : elles mettront à jour les paramètres de l'algorithme et laisseront l'automatisation se charger du déploiement. Les organisations qui n'ont pas recours à l'automatisation devront mener un projet de plusieurs années pour remplacer manuellement chaque certificat, tout en essayant de mettre en œuvre l'automatisation qu'elles auraient dû mettre en place des années plus tôt. 

Où en sont la plupart des organisations aujourd'hui ? 

Comprendre l'état actuel de la gestion des certificats dans la plupart des organisations permet de contextualiser le défi à relever. Malgré les progrès réalisés dans le domaine de PKI , de nombreuses organisations continuent de s'appuyer sur des approches obsolètes. 

Outils fragmentés et lacunes en matière de visibilité 

Les environnements typiques de gestion des certificats comprennent : 

• Tableurs permettant de suivre l'inventaire des certificats (souvent obsolètes) 

• Bases de données ad hoc gérées par des équipes individuelles 

• Outils d'analyse réseau qui détectent les certificats sur le réseau 

• Plusieurs portails CA pour différents fournisseurs de certificats 

• Scripts personnalisés pour des cas d'utilisation spécifiques 

Aucun de ces outils n'offre une visibilité complète en temps réel. Les certificats les plus importants, ceux qui sécurisent les services critiques, sont souvent ceux qui manquent dans l'inventaire officiel. Comme l'a dit un professionnel : « Les certificats les plus importants sont ceux qui ne figurent pas dans votre feuille de calcul. » 

Absence de propriété claire ou de responsabilité 

Dans de nombreuses organisations, la responsabilité des certificats est répartie entre plusieurs équipes sans qu'il y ait de responsabilité claire. PKI peut gérer les relations avec les autorités de certification, mais ce sont les équipes chargées des applications qui demandent et installent les certificats, les équipes chargées de l'infrastructure qui gèrent les serveurs et les équipes chargées de la sécurité qui définissent les politiques. 

Cette dilution des responsabilités engendre une tragédie des biens communs : si tout le monde détient des certificats, personne n'en détient réellement. Lorsque quelque chose tourne mal, la réaction par défaut consiste à pointer du doigt plutôt qu'à résoudre systématiquement le problème. 

Processus manuels et incohérents 

Même les organisations disposant de processus certifiés bien définis s'appuient souvent largement sur des étapes manuelles : 

• Les propriétaires d'applications génèrent manuellement des CSR contenant des informations incohérentes. 

• Les workflows d'approbation impliquent des chaînes d'e-mails et des mises à jour de feuilles de calcul. 

• L'installation du certificat nécessite des sessions SSH manuelles ou des connexions RDP. 

• La vérification dépend des tests manuels effectués par les administrateurs sur les services. 

• Les renouvellements sont suivis dans des calendriers et des systèmes de rappel. 

Les erreurs humaines dans la création des CSR (certificats de signature de certificat) — fautes de frappe dans les noms de domaine, tailles de clés incorrectes, noms alternatifs manquants — entraînent des retards et des retouches. Les processus manuels sont également lents, ce qui crée des frictions entre les équipes de sécurité qui tentent d'appliquer la politique et les équipes d'application qui tentent de déployer rapidement les services. 

Dépendance excessive à l'égard des certificats publics alors qu'une infrastructure PKI privée PKI  

De nombreuses organisations utilisent par défaut des certificats publics de confiance pour leurs services internes qui ne sont jamais exposés à l'Internet public. Cela s'explique par plusieurs raisons : 

• PKI privée n'était pas disponible ou était difficile à utiliser. 

• Les équipes chargées des applications avaient besoin de certificats rapidement et se sont tournées vers des autorités de certification publiques. 

• Manque de compréhension quant au moment où la confiance du public est réellement nécessaire 

• Décisions historiques qui n'ont jamais été réexaminées 

L'utilisation de certificats publics pour les services internes engendre des coûts inutiles, des frais généraux opérationnels et, désormais, des renouvellements plus fréquents que nécessaire. Le mandat de 47 jours offre l'occasion de réévaluer les services qui nécessitent réellement la confiance du public et de transférer les charges de travail appropriées vers PKI privée PKI une durée de vie plus longue. 

À quoi ressemble le cycle de vie moderne d'un certificat valable 47 jours ? 

Pour être prêt à délivrer des certificats valables 47 jours, il faut repenser la gestion des certificats comme un système intégré plutôt que comme un ensemble de tâches manuelles. L'état cible englobe plusieurs capacités clés. 

Inventaire complet et visibilité en temps réel 

Une gestion efficace des certificats commence par connaître les certificats existants, leur emplacement et leur date d'expiration. Cela nécessite plusieurs mécanismes de découverte : 

• Les intégrations CAqui extraient directement les données relatives à la délivrance des certificats auprès des autorités de certification publiques et privées constituent la source faisant autorité pour connaître les certificats qui ont été délivrés. 

• Les solutions de découverte réseauanalysent TLS à travers l'infrastructure, identifiant les certificats en cours d'utilisation. Cela permet de détecter les certificats qui auraient pu être émis en dehors des canaux officiels ou déployés sans documentation appropriée. 

• La recherche directe dans le magasin de clés et les appareilsexamine directement les magasins de certificats, les équilibreurs de charge, les services cloud et les applications. Cette approche permet de trouver les certificats qui ne sont peut-être pas activement utilisés pour TLS , mais qui sont toujours présents dans l'environnement. 

La combinaison de ces angles de découverte offre une visibilité complète. Aucune méthode ne permet à elle seule de tout saisir, mais ensemble, elles donnent une image complète. 

Gouvernance, propriété et politique définies 

Une définition claire des responsabilités et des obligations empêche les accusations mutuelles qui suivent généralement les incidents liés aux certificats. Une gouvernance efficace comprend : 

Propriétaires définispour chaque certificat ou catégorie de certificats, responsables des renouvellements, des mises à jour et des interventions en cas d'incident. 

• Workflows basés sur les rôlesqui acheminent les demandes, les approbations et les renouvellements de certificats vers les équipes appropriées en fonction de l'objectif et du niveau de risque du certificat. 

• Profils normalisésqui définissent les tailles de clés, les algorithmes, les durées de vie, les conventions de dénomination et les politiques relatives aux caractères génériques acceptables. La normalisation réduit les erreurs et garantit la cohérence. 

• Application de politiquesqui empêchent la délivrance de certificats non conformes aux normes organisationnelles, permettant ainsi de détecter les problèmes avant le déploiement des certificats. 

Automatisation tout au long du cycle de vie, pas seulement lors de l'inscription 

La véritable automatisation va au-delà de la simple demande et réception de certificats. Elle englobe : 

• ACME et protocoles similairespour l'inscription automatisée lorsqu'ils sont adaptés. ACME fonctionne bien pour les serveurs Web et les environnements Kubernetes, mais ne résout pas tous les cas d'utilisation. 

• Cert-manager pourles environnements Kubernetes, avec intégrations appropriées aux autorités de certification.  

• Intégration de l'infrastructure en tant que codeavec des outils tels que Terraform, permettant l'intégration du provisionnement des certificats dans le déploiement automatisé de l'infrastructure. 

• Gestion du cycle de vie des certificats (CLM) et orchestrationpour les déploiements complexes à plusieurs sauts et les systèmes hérités qui ne prennent pas en charge les protocoles modernes. Les solutions d'orchestration peuvent déployer des certificats vers diverses cibles, notamment des équilibreurs de charge, des serveurs d'applications, des magasins de certificats et des systèmes de fichiers distants. 

• Alerte et confirmationque les certificats ne sont pas seulement émis, mais également déployés et actifs. Une émission sans déploiement crée un faux sentiment de sécurité. 

Séparation des préoccupations pour les redémarrages et le contrôle des changements 

CertainsCLM offrent la possibilité de redémarrer automatiquement les services après le déploiement d'un certificat. Bien que cela semble pratique, cela comporte des risques. Le redémarrage automatique des services de production sans contrôle approprié des changements peut entraîner des interruptions imprévues. 

Une meilleure approche consiste à séparer le déploiement des certificats du redémarrage des services : 

• Les solutions d'automatisation gèrent le renouvellement et le déploiement des certificats. 

• Le système informe la gestion des changements qu'un nouveau certificat est en place. 

• La gestion du changement coordonne les redémarrages des services pendant les fenêtres de maintenance approuvées. 

• Une surveillance et une alerte adéquates permettent de détecter tout problème lié au processus de redémarrage. 

Cette séparation garantit que les renouvellements de certificats ont lieu dans les délais impartis, tandis que les redémarrages de service suivent les procédures de contrôle des changements appropriées. 

CommentKeyfactor -t-il dans le passage aux certificats de 47 jours ? 

Bien que le passage aux certificats de 47 jours soit motivé par les autorités de certification publiques et les navigateurs, ce sont les organisations, et non les autorités de certification, qui supportent la charge opérationnelle liée aux renouvellements fréquents. Le rôle Keyfactorest de les aider à gérer efficacement ce changement. 

Keyfactor la visibilité sur tous les certificats 

Keyfactor Command offre une découverte complète des certificats émis par les autorités de certification, des terminaux réseau et des magasins de certificats. Cette approche multi-angles aide les organisations à identifier les certificats inconnus ou non gérés qui présentent des risques de panne. La plateforme prend en charge PKI publics et privés, offrant aux équipes une source unique et fiable pour l'ensemble de leur inventaire de certificats, quel que soit leur origine ou leur mode de déploiement. 

La gestion indépendante du système d'exploitation simplifie les opérations 

Les organisations font souvent appel à plusieurs autorités de certification (CA) : différents fournisseurs pour différents cas d'utilisation, relations historiques ou exigences géographiques. La gestion séparée de chaque CA devient ingérable avec des certificats à courte durée de vie. Keyfactor aux équipes de standardiser les processus et les politiques de toutes les CA sur une seule plateforme. Cela élimine les incohérences et les inefficacités liées à la gestion de plusieurs portails, chacun avec des interfaces et des flux de travail différents. 

Automatisation du processus complet de renouvellement 

Les durées de vie courtes nécessitent plus qu'une simple inscription ACME ; les organisations doivent garantir le déploiement, la vérification et la surveillance continue. Keyfactor les tâches de cycle de vie de bout en bout, réduisant le processus de renouvellement manuel de 3 à 6 heures à un flux de travail évolutif. Les capacités d'orchestration de la plateforme garantissent que les certificats atteignent réellement chaque point d'extrémité dans un déploiement multi-systèmes, et pas seulement le premier serveur d'une chaîne. 

Découvrir la cryptographie dans toute l'entreprise 

Au-delà des certificats, les organisations ont besoin de visibilité sur les algorithmes cryptographiques, les clés et les dépendances. Les solutions de découverte cryptographique Keyfactoraident les équipes à comprendre où la cryptographie est utilisée et si elle est obsolète ou vulnérable. Il s'agit d'une préparation essentielle pour les transitions futures telles que la cryptographie post-quantique. Les équipes peuvent identifier quels systèmes utilisent quels algorithmes, évaluer l'ampleur des changements nécessaires et planifier des stratégies de migration avant la date limite de 2030. 

Jeter les bases de la crypto-agilité 

Les organisations qui automatisent dès maintenant la gestion des certificats seront mieux préparées aux changements à venir dans leur secteur.Keyfactor l'infrastructure et l'automatisation nécessaires pour remplacer les certificats ou les algorithmes à grande échelle. Lorsque les algorithmes post-quantiques deviendront obligatoires, les organisations disposantCLM matureCLM traiter cette transition comme un simple changement de configuration plutôt que comme un projet de crise s'étalant sur plusieurs années. 

Comment les organisations devraient-elles commencer à se préparer dès maintenant ? 

La préparation aux certificats de 47 jours ne nécessite pas de tout mettre en œuvre immédiatement, mais il faut commencer dès maintenant. Les organisations disposent d'une période de plusieurs années pour développer leurs capacités avant la date limite de 2029. 

• Commencez par la visibilité et l'inventaire.Avant de pouvoir automatiser la gestion des certificats, vous devez savoir quels certificats existent. Mettez en place un système de détection couvrant les autorités de certification publiques et privées, les terminaux réseau et les magasins de certificats. Documentez les certificats informatiques parallèles et les déploiements génériques. La compréhension de votre situation actuelle est la base de tout le reste. 

• Classez les certificats en fonction du risque, de l'environnement et de la faisabilité de l'automatisation.Tous les certificats ne sont pas égaux. Les services Web destinés aux clients nécessitent un traitement différent de celui des systèmes de développement internes. Identifiez les certificats les plus critiques pour les opérations commerciales et ceux qui sont les plus faciles à automatiser. Cette classification guide la hiérarchisation des priorités. 

• Normalisez les politiques et résolvez les problèmes évidents.Avant d'automatiser les mauvaises pratiques, corrigez-les. Éliminez les certificats génériques inutiles, transférez les services internes vers PKI privée PKI approprié, normalisez les tailles de clés et les algorithmes, et établissez des conventions de nommage claires. Nettoyez votre environnement de certificats avant de l'automatiser. 

• Automatisation pilote dans un domaine confiné.Choisissez un sous-ensemble bien défini de votre inventaire de certificats pour l'automatisation initiale, par exemple les serveurs front-end Web ou une pile d'applications spécifique. Mettez en œuvre une automatisation de bout en bout pour ce domaine, tirez les leçons de cette expérience et documentez ce qui fonctionne. Ensuite, étendez progressivement cette automatisation à d'autres domaines. 

• Utilisez le changement prévu dans 47 jours comme catalyseur pour moderniser PKI publiques et privées.Bien que cette obligation ne concerne que les certificats publics, les capacités d'automatisation et de gouvernance que vous développerez profiteront à l'ensemble de votre PKI . Les organisations qui considèrent cela comme un effort de modernisation global plutôt que comme une simple case à cocher pour se conformer à la réglementation en tireront des avantages plus larges. 

Le passage aux certificats de 47 jours est inévitable. Les organisations qui commencent à s'y préparer dès maintenant vivront cette transition comme une évolution maîtrisée. Celles qui attendront seront confrontées à une crise.