C’est officiel : la durée de vie des certificats SSL/TLS va être réduite à 47 jours

la durée de vie des certificats SSL/TLS va être réduite à 47 jours

Le 9 octobre 2024, Apple annonçait au CA/B Forum (Certification Authority Browser Forum), sa volonté de réduire la durée maximale des certificats SSL/TLS publics à 45 jours d’ici 2027 mais aussi de réduire la période de réutilisation des challenges DCV à 10 jours d’ici 2027.

Cette demande avait ensuite été discutée, puis amendée, 6 mois plus tard, toujours par Apple, qui proposait une modification de l’agenda initial avec une durée de certificats réduite à 47 jours pour les certificats SSL/TLS et une durée de validation des challenges DCV de 10 jours à partir du 15 mars 2028.

Cette mesure entre officiellement en vigueur, suite au vote du CA/B Forum datant d’avril 2025, qui adopte un nouveau calendrier de mise en œuvre, réduisant officiellement la validité des certificats à 47 jours et favorisant ainsi l’automatisation pour la bonne gestion de ces certificats.

  • Jusqu’au 15 mars 2026, la durée de vie maximale d’un certificat TLS est maintenue à 398 jours.
  • À compter du 15 mars 2026, la durée de vie maximale d’un certificat TLS sera de 200 jours.
  • À compter du 15 mars 2027, elle passera à 100 jours.
  • Et à compter du 15 mars 2029, la durée de vie maximale d’un certificat TLS sera réduite à 47 jours.
Durée de vie des certificats SSL/TLS

En parallèle, les périodes de réutilisation de la Validation du Contrôle de Domaine (challenge DCV), qui impliquent d’intervenir dans la zone du nom de domaine listé dans le certificat pour le valider, seront alignées au calendrier des certificats, jusqu’à atteindre 10 jours en 2029.

  • Jusqu’au 15 mars 2026, la période maximale pendant laquelle les informations de validation de domaine peuvent être réutilisées est de 398 jours.
  • À compter du 15 mars 2026, la période maximale pendant laquelle les informations de validation de domaine peuvent être réutilisées est de 200 jours.
  • À compter du 15 mars 2027, la période maximale pendant laquelle les informations de validation de domaine peuvent être réutilisées est de 100 jours.
  • À compter du 15 mars 2029, la période maximale pendant laquelle les informations de validation de domaine peuvent être réutilisées est de 10 jours.
période de réutilisation des challenges DCV

Face à ces changements majeurs dès 2026, il est essentiel pour les entreprises de se préparer

L’impulsion du CA/B Forum va transformer progressivement le paysage de la sécurité des certificats numériques. La durée de validité des certificats SSL/TLS va se voir réduite, accompagnée par un durcissement des règles de validation des challenges DCV. La clé d’une bonne gestion à venir des certificats repose donc sur l’automatisation. 47 jours de durée des certificats en 2029 c’est 9 interventions par an par certificat, la gestion manuelle deviendra utopique. Il faut donc s’appuyer sur les différents services/logiciels suivants :

  • Fournisseur de certificats / Autorité de Certification (AC) : un partenaire de confiance qui vous accompagnera dans les problématiques d’authentification des organisations et domaine. Le niveau de service est la clé pour une bonne gestion. Un partenaire multi-AC est recommandé pour limiter la dépendance à une seule AC, cas des récents déboires d’Entrust.

  • Registrar / DNS Primaire : maîtriser le DNS primaire des noms de domaine listés dans les certificats va devenir la clé de la livraison. Chaque émission de certificat entrainera l’installation d’un TXT ou d’un CNAME sur la ou les zones concernées. Avoir une interconnexion entre l’AC et le DNS est primordial.

  • Editeur CLM : inventorier le parc de certificats, définir des règles de gestion du parc et assurer l’automatisation complète du processus de commande depuis la génération des CSR jusqu’au déploiement des certificats sur les serveurs, c’est le travail du CLM. Et celui-ci pour fonctionner, s’appuie sur des connecteurs avec les AC ou fournisseurs de Certificats.

