Lacunes dans la révocation des certificats macOS pour les outils en ligne de commande

Le 19 octobre 2026, Apple a automatiquement bloqué douze certificats compromis, suivis du blocage du treizième, l’emSign ECC Root CA - G3, le 23 octobre. Alors que Safari et la plupart des applications natives ont immédiatement mis à jour leurs paramètres de confiance, les outils en ligne de commande reposant sur des magasins de certificats statiques sont restés vulnérables. Cette divergence a créé une réalité scindée où la même machine pouvait rejeter un certificat dans un navigateur tout en l’acceptant dans une session de terminal.

Ce qui s’est passé

Le problème fondamental provient de la manière dont différents composants logiciels sur macOS vérifient les certificats numériques. Les frameworks de sécurité d’Apple, qui alimentent Safari, Mail et de nombreuses autres applications, utilisent un système dynamique qui consulte la liste de blocage d’Apple et effectue des vérifications de révocation en ligne. Cependant, certains outils fournis avec macOS et les Xcode Command Line Tools n’utilisent pas ce système dynamique. Au lieu de cela, ils lisent un fichier plat statique situé à /etc/ssl/cert.pem. Au moment où Apple a publié son avis, ce fichier n’avait pas été actualisé pour refléter les nouveaux blocages. Apple a confirmé dans l’article d’assistance 149555 que ces outils ne consultent pas la liste de blocage ni ne vérifient si un certificat a été révoqué.

Cette fragmentation a entraîné des rapports contradictoires de la part des opérateurs et des développeurs. Certains ont noté que leurs commandes intégrées curl et git continuaient de se connecter à des serveurs utilisant les certificats bloqués, tandis que d’autres affirmaient que ces outils respectaient les paramètres de confiance du système. La confusion provient probablement des différences entre les versions de macOS, de l’utilisation d’outils installés via Homebrew par rapport aux binaires système, ou de malentendus concernant quel magasin de certificats référence un binaire spécifique. Par exemple, Homebrew maintient son propre bundle de certificats à /opt/homebrew/opt/ca-certificates, qui est mis à jour indépendamment des mises à jour du système d’exploitation d’Apple. De même, les environnements d’exécution comme Python regroupent souvent leurs propres autorités de certification via des packages tels que certifi, créant ainsi une autre surface de confiance isolée.

Détails clés

• Apple a bloqué douze certificats le 19 octobre 2026 et l’emSign ECC Root CA - G3 le 23 octobre 2026.
• Les outils lisant /etc/ssl/cert.pem ne consultent pas la liste de blocage d’Apple ni n’effectuent de vérifications de révocation.
• La remédiation manuelle implique la suppression des certificats racines du fichier plat, mais les mises à jour logicielles de macOS peuvent écraser ce fichier.
• Il existe au moins quatre vérificateurs distincts sur un seul Mac : les frameworks Apple, LibreSSL système, les bundles Homebrew et les bundles des environnements d’exécution.
• Apple conseille aux administrateurs de revérifier le fichier de certificats après chaque mise à jour du système d’exploitation, car les correctifs peuvent annuler les modifications manuelles.
• Les rapports contradictoires concernant le comportement de curl suggèrent des variations dans les sources des outils ou les versions de macOS parmi les utilisateurs.

Contexte

La révocation de certificat n’est pas une propriété inhérente au certificat lui-même, mais une décision prise par le vérificateur qui le contrôle. Lorsqu’une autorité de certification compromet ses clés ou émet des certificats incorrectement, elle les révoque. Cependant, pour qu’un client respecte cette révocation, il doit consulter une liste actuelle des certificats révoqués ou vérifier en ligne en temps réel. Dans l’écosystème macOS, ce processus est fragmenté. Le système de trousseau d’Apple est conçu pour être à jour et automatique, mais les outils hérités et les gestionnaires de paquets tiers dépendent souvent d’instantanés statiques des racines approuvées. Ces instantanés deviennent obsolètes jusqu’à ce qu’ils soient explicitement mis à jour, créant des fenêtres de vulnérabilité où les certificats révoqués sont encore acceptés comme valides.

Pourquoi c’est important

Pour les équipes gérant des infrastructures auto-hébergées ou développant des logiciels sur macOS, cette fragmentation pose un risque de sécurité significatif. Si vos scripts de déploiement, vos pipelines CI/CD ou vos outils de surveillance dépendent d’utilitaires en ligne de commande comme curl ou git, ils peuvent continuer à faire confiance à des certificats compromis même après qu’Apple les ait bloqués. Cela signifie que vos systèmes automatisés pourraient communiquer avec des acteurs malveillants ou des points de terminaison non sécurisés sans déclencher d’alertes. Le silence de ces outils est dangereux car ils signalent des connexions réussies, masquant l’échec de confiance sous-jacent.

De plus, la correction recommandée — modifier manuellement le fichier de certificats — est fragile. Étant donné que les mises à jour macOS peuvent restaurer la version originale non corrigée de /etc/ssl/cert.pem, une machine sécurisée hier pourrait redevenir vulnérable aujourd’hui après une mise à jour système de routine. Sans vérification continue, les administrateurs ne peuvent pas être sûrs de l’état de confiance de leurs machines. Cette incertitude complique la réponse aux incidents et l’audit de conformité, car deux machines apparemment identiques peuvent avoir des postures de sécurité complètement différentes concernant la validation des certificats.

Ce que vous pouvez faire

• Identifiez quel magasin de certificats utilisent vos outils critiques en exécutant des tests de connexion détaillés et en vérifiant les sorties CAfile ou CApath.
• Comparez les résultats de security verify-cert avec ceux de vos outils en ligne de commande pour détecter les divergences dans les décisions de confiance.
• Si vous corrigez manuellement /etc/ssl/cert.pem, notez le hash du fichier et la date, et revérifiez-le après chaque mise à jour logicielle de macOS.
• Envisagez de pointer les outils vers un bundle de certificats unique et contrôlé en utilisant des variables d’environnement telles que CURL_CA_BUNDLE ou SSL_CERT_FILE.
• Surveillez la validité et l’expiration des certificats de vos services exposés à l’extérieur pour garantir la sécurité de votre propre infrastructure.
• Auditez les bundles de certificats spécifiques aux langages, tels que certifi de Python, et mettez-les à jour indépendamment du système d’exploitation.