macOS 27.2 e certificati eMudhra: curl, git e python3 si fidano ancora, come rimediare

Articolo aggiornato al 31 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Apple rilascia nuove correzioni.

Sui Mac aziendali Safari, Mail e le app che usano i servizi di rete di Apple hanno già smesso di fidarsi dei certificati eMudhra compromessi. Se però in azienda avete Mac usati da sviluppatori o da chi lancia script, c’è un pezzo che resta scoperto: gli strumenti da riga di comando. curl, git, python3, ruby, perl e openssl non usano il portachiavi di sistema ma un file di testo con l’elenco delle radici attendibili, /etc/ssl/cert.pem, e quel file per ora non è stato toccato.

Il contesto è lo stesso di cui ho parlato per Windows in Certificati eMudhra compromessi: aggiornare le CTL di Windows sui server non connessi: sono state compromesse le chiavi private di otto CA intermedie di eMudhra, sei per i certificati TLS e due per la firma del codice. Con quelle chiavi chi le possiede può emettere un certificato valido per qualsiasi sito, per esempio il vostro server Git, e intercettare il traffico senza che curl o git se ne accorgano. In più, in questi giorni stanno arrivando segnalazioni che l’aggiornamento a macOS 27.2 ha ripristinato il file originale, annullando le correzioni fatte a mano la settimana scorsa.

Chi è coinvolto

Secondo la nota di supporto di Apple, dal 19 ottobre macOS blocca automaticamente i 12 certificati intermedi TLS coinvolti tramite aggiornamenti di configurazione, senza bisogno di installare nulla, e dal 23 ottobre blocca anche la radice emSign ECC Root CA – G3. Questo vale per Safari, Mail e le applicazioni che si appoggiano ai framework di Apple. Restano fuori:

• gli strumenti da riga di comando di sistema che leggono /etc/ssl/cert.pem, quindi script di automazione, deploy, backup verso servizi HTTPS, client Git;
• le applicazioni che si portano dietro il proprio elenco di certificati, come pip, molti runtime Java e Node.js e diversi client di terze parti: per questi la correzione deve arrivare dal rispettivo sviluppatore.

Apple ha annunciato un futuro aggiornamento di macOS che sistemerà anche il file, senza modifiche manuali. Fino ad allora la correzione è a carico di chi amministra i Mac. Se in azienda i Mac sono solo postazioni da ufficio senza terminale e script, il rischio pratico è basso; sui Mac di sviluppatori e sistemisti io la applicherei subito.

Prima di iniziare: verificate lo stato del file

Aprite il Terminale e controllate se le due radici interessate sono presenti in /etc/ssl/cert.pem:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'

Se il comando restituisce una o due righe, il file contiene ancora quelle radici. Se non restituisce nulla, la correzione è già applicata. Controllate anche se esiste una copia di sicurezza fatta in precedenza:

ls -l /etc/ssl/cert.pem*

Attenzione: se trovate un cert.pem.orig ma il controllo sopra mostra di nuovo le radici, significa che un aggiornamento di macOS ha sostituito il file. In quel caso Apple indica di eliminare la vecchia copia (sudo rm /etc/ssl/cert.pem.orig) prima di ripetere la procedura, così la nuova copia di sicurezza corrisponde al file attuale.

La procedura indicata da Apple

I comandi sono quelli pubblicati da Apple nella nota di supporto. Richiedono la password di un amministratore.

1. Fate una copia di sicurezza del file, solo se non esiste già:

[ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig

2. Rimuovete la radice emSign ECC Root CA – G3:

t=$(mktemp) && awk -v s='=== /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"

3. Facoltativo: rimuovete anche AAA Certificate Services, la radice di Sectigo che ha firmato in modo incrociato sei dei certificati intermedi coinvolti (leggete prima l’avvertenza qui sotto):

t=$(mktemp) && awk -v s='=== /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"

4. Rilanciate il comando di verifica visto prima: se avete rimosso entrambe le radici non deve restituire nulla, se avete rimosso solo la prima deve comparire soltanto AAA Certificate Services.

I comandi sono costruiti con prudenza: il file viene sostituito solo se quello nuovo non è vuoto, e la copia originale resta in /etc/ssl/cert.pem.orig. Per tornare indietro basta sudo cp -p /etc/ssl/cert.pem.orig /etc/ssl/cert.pem.

Attenzione: AAA Certificate Services è una radice molto vecchia e ancora diffusa. Toglierla blocca i certificati incrociati compromessi, ma può far fallire la verifica anche di siti legittimi la cui catena passa da lì. Io la rimuoverei sui Mac di chi lavora con Git e script verso servizi esterni, dopo aver provato su una macchina che i servizi usati ogni giorno (repository, API, gestionali in cloud) rispondano ancora con un semplice curl -I https://example.com. Sulle postazioni dove non c’è nessuno da avvisare se qualcosa smette di funzionare, mi limiterei alla prima radice.

Su più Mac e dopo ogni aggiornamento

Se gestite i Mac con un MDM, potete distribuire gli stessi comandi come script eseguito con privilegi di root, togliendo sudo. Io aggiungerei in coda il comando di verifica, così dal registro dello script vedete subito su quali macchine le radici sono ancora presenti.

Il punto debole di questa correzione è che un aggiornamento di macOS può riscrivere /etc/ssl/cert.pem, ed è proprio quello che viene segnalato con la 27.2. Finché Apple non rilascia la correzione definitiva, rilanciate la verifica dopo ogni aggiornamento e, se le radici sono tornate, eliminate la vecchia copia .orig e ripetete i passi.

Se il problema persiste

Se dopo la modifica un’applicazione continua a fidarsi dei certificati compromessi, probabilmente non usa il file di sistema. È il caso di pip, che ha un suo elenco di radici, dei Git e curl installati con gestori di pacchetti che possono puntare a file diversi, e dei runtime Java o Node.js. Per Git potete controllare se qualcuno ha impostato un file di certificati diverso con git config --show-origin --get http.sslCAInfo. Per gli altri strumenti la strada è aggiornarli appena lo sviluppatore pubblica un elenco di radici corretto.

Ricordate infine che segnare i certificati come “Non fidarti mai” in Accesso Portachiavi non serve a nulla per questi strumenti: il portachiavi e /etc/ssl/cert.pem sono due archivi separati.

Vi è capitato di ritrovarvi le radici rimesse a posto dopo l’aggiornamento a macOS 27.2? Raccontate nei commenti come gestite il file dei certificati sui Mac aziendali: possono essere utili ad altri.