Se préparer c’est donc identifier les solutions qui vous conviennent sur ces trois points et lancer cette réflexion pour comprendre les impacts en matière de processus, de technologie et de budget, pour être prêts idéalement au premier semestre 2026.

Nameshield, un allié, pour vous aider à faire face à ces changements 

Nameshield occupe une place unique sur le marché en étant registrar et fournisseur de certificats multi-AC. Depuis plus de 10 ans, nous gérons au quotidien toutes les problématiques liées à l’authentification des organisations et des domaines liés aux certificats en ayant d’un côté, une relation privilégiée avec les plus grandes AC du marché (Digicert, Sectigo, GlobalSign), et en maitrisant de l’autre la brique DNS pour la validation des challenges DCV. De ce fait, nous émettons des certificats publics de manière quasi instantanée. Enfin, en ce qui concerne la brique CLM, Nameshield dispose de connecteurs avec les plus grands acteurs du marché pour vous permettre d’assurer une connexion complète entre les différentes briques liées à la gestion des certificats. Nous vous accompagnons ainsi dans l’anticipation de l’ensemble des problématiques mentionnées ci-dessus.

Vous souhaitez aller plus loin afin de tout comprendre sur le contexte de ces changements et leurs impacts sur la gestion de vos certificats ? Notre webinar « Réduction de la durée des certificats SSL/TLS à 45 jours : Comment se préparer face au challenge de l’automatisation ? » est disponible en replay.

Pour toute autre question, vous pouvez contacter Nameshield directement ici.

[REPLAY WEBINAR] Réduction de la durée des certificats SSL/TLS à 45 jours : Comment se préparer face au challenge de l’automatisation ?

[REPLAY WEBINAR] Réduction de la durée des certificats SSL/TLS à 45 jours : Comment se préparer face au challenge de l’automatisation ?

Retrouvez sur le site de Nameshield et sur Webikeo le replay du webinar « Réduction de la durée des certificats SSL/TLS à 45 jours : Comment se préparer face au challenge de l’automatisation ?», animé par Christophe GÉRARD, Directeur Produits de Nameshield et Alexandre AUFRERE, Directeur Technique d’Evertrust.

En 2023, Google annonçait son intention de réduire la durée des certificats à 90 jours et le 9 octobre 2024, Apple proposait un premier calendrier prévisionnel indiquant une durée des certificats réduite à 45 jours en 2027 et la limitation à 10 jours pour le challenge DCV. Une mise à jour d’Apple a très récemment été publiée annonçant reculer son calendrier de 6 mois, avec pour nouvel objectif, des certificats de 47 jours en mars 2028.

Ces annonces sonnent le glas de la gestion manuelle des certificats SSL/TLS publics et lancent officiellement le besoin d’automatisation.

Lors de ce webinar, nos deux experts aborderont :

  • Le contexte et les impacts sur la gestion de vos certificats,
  • Le challenge de l’automatisation
  • Comment des prestataires comme Nameshield et Evertrust sont des alliés essentiels pour vous accompagner et anticiper l’ensemble des problématiques liées à ces annonces.

Qu’est-ce que la validation étendue (EV, ou Extended Validation) et quelle est son importance ?

Cybersécurité - Certificat SSL EV - Blog Nameshield

Les certificats SSL assurent le chiffrement et l’intégrité des données échangées entre un navigateur et un serveur web. Il existe différents niveaux de certificats, Extended Validation (EV), Organizational Validation (OV) et Domain Validation (DV), qui varient en fonction du degré d’authentification. Le certificat SSL de type Extended Validation fournit le plus haut niveau d’authentification SSL. Son obtention passe par un processus de vérification d’identité complet et normalisé à l’échelle mondiale ratifié par le forum CA/Browser Forum.

