Un certificato TLS che il browser sembra accettare può ancora creare problemi a webhook, backup remoti, API e processi lanciati da terminale. Il controllo utile, quindi, non consiste nel guardare il lucchetto verde: bisogna verificare quale catena presenta davvero il server e se il client riesce a validarla senza ignorare gli errori.

Il problema non è il lucchetto verde

Il caso eMudhra ha reso concreto un rischio spesso trattato come teoria. Nell’ottobre 2026 sono state compromesse le chiavi private di otto autorità di certificazione intermedie; sei potevano emettere certificati TLS. Apple ha bloccato automaticamente i certificati coinvolti nei propri framework, mentre Mozilla ha distribuito il blocco tramite OneCRL. eMudhra ha precisato che gli intermedi compromessi non avevano emesso certificati pubblici finali e che non risultavano compromessi dati o infrastruttura. Le due informazioni vanno lette insieme: l’incidente è serio, ma non autorizza a dichiarare infetto ogni sito.

Per una PMI la lezione è operativa. Browser, sistema operativo, container e tool da riga di comando possono usare trust store e meccanismi di revoca differenti. Un sito può aprirsi nel browser dell’amministratore e fallire nel gestionale che invia un webhook. Dopo un cambio di hosting, CDN o certificato, serve quindi un test ripetibile sullo stesso dominio usato dalle integrazioni, non una verifica visiva fatta da un solo computer.

Controlla la catena con OpenSSL

Sostituisci example.com con il dominio reale, senza protocollo né percorso, ed esegui il comando da una macchina simile a quella che effettua le chiamate automatiche. L’opzione -servername invia il nome corretto tramite SNI; -verify_hostname controlla che il certificato sia valido per quel dominio; -verify_return_error interrompe il test quando la validazione fallisce. È un dettaglio importante: la documentazione OpenSSL spiega che s_client, usato senza questa opzione, può continuare anche dopo un errore.

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error \
  -showcerts </dev/null

Cerca Verify return code: 0 (ok), poi controlla soggetto, issuer e date del certificato. Non confondere però -showcerts con una certificazione della catena: mostra i certificati inviati dal server, nell’ordine ricevuto, ma OpenSSL specifica che quell’elenco non è di per sé una catena verificata. Se manca un intermedio o compare un errore di hostname, correggi la configurazione sul server, sulla CDN o sul pannello hosting prima di toccare WordPress.

Trasforma il test in una routine

Esegui il controllo dopo ogni rinnovo, migrazione, cambio CDN o intervento sul reverse proxy. Ripetilo anche dall’ambiente che esegue cron, webhook e deploy: testare soltanto dal portatile non riproduce il trust store di un container, di una funzione cloud o di un server rimasto indietro con gli aggiornamenti. Registra almeno dominio, data del test, issuer, scadenza ed esito della verifica. In questo modo un’anomalia non resta una sensazione, ma diventa un confronto con l’ultimo stato funzionante.

Se il test fallisce, separa subito i livelli. Prima aggiorna sistema operativo, runtime e immagini container; poi verifica la catena servita dall’hosting; infine controlla eventuali URL http:// rimasti nel database WordPress. Per quest’ultimo caso, wp search-replace supporta --dry-run, utile per vedere cosa cambierebbe senza scrivere nel database. Una copia recente e un test preliminare restano obbligatori. Lo stesso approccio a gate è utile anche per la gestione delle patch PHP critiche e per revocare gli accessi WordPress dei fornitori.

L’errore da evitare e il take finale

L’errore più pericoloso è reagire a un incidente globale modificando alla cieca il trust store del server o del Mac. Rimuovere una root può interrompere altri servizi perfettamente legittimi; Apple stessa avverte che l’intervento sul file /etc/ssl/cert.pem riguarda amministratori e tool specifici, non tutti gli utenti. Prima identifica il client che fallisce, verifica l’issuer presentato e applica l’advisory del vendor a quella piattaforma. Se non amministri il sistema, apri un ticket all’hosting con l’output del test, evitando di incollare credenziali o token.

Il take finale è semplice: il certificato non è una spunta annuale, ma una dipendenza delle automazioni aziendali. Un controllo OpenSSL dopo ogni modifica importante costa pochi minuti e distingue tre problemi diversi — catena incompleta, hostname errato, trust store obsoleto — prima che diventino ordini persi o integrazioni ferme. Le fonti tecniche per approfondire sono l’avviso Apple sulle CA eMudhra, il resoconto del Mozilla Security Team, la nota aggiornata di eMudhra e la documentazione ufficiale di OpenSSL.