Certificats eMudhra : auditer la confiance TLS des outils Mac

Créé le 24 octobre 2026 · Publication Apple analysée : 23 octobre 2026 · Source consultée le 24 octobre 2026

Après l’alerte eMudhra, nous recommandons aux DSI de vérifier la confiance TLS de leurs automatisations Mac. Le guide ci-dessous propose une méthode de qualification : identifier les outils, tester les flux métier et conserver une preuve de validation avant toute généralisation.

1. Ce qu’Apple confirme

Apple bloque automatiquement les certificats compromis depuis le 19 octobre. Certains outils Mac, dont curl et git, peuvent encore les accepter via /etc/ssl/cert.pem en attendant une mise à jour. Les logiciels utilisant leur propre liste de racines nécessitent une vérification auprès de leur éditeur.

2. Construire un inventaire des flux, pas seulement des postes

Nous recommandons une fiche par automatisation : propriétaire, Mac concernés, exécutable réellement lancé, source d’installation, version, configuration TLS et destinations. Incluez les scripts de support, les téléchargements de paquets et les tâches de développement. Relevez aussi le contexte d’exécution : une tâche lancée par le MDM doit être qualifiée dans ce contexte.

Définir une preuve de fonctionnement

Pour chaque flux, consignez le résultat attendu : téléchargement vérifié, accès au dépôt ou récupération d’un artefact de test. Utilisez des destinations maîtrisées et des comptes de recette. Évitez de conclure à la sécurité d’un script à partir du seul succès d’une navigation dans Safari.

3. Encadrer une éventuelle mesure temporaire

Apple propose une modification facultative du fichier de confiance ; elle peut affecter des sites légitimes et être remplacée par une mise à jour macOS. Consultez la procédure officielle avant toute intervention.

Organiser un pilote avec critères d’arrêt

Notre recommandation : faire approuver la décision par le responsable sécurité, conserver l’état initial et tester un petit groupe représentatif. Vérifiez ensuite les flux inventoriés, les accès métier et le résultat après redémarrage. En cas de rupture, suspendez la généralisation et faites arbitrer la remédiation. Ne contournez pas le problème en désactivant la validation TLS.

4. Ce que cela change pour une entreprise belge ou française

Pour une PME, commencez par les scripts du prestataire et les postes de développement. Pour une ETI, une grande entreprise ou une administration, nous recommandons un responsable par chaîne d’automatisation et une validation par population. Testez les accès propres aux sites belges et français : un pilote doit représenter leurs usages, leurs proxies et leurs dépôts.

Conservez une fiche de changement commune aux équipes : périmètre, décision, résultats, exceptions et prochaine revue. Cette trace sert au support et au suivi interne ; elle ne constitue pas, à elle seule, une preuve de conformité réglementaire.

5. Analyse Underside : suivre la confiance au niveau du workflow

Notre lecture est que l’inventaire du parc doit être relié à celui des automatismes qui font fonctionner le poste. Nous recommandons d’utiliser Jamf ou le MDM pour cibler le pilote et collecter les résultats, puis de faire valider le service par son propriétaire. Un statut de commande réussie ne suffit pas à démontrer le fonctionnement du processus métier.

Prolongez cette démarche avec notre analyse des exigences TLS et MDM et notre dossier Jamf et gestion Apple.

Source : Apple — About the compromised eMudhra intermediate CAs.