Le certificat SSL EV active la sécurité HTTPS et le cadenas, maintenant gris, dans la barre d’adresse du navigateur, tout comme les certificats DV et OV. Le coût et le temps supplémentaires consacrés à la vérification rendent plus difficile l’obtention de certificats de niveau EV pour les sites de phishing. Les internautes peuvent donc utiliser ce certificat comme marque de confiance et se sentent plus en sécurité lorsqu’ils communiquent et effectuent des achats.

Le 12 juin 2007, le CA/Browser Forum ratifie officiellement la première version des directives SSL Extended Validation qui entrent en vigueur immédiatement. L’approbation formelle clôture alors avec succès plus de deux ans d’efforts et fournit un cadre pour l’identité de site Web afin d’accroitre la confiance sur Internet.

La plupart des principaux navigateurs créent des indicateurs visuels pour les pages chargées via HTTPS et sécurisées par un certificat EV peu après la création de la norme : ils affichent l’identité validée, soit une combinaison du nom de l’organisation et de la juridiction, dans la barre URL. Safari pour iOS, Windows Phone, Firefox pour Android, Chrome pour Android et iOS, ajoutent également ces indicateurs.

En mai 2018, Google annonce son intention de repenser les interfaces utilisateur de Google Chrome afin de ne plus mettre l’accent sur les certificats EV. Chrome 77, sorti en 2019, supprime l’indication du certificat EV de l’omnibox. Firefox 70 fait de même et retire la distinction dans la barre d’URL : les certificats EV et DV sont affichés de la même manière, mais le statut du certificat EV peut toujours être consulté en cliquant sur l’icône cadenas, puis en vérifiant le nom de l’entité légale sous « certificat ».

Certificat SSL EV - Nameshield

Affichage d’un certificat EV dans Firefox

L’utilisation croissante des appareils mobiles et la suppression de l’indicateur visuel EV par les navigateurs a fait diminuer de manière significative l’intérêt de certaines entités à utiliser ce niveau de sécurité, mais l’EV a toujours une très grande importance dans notre quotidien.

Aujourd’hui les sites de phishing représentent malheureusement toujours une menace majeure pour les sites web et services en ligne légitimes. Ces « hameçonneurs » utilisent des certificats DV, généralement obtenus auprès d’un service SSL gratuit qui ne mène pas de contrôles de phishing adéquats, afin que leurs sites paraissent plus fiables. Ils trompent ainsi facilement les victimes peu méfiantes et les incitent à communiquer des informations financières ou personnelles.

Il a été remarqué une très forte hausse du phishing depuis Mars 2020, début du confinement et du télétravail pour beaucoup de personnes : le volume des sites de phishing a augmenté de 47 % pour le premier trimestre de 2020, et 82,7% des attaques de phishing ont utilisé des certificats SSL DV. Ce problème ne fait que s’accroitre et accentue la nécessité de vérifier les identités en ligne.

Source de l’image : TheDigitalArtist via Pixabay



Nouvelle fiche « 5 minutes pour comprendre : Les certificats SSL / TLS »

Fiche 5 minutes pour comprendre : les certificats SSL / TLS - Nameshield

Un certificat SSL ou TLS authentifie un serveur et chiffre les données échangées avec celui-ci. Les données sont ainsi échangées en confiance, entre deux acteurs dont l’identité est connue. Les données échangées ne peuvent être espionnées ni altérées par un tiers : confidentialité et intégrité.

Téléchargez cette fiche « 5 minutes pour comprendre : les certificats SSL / TLS » depuis notre page ressources.

HTTPS:// : La Chine n’aime pas la confidentialité et bloque l’extension ESNI

HTTPS:// : la Chine n’aime pas la confidentialité et bloque l'extension ESNI
Source de l’image : HealthWyze via Pixabay

Selon un rapport conjoint d’iYouPort, de l’Université du Maryland et du Great Firewall Report, les connexions TLS utilisant l’extension préliminaire SNI chiffrée (ESNI) sont bloquées en Chine. Un nouveau pas vers la censure et une volonté de pouvoir tracker les internautes.

Qu’est-ce que le SNI (Server Name Indication) ?

