SaaSFort La configuration TLS a une propriété rassurante : une fois correcte, elle le reste. Désactivez les vieilles versions de protocole, choisissez des suites à confidentialité persistante, mettez HSTS en place, et la configuration continue de passer.
Cette propriété est fausse, et 2026 est une année où cela s’est vu. Trois choses ont changé qui transforment une configuration auparavant propre en configuration avec constats, et aucune ne concerne les versions de protocole ni les suites cryptographiques.
La base qui n’a pas changé
À énoncer d’abord, car elle représente encore l’essentiel du travail et elle est stable.
- TLS 1.2 au minimum, TLS 1.3 pris en charge et préféré.
- TLS 1.0 et 1.1 refusés, pas seulement dépriorisés.
- Uniquement des suites à confidentialité persistante.
- HSTS avec un
max-agelong,includeSubDomains, et préchargement quand l’inventaire des sous-domaines le permet. - Chaîne de certification complète, SAN corrects, agrafage OCSP.
Si l’un de ces points échoue, corrigez-le avant de lire la suite. Ce sont les éléments qui disqualifient un fournisseur dans une revue entreprise, et ils priment sur tout ce qui suit.
Changement un : la durée de vie du certificat est devenue un constat
Le scrutin SC-081v3 du CA/Browser Forum plafonne la durée de vie des certificats à 200 jours depuis le 15/03/2026, 100 jours à partir du 15/03/2027, et 47 jours à partir du 15/03/2029. La réutilisation de la validation de domaine tombe à 10 jours sur la même trajectoire.
Ce que cela change pour un audit est subtil. L’expiration était toujours vérifiée : expire-t-il bientôt. La durée de vie ne l’était pas : pour combien de temps a-t-il été émis. La seconde est désormais la question intéressante, car elle prédit si votre processus de renouvellement survit à l’étape suivante.
Un certificat émis pour 365 jours n’est pas invalide. C’est un signal que le renouvellement est manuel ou semi-manuel, et qu’en mars 2027 le processus casse.
Une nuance importante pour quiconque construit ou achète un scanner : le plafond doit être évalué contre la date d’émission du certificat, pas contre celle du jour. Un certificat de 398 jours émis en 2025 respectait la règle en vigueur au moment de sa frappe. Un vérificateur qui compare chaque certificat au plafond du jour produit un faux constat sur chaque certificat hérité légitimement émis, et un outil qui crie au loup finit ignoré.
Le calendrier complet et quoi faire.
Changement deux : l’accord de clés est devenu une question
Chrome, Firefox et Edge négocient le groupe hybride X25519MLKEM768 par défaut depuis leur version 131. Le support côté serveur tournait autour de dix pour cent en 2026.
Ce n’est pas encore une condition d’échec, et tout outil honnête le rapporte en information et non en défaut. Ne pas proposer d’accord de clés post-quantique en 2026 n’est pas une erreur de configuration.
C’est une exposition à effet différé. Le trafic enregistré aujourd’hui, protégé par un accord de clés classique sur courbes elliptiques, devient lisible rétroactivement une fois les attaques quantiques praticables. Que cela vous concerne dépend de la durée pendant laquelle vos données restent sensibles, ce qui explique pourquoi la question apparaît désormais dans les questionnaires d’acheteurs régulés et rarement ailleurs.
Le correctif tient en une ligne de configuration et le repli est automatique, donc le rapport coût-bénéfice est inhabituel pour un changement cryptographique.
Changement trois : TLS a cessé de signifier seulement HTTPS
Le troisième changement ne concerne pas du tout votre serveur web.
Un audit TLS qui couvre le port 443 et s’arrête là manque entièrement le chemin du courrier. SMTP négocie le chiffrement par une annonce STARTTLS non authentifiée qu’un attaquant en coupure peut retirer, et aucun de SPF, DKIM ou DMARC ne le détecte, car tous trois authentifient le message plutôt que la connexion.
MTA-STS est le contrôle, TLS-RPT la télémétrie, et l’adoption reste sous un pour cent du million de domaines les plus visités. Pour la plupart des organisations, c’est le plus grand trou de sécurité du transport non traité, et c’est aussi le moins coûteux à fermer.
Le déploiement, et le piège du mode test.
La checklist d’audit 2026
Transport (HTTPS)
[ ] TLS 1.3 pris en charge, TLS 1.2 minimum
[ ] TLS 1.0 / 1.1 refusés
[ ] Uniquement des suites à confidentialité persistante
[ ] HSTS : max-age long, includeSubDomains, preload
[ ] Chaîne complète, SAN corrects, agrafage OCSP
Certificats
[ ] Durée de vie émise dans le plafond en vigueur à l'émission
[ ] Durée de vie <= 100 jours, ou renouvellement automatisé avant le 15/03/2027
[ ] Émission via ACME, renouvellement découplé de la durée de vie
Accord de clés
[ ] X25519MLKEM768 proposé, X25519 conservé en repli
[ ] Activé en périphérie ET à l'origine, si un CDN est devant
Transport du courrier
[ ] MTA-STS publié en mode enforce
[ ] TLS-RPT publié et rapports réellement lus
[ ] DANE, si la zone est signée DNSSEC
La ligne CDN mérite qu’on s’y arrête. Les éditeurs activent régulièrement un TLS moderne en périphérie pendant que la connexion périphérie-origine reste sur une configuration plus ancienne. Un scan externe voit la périphérie. Votre schéma d’architecture voit les deux, et l’auditeur posera la question sur le second.
Où cela se mappe
Tout ce qui précède relève de NIS2 article 21(2)(h), ISO/IEC 27001:2022 A.8.24 et DORA article 9, les éléments réseau relevant aussi de NIS2 21(2)(e) et ISO A.8.20. Ce que les auditeurs acceptent comme preuve pour cette clause.
En résumé
Les versions de protocole et les suites cryptographiques étaient tout le travail en 2024. En 2026, elles sont le ticket d’entrée.
Les trois nouveaux points sont la durée de vie des certificats, l’accord de clés hybride et le chemin du courrier. C’est sur le troisième que presque tout le monde a un vrai trou.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.