Apple’s git fait encore confiance aux certificats eMudhra compromis

Il y a une règle implicite dans le monde du développement : on fait confiance à sa chaîne de certificats. C’est le socle invisible sur lequel reposent les clones git, les téléchargements de dépendances, les appels API sécurisés. Quand cette chaîne est saine, tout roule. Quand elle ne l’est plus, les ennuis commencent silencieusement.

Le problème eMudhra n’est pas nouveau. Cette autorité de certification indienne a vu ses certificats signalés comme compromis — et la grande majorité des systèmes a réagi en les révoquant ou en les retirant de leur trust store. La plupart… sauf le git fourni par Apple sur macOS.

Oui. Si tu es développeur sur Mac et que tu utilises le git livré avec Xcode Command Line Tools, tu fais peut-être encore confiance à des certificats qu’il vaudrait mieux avoir révoqués depuis longtemps. Voici pourquoi, et surtout, quoi faire.

eMudhra : une autorité de certification dans le viseur

eMudhra est une autorité de certification basée en Inde, accréditée par le gouvernement indien pour émettre des certificats numériques. Sur le papier, rien d’inhabituel : il existe des centaines de CA dans le monde, et la plupart sont méconnues du grand public tout en faisant partie des trust stores par défaut des OS et navigateurs.

Le problème est apparu quand des chercheurs ont documenté des émissions non conformes — des certificats délivrés sans respecter les Baseline Requirements du CA/Browser Forum, l’organisme qui fixe les règles du jeu pour les CA reconnues par les navigateurs et systèmes d’exploitation. Ce n’est pas une entorse technique mineure : ces règles existent précisément pour éviter que des certificats frauduleux ne circulent librement. Parmi les violations constatées : des certificats émis pour des domaines que le demandeur ne contrôlait pas réellement, et des certificats mal encodés ne respectant pas les standards ASN.1.

La réaction habituelle face à ce type d’incident suit une cascade bien rodée : Mozilla, Google, Microsoft et Apple retirent ou distrustent la CA dans leurs trust stores respectifs. C’est ce qui s’est passé — en partie. Les navigateurs ont été mis à jour. Les systèmes d’exploitation ont suivi. Mais le git bundlé avec les outils Apple, lui, a sa propre horloge.

Pourquoi git a son propre bundle de certificats

C’est là que beaucoup de développeurs sont surpris. On suppose souvent que git utilise les certificats du système — le trousseau macOS dans le cas d’Apple. Et pour certaines opérations, c’est vrai. Mais git s’appuie sur libcurl pour ses connexions HTTPS, et libcurl peut être compilé avec son propre bundle de CA racines : un fichier ca-bundle.crt statique, figé au moment de la compilation du binaire.

Apple shippe une version de git compilée avec ce type de bundle statique. Résultat : même si macOS a révoqué eMudhra dans le Keychain système, le git Apple peut encore la considérer comme valide. C’est un problème classique de « bundled vs system trust ». On le retrouve aussi avec OpenSSL sur Linux, Python dans certaines configurations, ou encore Node.js selon la manière dont il a été compilé. La logique est compréhensible — avoir un comportement TLS prédictible quel que soit l’OS hôte. Mais ça suppose que le bundle soit activement maintenu à jour.

Et là, visiblement, ça n’a pas suivi. La révocation d’eMudhra dans le Keychain macOS date de plusieurs mois. Le bundle embarqué dans le git Apple, lui, n’a pas bougé.

Le risque concret pour les développeurs Mac

Concrètement, qu’est-ce que ça change pour toi ? Dans la majorité des cas quotidiens — cloner un repo GitHub, pousser sur GitLab — tu ne risques rien directement. Ces plateformes utilisent des certificats émis par des CA réputées (DigiCert, Let’s Encrypt), pas eMudhra. Mais plusieurs scénarios méritent qu’on s’arrête.

• Un serveur git interne dont le certificat TLS est signé par eMudhra — certaines entreprises dans des régions où cette CA était bien implantée l’utilisent encore
• Une attaque Man-in-the-Middle exploitant la confiance résiduelle en eMudhra pour présenter un faux certificat à ton client git
• Des pipelines CI/CD tournant sur Mac qui font des appels HTTPS vers des services tiers avec des certificats eMudhra en jeu

