La durée de vie des certificats TLS baisse depuis des années, et le mouvement s’accélère. Depuis le 15 mars 2026, un certificat public ne peut plus dépasser 200 jours. En 2029, ce sera 47 jours.
J’ai récemment rencontré l’effet de bord le moins attendu de ces règles : un outil de développement qui change de bibliothèque TLS et une registry MCP interne qui devient brusquement « injoignable » sur macOS. Rien n’avait changé côté serveur.
Dans cet article, je vous propose de voir le calendrier officiel et ce qu’il implique pour la validation des domaines (et donc pour votre DNS). Je vous expliquerai ensuite pourquoi Copilot CLI a cassé une registry MCP interne, comment vérifier vos certificats, et ce qui pourrait encore bouger côté Windows et Linux.
📅 1. Le calendrier du CA/Browser Forum
📌 Le CA/Browser Forum réunit les autorités de certification (CA) et les éditeurs de navigateurs et de systèmes. Il publie les Baseline Requirements, les règles que doivent respecter tous les certificats TLS publics.
En avril 2025, le ballot SC-081v3, proposé par Apple, a été adopté sans aucun vote contre. Côté éditeurs, Apple, Google, Microsoft et Mozilla ont tous voté pour. Le ballot réduit la durée maximale des certificats en trois étapes (section 6.3.2 des Baseline Requirements) :
| Certificat émis à partir du | Émis avant le | Durée maximale |
|---|---|---|
| 15 mars 2026 | 398 jours | |
| 15 mars 2026 | 15 mars 2027 | 200 jours |
| 15 mars 2027 | 15 mars 2029 | 100 jours |
| 15 mars 2029 | 47 jours |
À noter : le texte compte un jour comme 86 400 secondes, et toute fraction de seconde en plus compte comme un jour entier. Les Baseline Requirements recommandent donc de ne pas émettre pour la durée maximale (397, 199, 99 ou 46 jours au lieu de 398, 200, 100 ou 47).
🌐 L’enjeu DNS : la validation des domaines
Le ballot réduit aussi la durée pendant laquelle une CA peut réutiliser une preuve de contrôle du domaine (DCV, Domain Control Validation) :
| À partir du | Réutilisation maximale de la validation du domaine |
|---|---|
| Avant le 15 mars 2026 | 398 jours |
| 15 mars 2026 | 200 jours |
| 15 mars 2027 | 100 jours |
| 15 mars 2029 | 10 jours |
Avec 10 jours de réutilisation et des certificats de 47 jours, la preuve de contrôle du domaine devra être refaite à presque chaque renouvellement. Si vous validez vos domaines avec un enregistrement DNS (le challenge DNS-01 du protocole ACME, obligatoire pour les certificats wildcard), votre DNS doit pouvoir être modifié automatiquement, par API. Un enregistrement TXT ajouté à la main une fois par an ne tiendra plus.
Let’s Encrypt anticipe : ses certificats durent 90 jours par défaut, des certificats de 6 jours sont déjà disponibles en option, et la durée maximale passera à 45 jours en février 2028 (plan officiel).
🍏 2. Apple n’attend pas : la règle des 825 jours
Ces règles visent les certificats publics. Une PKI interne n’est pas soumise au CA/Browser Forum, mais macOS lui impose quand même ses propres limites.
Depuis macOS 10.15 et iOS 13, le système lui-même refuse les certificats serveur TLS qui ne respectent pas les exigences d’Apple : clés RSA d’au moins 2048 bits, signature SHA-2, nom DNS dans le SAN (Subject Alternative Name), serverAuth dans l’EKU (Extended Key Usage) et une validité de 825 jours maximum pour les certificats émis après le 1er juillet 2019. Pour un certificat rattaché à une racine préinstallée par Apple, la limite est de 398 jours depuis le 1er septembre 2020.
La règle des 825 jours s’applique aussi aux certificats émis par une PKI d’entreprise. Apple ne l’écrit pas noir sur blanc, mais c’est ce que j’ai constaté sur macOS 26. Un certificat interne valable 3 ans fonctionne dans Chrome, avec curl ou avec Node, et échoue dans Safari et dans toutes les apps qui utilisent le vérificateur du Mac.
🤖 3. Quand Copilot CLI change de bibliothèque TLS
C’est exactement ce que j’ai vécu avec GitHub Copilot CLI.
Le contexte : une organisation qui impose une registry MCP (Model Context Protocol) interne, avec la politique « Registry only ». Copilot CLI interroge cette registry pour vérifier que chaque serveur MCP configuré est autorisé.
Avec la version 1.0.78, tous les serveurs MCP personnalisés ont été bloqués d’un coup sur macOS :
! 3 MCP servers were blocked by policy: '<server-a>', '<server-b>', '<server-c>'Les logs de debug montrent la vraie cause :
[ERROR] failed to verify TLS certificate: invalid peer certificate: Other(OtherError("“*.<domain>” certificate is not standards compliant: -67901"))
log.target=rustls_platform_verifier::verification::apple
[ERROR] MCP server "<server-id>" filtered: Registry https://<registry>/ was unreachableLe code -67901 correspond à errSecCertificateValidityPeriodTooLong dans Security.framework. Le message parle de certificat « not standards compliant », mais le problème est uniquement sa durée : 1095 jours, émis en janvier 2026 pour 3 ans.
Ce qui a changé, c’est le client. Avant la 1.0.78, la vérification de la registry passait par Node, qui vérifie les certificats avec OpenSSL et n’impose aucune durée maximale. Depuis, elle passe par le runtime Rust de Copilot CLI (reqwest + rustls-platform-verifier), qui délègue la vérification au système. Sur macOS, c’est donc Apple qui décide, avec sa règle des 825 jours. Comme la registry semble injoignable, Copilot CLI bloque par précaution tous les serveurs MCP qu’elle n’a pas pu vérifier.
Le diagnostic est piégeux, parce que tous les tests habituels passent :
| Client | Vérificateur | Résultat |
|---|---|---|
| Copilot CLI < 1.0.78 | OpenSSL (Node) | ✅ |
| Copilot CLI ≥ 1.0.78 sur macOS | Security.framework | ❌ -67901 |
| Safari | Security.framework | ❌ |
Chrome, curl, Node | Leur propre vérificateur ou OpenSSL | ✅ |
Et mes collègues sous Windows ? Ils ne sont pas concernés : sur Windows, rustls-platform-verifier passe par CryptoAPI, qui n’impose pas de durée maximale.
J’ai documenté le problème dans l’issue #4364. Il n’est pas isolé : l’issue #5085 montre qu’à partir de la 1.0.93, davantage de requêtes passent par le runtime natif, avec une autre régression TLS sur macOS quand Copilot CLI tourne dans une sandbox.
🔍 4. Vérifiez vos certificats, surtout internes
Pour savoir si un certificat passera sur macOS, curl ne suffit pas : il faut interroger Security.framework. J’ai donc créé un petit outil open source : jlandure/macos-tls-cert-check.
Il contient deux scripts qui affichent un verdict PASS ou FAIL, sans rien installer :
check-tls.shsur macOS, qui vérifie le certificat avec le vérificateur d’Apple ;check-tls.ps1sur Windows, qui vérifie avec le vérificateur de Windows et prédit le résultat macOS à partir des règles d’Apple.
Sur macOS, une seule commande suffit :
git clone https://github.com/jlandure/macos-tls-cert-check.git
cd macos-tls-cert-check
./scripts/check-tls.sh github.comLe script affiche aussi où se situe le certificat par rapport aux limites de durée :
Target: github.com:443
Certificate: CN=github.com
Issuer: C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36
Validity: 2026-09-01 -> 2026-11-29 (89 days, 38 days left)
Lifetime limits (informative):
Apple, private root CA 825 days OK
Apple, Apple-trusted root CA 398 days OK
CA/B Forum, public CA at issue date 200 days OK
CA/B Forum, public CA from 2029-03-15 47 days OVER
macOS verifier (Security.framework): PASSPour notre registry interne, le verdict est clair :
Validity: 2026-01-22 -> 2029-01-21 (1095 days, 822 days left)
macOS verifier (Security.framework): FAIL
FAILED (-67901): “*.<domain>” certificate is not standards compliant
-67901 errSecCertificateValidityPeriodTooLong: lifetime above 825 days (398 for an Apple-trusted root).Depuis un poste Windows, la commande équivalente est :
powershell -ExecutionPolicy Bypass -File .\scripts\check-tls.ps1 -HostName internal.example.comLes scripts renvoient 0 pour PASS, 1 pour FAIL et 2 si la connexion échoue. On peut donc les brancher en CI ou dans une sonde de supervision.
💪 ProTip : badssl.com héberge des certificats volontairement défectueux (expiré, mauvais hôte, racine inconnue…). C’est pratique pour voir comment un outil réagit avant de le pointer vers votre infrastructure.
Côté PKI interne, quelques réflexes :
- faire l’inventaire des certificats serveur internes et de leur durée ;
- émettre pour 825 jours maximum si des Mac doivent s’y connecter, et viser plutôt 398 jours ou moins ;
- automatiser le renouvellement (ACME interne, cert-manager sur Kubernetes…) avant que les durées ne baissent encore ;
- tester avec le vérificateur de chaque système, pas seulement avec
curl.
🪟 5. Et Windows, Linux, les autres bibliothèques ?
En octobre 2026, Apple est la seule plateforme qui impose une durée maximale dans le système lui-même. Les autres s’appuient sur leurs programmes de certificats racines, qui obligent les CA publiques à suivre les Baseline Requirements :
- Microsoft Trusted Root Program pour Windows : je n’ai trouvé aucune documentation d’un contrôle de durée côté client ;
- Mozilla Root Store Policy pour la plupart des distributions Linux, dont le magasin de certificats commun repose sur la liste de Mozilla (doc Red Hat) ;
- Chrome, qui refuse lui-même les certificats publics de plus de 398 jours depuis Chrome 85, mais exempte les autorités configurées localement.
Personne n’a annoncé de date pour un contrôle des 200, 100 ou 47 jours côté client. Le précédent existe pourtant : en 2020, Apple dans ses systèmes et Chrome dans son navigateur ont appliqué eux-mêmes la limite de 398 jours.
L’histoire de Copilot CLI montre un second risque, plus discret. Vos certificats peuvent devenir invalides sans qu’aucune règle ne change, simplement parce qu’un outil change de bibliothèque TLS. De plus en plus d’outils passent d’OpenSSL au vérificateur du système, par exemple avec rustls-platform-verifier en Rust. Le jour où vos outils, ou Windows et Linux, se mettront à appliquer ces limites, mieux vaut que vos certificats internes soient déjà en règle et renouvelés automatiquement.
🎯 Conclusion
Les durées des certificats publics sont fixées jusqu’en 2029 : 200 jours depuis mars 2026, 100 jours en mars 2027, 47 jours en mars 2029, avec une validation de domaine à refaire tous les 10 jours. Sans renouvellement automatique, ça ne tiendra pas, et un DNS pilotable par API devient indispensable pour les certificats wildcard.
Pour les certificats internes, la limite immédiate est celle d’Apple : 825 jours. Si vous ne devez faire qu’une chose cette semaine, lancez check-tls.sh sur vos services internes depuis un Mac.
👉 Et vous, combien de temps durent les certificats de votre PKI interne ?
📚 Pour aller plus loin
CA/Browser Forum :
- Baseline Requirements, section 6.3.2 : durée maximale des certificats publics
- Ballot SC-081v3 : le calendrier 2026-2029 et le vote
Apple :
- Exigences pour les certificats approuvés dans iOS 13 et macOS 10.15 : la règle des 825 jours
- Limites à venir des certificats approuvés : la règle des 398 jours
- Apple Root Program Policy
Microsoft, Mozilla et Linux :
- Exigences du Microsoft Trusted Root Program
- Mozilla Root Store Policy
- Mozilla : passage des certificats TLS à 398 jours (2020)
- Red Hat : certificats système partagés
Chrome et Let’s Encrypt :
Le cas Copilot CLI :
- Issue #4364 : registry MCP rejetée sur macOS (
-67901) - Issue #5085 : régression TLS dans les sandbox macOS depuis la 1.0.93
- Le diagnostic complet dans le dépôt de l’outil
🎓 Aller plus loin avec GitHub Copilot
Vous utilisez déjà GitHub Copilot au quotidien et voulez passer aux usages avancés ? En une journée, la formation Coder avec GitHub Copilot - Avancé de TechTown couvre :
- les workflows complexes et l’automatisation avec GitHub Copilot ;
- l’intégration dans les pipelines CI/CD ;
- l’optimisation du code legacy, des performances et de la sécurité.