Apple bloque les certificats eMudhra compromis et guide les administrateurs sur la remédiation via CLI

Apple a lancé une réponse de sécurité visant à bloquer les certificats émis par des autorités de certification (CA) intermédiaires compromises d'eMudhra. À partir du 19 octobre 2026, l'entreprise a commencé à bloquer automatiquement ces identifiants sur ses appareils tout en fournissant des étapes spécifiques de remédiation manuelle pour les administrateurs système qui dépendent des interfaces en ligne de commande.

Ce qui s'est passé

L'incident de sécurité découle de la compromission des clés privées appartenant à huit autorités de certification intermédiaires opérées par eMudhra. Bien que deux de ces autorités émettent des certificats de signature de code auxquels les frameworks Apple ne font pas confiance, les six autres émettent des certificats Transport Layer Security (TLS). Cette distinction est cruciale car un attaquant possédant ces clés compromises pourrait générer des certificats TLS apparemment valides pour n'importe quel site web, permettant potentiellement des attaques de type homme du milieu ou l'usurpation d'identité de services légitimes.

En réponse, eMudhra et Sectigo ont révoqué les certificats affectés. L'étendue du problème concerne douze certificats spécifiques associés aux six CA intermédiaires émettrices de TLS. Chacune de ces six autorités détient deux certificats : l'un émis par emSign Root TLS CA - G3, qui s'enchaîne vers emSign ECC Root CA - G3, et l'autre contresigné par Sectigo, qui s'enchaîne vers AAA Certificate Services. Apple a identifié ces douze certificats comme les principaux vecteurs d'abus potentiels et a pris des mesures pour les neutraliser dans son écosystème.

Détails clés

• Apple a commencé à bloquer les douze certificats compromis sur tous les appareils Apple le 19 octobre 2026.
• Le blocage s'applique automatiquement à Safari, Mail et aux applications utilisant les frameworks natifs de réseau et de sécurité d'Apple.
• Le 23 octobre 2026, Apple a étendu le blocage pour inclure le certificat racine emSign ECC Root CA - G3.
• Les outils en ligne de commande tels que curl, git, python3, ruby, perl et openssl peuvent encore accepter ces certificats s'ils se basent sur le fichier local /etc/ssl/cert.pem.
• Apple fournira une future mise à jour logicielle pour corriger la vulnérabilité des outils en ligne de commande, mais aucune mise à jour immédiate du système d'exploitation n'est requise pour les utilisateurs généraux.
• Les administrateurs peuvent supprimer manuellement les certificats racines compromis de /etc/ssl/cert.pem pour protéger les flux de travail CLI avant l'arrivée du correctif officiel.

Contexte

Pour comprendre l'impact, il est utile de distinguer la manière dont différentes applications vérifient l'identité sur macOS. La plupart des applications grand public, y compris les navigateurs web comme Safari, utilisent les frameworks de sécurité centralisés d'Apple. Ces frameworks reçoivent des listes de blocage mises à jour via OTA (over-the-air), permettant à Apple de révoquer la confiance accordée aux certificats compromis instantanément sans nécessiter une mise à jour complète du système d'exploitation. Ce mécanisme protège automatiquement la grande majorité des utilisateurs.

Cependant, de nombreux outils de développement et d'administration système fonctionnent différemment. Des utilitaires comme curl et git contournent souvent le magasin de confiance central d'Apple et vérifient plutôt contre un fichier local nommé /etc/ssl/cert.pem. Ce fichier contient un ensemble de certificats racines de confiance stockés directement sur le disque. Parce que ces outils n'interrogent pas la liste de blocage en direct d'Apple, ils restent vulnérables aux certificats compromis d'eMudhra jusqu'à ce que le fichier local soit soit modifié manuellement par un administrateur, soit remplacé par une future mise à jour logicielle d'Apple.

Pourquoi c'est important

Pour les équipes qui gèrent leur propre infrastructure ou développent des logiciels sur macOS, cette lacune dans la protection automatique présente un risque tangible. Si vos scripts de déploiement, pipelines CI/CD ou agents de surveillance utilisent des outils en ligne de commande pour se connecter à des services externes, ils pourraient faire confiance involontairement à un serveur malveillant présentant un certificat forgé. Cela pourrait entraîner une exfiltration de données ou l'injection de code malveillant lors de mises à jour automatisées, car les outils percevraient la connexion comme sécurisée.

De plus, le processus de remédiation manuelle nécessite une exécution prudente. La modification des magasins de certificats au niveau système est une opération sensible. La suppression du mauvais certificat racine pourrait rompre la connectivité avec des services légitimes qui passent par les mêmes racines. Les administrateurs doivent équilibrer l'urgence de combler la faille de sécurité avec le besoin de maintenir la stabilité opérationnelle. Le fait qu'Apple prévoit de corriger cela dans une future mise à jour signifie que toute modification manuelle effectuée maintenant pourrait devoir être annulée ou gérée avec soin pour éviter des conflits lorsque le correctif officiel arrivera.

Ce que vous pouvez faire

• Vérifiez si votre flux de travail utilise des outils basés sur Terminal comme curl, git ou python3 qui dépendent de /etc/ssl/cert.pem pour la validation des certificats.
• Sauvegardez le fichier de certificats actuel en exécutant [ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig dans le Terminal.
• Supprimez le certificat emSign ECC Root CA - G3 du magasin de confiance local en utilisant la commande awk spécifique fournie par Apple pour garantir que le fichier reste valide.
• Optionnellement, supprimez la racine AAA Certificate Services si vous devez bloquer immédiatement les certificats contresignés par Sectigo, en comprenant que cela peut affecter d'autres services.
• Validez vos modifications en exécutant la commande de vérification openssl pour confirmer que les racines compromises ne sont plus présentes dans le fichier.
• Surveillez la prochaine mise à jour logicielle macOS qui corrigera officiellement /etc/ssl/cert.pem, et restaurez la sauvegarde originale si la mise à jour remplace vos modifications manuelles.