Le MitM est le scénario qui inquiète le plus les chercheurs en sécurité. Une CA compromise peut théoriquement émettre un certificat techniquement valide pour n’importe quel domaine — github.com, registry.npmjs.org, ton hébergeur privé. Si ton git lui fait confiance, il acceptera le faux certificat sans déclencher la moindre alerte.

Une CA compromise peut émettre un certificat valide pour n’importe quel domaine. Si ton outil lui fait confiance, il ne verra rien d’anormal — et toi non plus.

Diagnostiquer et corriger ta configuration git

La bonne nouvelle : c’est diagnosable et corrigeable en quelques minutes. Commence par identifier quel git est actif sur ton poste :

# Identifier la version de git active
which git
# → /usr/bin/git = git Apple (bundle CA potentiellement obsolète)
# → /opt/homebrew/bin/git = git Homebrew (OK)

# Voir si un bundle CA custom est configuré (vide = bundle compilé dans le binaire)
git config --global http.sslCAInfo

Si ton git pointe vers /usr/bin/git, la correction la plus propre est de passer par Homebrew. La version Homebrew s’appuie sur la formule ca-certificates, qui suit bien plus régulièrement les révocations du CA/Browser Forum — et se met à jour indépendamment du cycle de release d’Apple :

# Installer git et le bundle CA à jour via Homebrew
brew install git ca-certificates

# S'assurer que Homebrew est en tête du PATH (dans ~/.zshrc ou ~/.bash_profile)
export PATH="/opt/homebrew/bin:$PATH"

# Vérifier dans un nouveau terminal
which git
# → /opt/homebrew/bin/git

Si tu veux une solution temporaire sans changer ton git par défaut, tu peux pointer explicitement vers le bundle système macOS — qui, lui, a bien été mis à jour : git config --global http.sslCAInfo /etc/ssl/cert.pem. Ce fichier reflète le trust store macOS et exclut désormais eMudhra. Ça couvre le cas d’usage sans attendre un patch officiel d’Apple.

Ce que ça dit de la sécurité de notre outillage dev

Cette histoire eMudhra illustre un problème structurel souvent ignoré : les développeurs font confiance à leurs outils de façon implicite. On audite les dépendances npm ou Composer, on lit les CVE, on met en place des politiques de mise à jour — mais qui vérifie le bundle de CA embarqué dans son client git ? Qui sait combien de certificats racines se trouvent dans les outils installés sur son poste depuis des années ?

La surface d’attaque supply chain ne se limite pas au code que tu écris. Elle inclut tout l’outillage autour : le gestionnaire de paquets, le client git, le runtime, les outils de build. Si l’un d’eux fait confiance à une CA compromise, la porte est entrouverte — silencieusement. C’est d’autant plus critique sur des projets sensibles, comme une application sur mesure qui manipule des données métier ou financières.

La question de la maintenance des environnements — pas seulement en production, mais aussi sur les postes de développeurs — est régulièrement reléguée au second plan. On patch les serveurs, on renouvelle les certificats TLS, mais les trust stores des outils de dev restent souvent dans leur état d’origine pendant des années. C’est un angle mort que les équipes sérieuses gagneraient à inclure dans leurs audits de sécurité.

Apple devrait faire mieux — et on devrait tous s’y intéresser

Apple a les ressources et les équipes pour corriger ça rapidement. La question est de savoir si ce vecteur est jugé suffisamment critique pour un patch dédié, ou s’il attendra tranquillement la prochaine mise à jour des Command Line Tools. Plusieurs mois après la révélation publique, la réponse semble penchée vers la deuxième option — ce qui est décevant pour une entreprise qui communique autant sur la sécurité de son écosystème.

Mon avis : les CA compromises ne font jamais la une. Elles n’ont pas l’aspect dramatique d’un zero-day RCE ou d’une fuite de base de données. Pourtant, elles minent silencieusement la confiance cryptographique sur laquelle repose tout le reste. Un bundle de CA obsolète dans un outil utilisé des dizaines de fois par jour, c’est exactement le genre d’angle mort qui intéresse les attaquants patients et méthodiques.

Installe git via Homebrew. Audite les bundles CA de tes autres outils. Et la prochaine fois qu’un éditeur te dit que son logiciel est « sécurisé par défaut », demande-lui depuis quand il n’a pas mis à jour ses certificats racines. La réponse risque de t’étonner.