Lorsqu’un internaute consulte un site web en HTTPS://, cela signifie que le site est sécurisé par un certificat SSL/TLS. La consultation du site web commence par l’établissement de la connexion sécurisée, le « handshake ». Cette poignée de main se déroule en plusieurs étapes et vise à vérifier le certificat et établir le niveau de chiffrement de la connexion. Le premier message d’un handshake TLS est appelé « client hello ». Avec ce message, le client demande à voir le certificat TLS du serveur web. Le serveur doit joindre le certificat à sa réponse.

Présenter le bon certificat ne pose aucun problème dans le cas d’hébergements dédiés : une adresse IP, un seul certificat, contenant éventuellement plusieurs SAN (Subject Alternative Name) appartenant à la même organisation. Le problème intervient lors d’hébergements mutualisés où l’hébergeur dispose de la même adresse IP mais souhaite installer plusieurs certificats différents sous peine de devoir être le propriétaire du certificat en ajoutant des SAN pour tous ses clients. Pratique peu recommandée.

Le SNI répond à cette demande spécifique des hébergeurs et leurs hébergements mutualisés. Avec le protocole SNI, le client indique le nom de l’hôte (hostname) avec lequel il tente de démarrer une négociation TLS. Cela permet au serveur de présenter plusieurs certificats pour la même adresse IP (mais des noms d’hôte différents). Le SNI pourrait être comparé au numéro d’appartement d’une adresse postale : un immeuble comprend plusieurs appartements, et chaque appartement doit donc être identifié par un numéro différent. De même, si le serveur est indiqué par l’adresse IP, les appareils clients doivent intégrer le SNI dans leur premier message adressé au serveur pour indiquer quel site web (quel appartement) ils essaient d’atteindre.

Qu’est-ce que l’ESNI (Encrypted Server Name Indication) ?

L’établissement d’une connexion TLS chiffrée commence à la fin du handshake. Problème, le SNI n’est donc pas chiffré, car le message « client hello » est envoyé au début du handshake TLS. Un pirate peut reconstituer le parcours d’un internaute en lisant la partie SNI du handshake, même s’il n’est pas en mesure de déchiffrer les communications ultérieures. Le principal intérêt pour le pirate étant de pouvoir flouer l’internaute en créant un site de phishing. Par ailleurs, les géants du web aiment la confidentialité, et souhaitent préserver la confidentialité des données de navigation des utilisateurs. L’ESNI est donc né.

L’ESNI (Encrypted server name indication) chiffre la partie Server Name Indication (SNI) dans le handshake TLS. L’extension ESNI est accessible via la dernière version du protocole TLS, 1.3, de plus en plus largement adopté aujourd’hui. Le principe est de récupérer une clé de chiffrement via le DNS (qui lui-même peut être sécurisé via DNS via HTTPS). Encore à l’état de draft, certains gros hébergeurs l’implémentent déjà.

Et la Chine dans tout ça ?

Dans leur rapport, l’iYouPort, l’Université du Maryland et le Great Firewall Report, détaillent comment la Chine voit d’un très mauvais œil le chiffrement du handshake. Cela empêche effectivement l’outil de surveillance Great Firewall du gouvernement chinois de voir ce que font les internautes en ligne. La Chine a donc décidé de purement et simplement bloquer les connexions HTTPS établies via la dernière version du protocole TLS (la 1.3) associées à ESNI. De plus, les adresses IP impliquées dans la connexion sont bloquées temporairement pendant deux à trois minutes.

Des méthodes de contournement existent… mais jusqu’à quand ?

Les trois organisations semblent avoir trouvé des méthodes de contournement à appliquer côté client (dans les applications et les logiciels) ou côté serveur pour contourner le blocage actuel mis en place par le Great Firewall. « Malheureusement, ces stratégies spécifiques ne constituent peut-être pas une solution à long terme : à mesure que le jeu du chat et de la souris progresse, le Great Firewall continuera probablement à améliorer ses capacités de censure », écrivent les trois organisations dans leur rapport.