La compromissione delle chiavi della CA eMudhra: cosa devono controllare e correggere adesso le aziende

Sabato 17 ottobre 2026 un ricercatore di sicurezza ha segnalato che otto autorità di certificazione intermedie gestite da eMudhra, un'autorità di certificazione indiana, avevano chiavi private che chiunque poteva ricavare dai certificati pubblici. Ognuna di quelle chiavi era un numero inferiore a 256. Una era il numero 4. Sei delle otto potevano emettere certificati TLS considerati attendibili da Apple, Google, Microsoft e Mozilla; le altre due potevano firmare software per Windows.

Chrome ha bloccato le sei chiavi TLS un'ora e quaranta minuti dopo la segnalazione, e Firefox la sera stessa. Per chi naviga sul web, il pericolo era finito già sabato sera.

Non lo era per tutto il resto. Server, container, applicazioni Java, script Python, integrazioni di pagamento e dispositivi connessi confrontano i certificati con la propria copia dell'elenco delle autorità attendibili, e la maggior parte di queste copie cambia solo quando qualcuno installa un aggiornamento. Fino ad allora, un certificato per qualsiasi dominio firmato con una di queste chiavi passa per autentico, e le chiavi sono pubbliche dal 20 ottobre.

Nella stessa settimana GoDaddy ha iniziato a revocare 404.607 certificati perché le informazioni di policy che contenevano non corrispondevano ai documenti pubblicati da GoDaddy stessa. I suoi clienti hanno dovuto scaricare e installare da soli i certificati sostitutivi.

Questa guida è per chi deve rispondere alla domanda «siamo coinvolti?»: responsabili IT e operations, CTO e fondatori la cui attività si regge su un sito web, un'API o un prodotto connesso. Spiega cosa è successo, sulla base dei resoconti dell'incidente pubblicati da Mozilla, Google, eMudhra, GoDaddy e dai vendor di software; cosa controllare oggi; cosa aggiornare questa settimana; e cosa predisporre perché il prossimo incidente di questo tipo sia ordinaria amministrazione. Tutto ciò che segue è aggiornato al 22 ottobre 2026, e l'incidente è ancora aperto.

Cosa è successo

eMudhra ha creato le otto CA intermedie durante una cerimonia di generazione delle chiavi il 30 aprile 2025. La sua ricostruzione, pubblicata il 19 ottobre nel bug di Mozilla dedicato all'incidente: il test di una fase di wrapping e unwrapping delle chiavi, approvato come deroga alla procedura abituale, conteneva un difetto che ha creato nel modulo di sicurezza hardware (HSM) un secondo insieme di chiavi, deboli, accanto a quelle previste. Le etichette erano simili, le chiavi deboli sono state usate per errore per creare le richieste di certificato, e la root di eMudhra le ha firmate. Le stesse richieste sono andate a Sectigo, che il 14 maggio 2025 le ha firmate tutte e otto in cross-signing dalla sua root AAA Certificate Services. eMudhra dice di «non aver ancora confermato l'esatta causa all'origine».

Mozilla ha descritto il risultato: «Le chiavi private P384 sono interi scelti a caso tra 1 e l'ordine del gruppo. Le 8 chiavi coinvolte usavano tutte interi minori di 256.» Mozilla ha ricevuto la segnalazione alle 20:06 UTC e ha ricostruito le chiavi da sé alle 21:48, «senza sapere nulla del metodo usato dal segnalatore originale». Il ricercatore dice di averle trovate con paranoid_crypto, la libreria open source di Google, «così com'è, senza modifiche». Le chiavi deboli facevano parte di catene pubblicamente attendibili da quasi 18 mesi.

Gli otto certificati:

Ogni chiave compare in due certificati. Uno è stato emesso da emSign Root TLS CA - G3 o da emSign Root CS CA - G3 di eMudhra, che a loro volta risalgono a emSign ECC Root CA - G3; l'altro è il certificato incrociato (cross-certificate) di Sectigo emesso da AAA Certificate Services. Il secondo percorso conta, perché alcuni trust store che non hanno mai contenuto una root di eMudhra si fidano ancora di quella vecchia root di Sectigo.

Qualcuno è stato attaccato?

Nessuno ha segnalato abusi, e per i browser c'è un buon motivo per pensare che non ce ne siano stati. Chrome, come gli altri client che applicano la Certificate Transparency (CT), accetta un certificato solo se è stato registrato nei log pubblici di CT. Google: prima del suo blocco nei log non risultava alcun certificato TLS con catena verso queste sei CA intermedie, quindi «nessun certificato fraudolento emesso da queste CA avrebbe potuto essere usato contro client che applicano la CT».

Fuori dal browser il quadro è diverso. La pagina di Mozilla sull'incidente: «molti client al di fuori dell'ecosistema dei browser non applicano la Certificate Transparency. Non sappiamo se degli attaccanti abbiano sfruttato la generazione difettosa delle chiavi per colpire questi client.» Quella finestra si è aperta nella primavera del 2025 e per ciascun client si chiude solo quando viene aggiornato. eMudhra dice di non essere a conoscenza di alcuna prova che le chiavi siano state ricavate prima della divulgazione, e Cloudflare dice che la sua verifica non ha trovato alcuno sfruttamento attivo sui suoi servizi.

Ora che le chiavi sono pubbliche, falsificare un certificato non richiede alcuna competenza. La pagina di Mozilla sull'incidente elenca server di test che presentano certificati emessi con le chiavi compromesse, così che chiunque possa verificare i propri client (i comandi sono più sotto).

Che cosa permette un certificato falsificato: chi riesce a intercettare il traffico tra il vostro software e un servizio che questo chiama (su una rete condivisa, tramite un router compromesso o una risposta DNS avvelenata) può spacciarsi per quel servizio, leggere ciò che il vostro software invia, chiavi API e dati personali compresi, e modificare ciò che riceve. Un software firmato con una delle due chiavi di firma del codice avrebbe superato il controllo della firma di Windows finché il blocco di Microsoft non avesse raggiunto la macchina.

Chi è coinvolto

Ci sono tre problemi distinti, e una stessa azienda può averli tutti.

1. Software che si fida ancora delle chiavi compromesse

Questo riguarda quasi ogni azienda: qualsiasi programma che effettua chiamate HTTPS e il cui trust store contiene ancora emSign ECC Root CA - G3 o AAA Certificate Services, senza aver ricevuto un blocco per le otto chiavi. I punti tipici:

• Server Linux e immagini container costruite prima del 20 o del 21 ottobre. Una Debian 12 senza patch, per esempio, si fida di entrambe le catene.
• I runtime dei linguaggi che portano con sé un proprio elenco: Node.js, certifi di Python, il cacerts di Java, il bundle di Composer per PHP, webpki-roots di Rust.
• Gli strumenti da riga di comando di macOS. La pagina di Mozilla sull'incidente dice che le versioni integrate di curl, git, python3, perl, ruby e openssl verificano i certificati con /etc/ssl/cert.pem senza controllarne la revoca, e che Apple non ha aggiornato quel file.
• Le macchine Windows che non ricevono gli aggiornamenti automatici di Microsoft al suo elenco dei certificati non consentiti, di solito perché i Criteri di gruppo (Group Policy) li disattivano o perché la rete è offline.
• Appliance, dispositivi e software di terze parti che includono un proprio file di CA, come load balancer, gateway VPN, SDK e controller embedded.

Ogni runtime va verificato a sé. In un test che abbiamo eseguito il 22 ottobre, una macchina Debian 12 senza patch con Node.js 24.18 ha accettato la catena che termina nella root di eMudhra e rifiutato quella che termina nella root di Sectigo, mentre Python sulla stessa macchina le ha accettate entrambe.

2. Aziende con certificati propri sotto la root rimossa

Mozilla e le distribuzioni Linux hanno rimosso emSign ECC Root CA - G3, e Chrome seguirà il 27 ottobre. I certificati validi sotto quella root smettono di funzionare in ciascun client man mano che questo si aggiorna. L'indicazione di Google: i gestori di siti web con certificati di questo tipo «devono procurarsi e installare immediatamente un nuovo certificato TLS da un'altra gerarchia PKI inclusa nel Chrome Root Store».

Il 21 ottobre Chrome contava in CT circa 30.800 certificati non scaduti sotto quella root. Di questi, 30.791 provenivano da due CA intermedie di InCommon, il servizio di certificati che Internet2 gestisce per le università e gli istituti di ricerca statunitensi e che emette certificati ECC tramite CERTInext, la piattaforma di eMudhra. Altri 18 provenivano dalle CA intermedie della stessa eMudhra. eMudhra dice che circa 30.000 certificati vanno migrati, circa il 97% dei quali emessi tramite ACME, e che sta emettendo i sostitutivi da un'altra gerarchia.

Se il vostro sito è dietro Cloudflare in modalità Full (strict) e il server di origine presenta un certificato sotto questa root, Cloudflare dice che la rimozione della fiducia «causerebbe malfunzionamenti» e chiede ai clienti: «Verificate i certificati di origine personalizzati e le configurazioni dei server».

I certificati RSA dell'altra root di eMudhra, emSign Root CA - G1, per ora non sono coinvolti. Mozilla dice di non rimuovere quella root «in questo momento»; Chrome sta «valutando attentamente se mantenere l'inclusione dei restanti certificati CA di eMudhra». Se dipendete da certificati eMudhra o CERTInext di qualsiasi tipo, predisponete fin d'ora una seconda autorità di certificazione.

3. Clienti GoDaddy

Il caso di GoDaddy non ha niente a che vedere con eMudhra, ma è arrivato nella stessa settimana e ha colpito molti più siti. Il 15 ottobre GoDaddy ha segnalato a Mozilla che i certificati delle sue gerarchie GoDaddy e Starfield contenevano informazioni di policy (OID di policy e link alla CPS) che non corrispondevano ai profili della sua CP/CPS, il documento in cui un'autorità di certificazione dichiara che cosa emette. Non è una falla di sicurezza nei certificati. Secondo i Baseline Requirements, le regole che ogni autorità di certificazione pubblica rispetta, è comunque un motivo per revocarli entro cinque giorni.

Erano coinvolti 404.607 certificati, di cui 396.055 a validazione di dominio. GoDaddy ne ha revocati 170.566 entro la scadenza del 18 ottobre alle 23:45 UTC, e 227.422 entro la mattina seguente; il suo avviso ai clienti dice che i restanti sono stati revocati il 21 ottobre. GoDaddy riemette i certificati, ma installarli spetta al cliente: «i visitatori del vostro sito potrebbero vedere avvisi di sicurezza, e il sito potrebbe diventare inaccessibile finché non viene installato un nuovo certificato.»

Cosa controllare oggi

1. Cosa inviano i vostri server? Per ogni hostname pubblico, elencate gli emittenti della catena che presenta:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Una riga che nomina eMudhra, emSign, una delle autorità EM ... G3B o G3C, oppure InCommon Intermediate CA - DVG3C, OVG3C o EVG3C significa che il certificato va sostituito prima del 27 ottobre. AAA Certificate Services da solo è normale, perché molte catene di Sectigo del tutto ordinarie lo includono ancora. Per i servizi di posta e di directory aggiungete -starttls smtp (oppure imap, ldap) e la porta corretta. Includete gli host interni, i load balancer e i server di origine dietro una CDN.

2. Cosa è stato emesso per i vostri domini? La CT elenca ogni certificato che un'autorità di certificazione pubblica ha emesso per i vostri nomi, compresi quelli che nessuno in azienda ricorda di aver ordinato:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

L'output mostra anche quali autorità di certificazione la vostra azienda usa davvero, ed è il punto di partenza dell'inventario descritto più avanti.

3. I vostri client si fidano delle chiavi compromesse? I server di test di Mozilla presentano certificati emessi con le chiavi compromesse, quindi un errore di certificato è il risultato buono. Provate entrambe le famiglie: il primo host ha la catena verso la root di eMudhra, il secondo verso quella di Sectigo, e un trust store può superare una prova e non l'altra.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl risponde solo per curl. Eseguite la stessa richiesta attraverso lo stack TLS di ciascuna applicazione, nell'ambiente in cui l'applicazione gira:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Le due righe Python non sono ridondanti: urllib usa il trust store del sistema operativo, requests usa certifi. Ripetete ogni riga con l'host dv-g3b-aaa-emudhra. Per Java, effettuate una qualsiasi chiamata HTTPS ai server di test dalla JVM in questione, e controllate se il suo trust store contiene una delle due root (Java 9 o successivo; su Java 8 usate -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Una root presente in un trust store non dimostra da sola l'esposizione, perché Go, Node.js, Deno e rustls-webpki di Rust ora bloccano le otto chiavi qualunque cosa dica il trust store. A decidere sono i server di test.

4. Parchi macchine Windows. Microsoft non ha pubblicato nulla sull'incidente, ma l'elenco dei certificati non consentiti che Windows scarica automaticamente blocca tutte e otto le chiavi dal 20 ottobre. Fanno eccezione le macchine su cui i Criteri di gruppo disattivano l'aggiornamento automatico dei certificati root e le reti senza accesso a Windows Update; lì l'elenco va distribuito in un altro modo. certutil -verifyCTL Disallowed mostra la copia che una macchina ha in cache. La pagina di Mozilla sull'incidente offre uno script per singole macchine e dice che «non è consigliato per i dispositivi gestiti a livello aziendale».

5. Certificati GoDaddy. Controllate quale certificato presenta davvero ogni server:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Se l'emittente è GoDaddy o Starfield, confrontate il numero di serie con i certificati nel vostro account GoDaddy. Dove GoDaddy mostra «Install your new certificate» (installa il nuovo certificato), sul server c'è ancora quello revocato.

Una regola vale sempre: non fate sparire un errore disattivando la verifica dei certificati. Le parole di Cloudflare: «È importante non risolvere questi errori disattivando la verifica.» Un client che non verifica si fida di ogni certificato falsificato, non solo di questi.

Cosa aggiornare questa settimana

Le correzioni sono di due tipi. Rimuovere le due root chiude ogni percorso per un client che usa quel trust store, ma manda in errore anche i certificati validi emessi sotto di esse. Bloccare le otto chiavi tramite l'hash della loro chiave pubblica, come fanno Go, Node.js, Deno, Electron, rustls-webpki, Composer e Windows, chiude la falla senza mandare in errore nient'altro. Dove la vostra piattaforma offre la seconda strada, preferitela.

«Ancora nessun» e «non ancora» significano che al 22 ottobre non era stato pubblicato nulla. Ricontrollate prima di basarci la vostra pianificazione.

Quattro cose colgono di sorpresa i team:

• Le immagini container conservano il vecchio elenco. Un'immagine costruita prima del 20 o del 21 ottobre si fida delle chiavi finché non viene ricostruita su un'immagine di base aggiornata, e rifare il pull dello stesso tag serve solo dopo che l'immagine di base è stata ricostruita. Ricostruite, rifate il deploy e chiedete ai vendor delle immagini che usate.
• I processi tengono ciò che hanno caricato. Un programma legge il suo trust store all'avvio, quindi dopo l'aggiornamento riavviate i servizi di lunga durata. Node.js aggiunge che le sessioni TLS riprese da prima dell'aggiornamento non vengono ricontrollate.
• Le applicazioni portano con sé i propri file di CA. SDK e applicazioni includono spesso un proprio cacert.pem o ca-bundle.crt. Cercateli nei repository e nelle immagini, per esempio con find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, e aspettatevi di trovarne più di uno: pip, ad esempio, ha una propria copia di certifi.
• I dispositivi aspettano il loro vendor. Chiedete per iscritto a ciascun vendor quale trust store usa il prodotto e quando esce l'aggiornamento. Fino ad allora il dispositivo si fida di certificati falsificati per ogni servizio che chiama, quindi limitate ciò che può raggiungere.

Se rimuovete AAA Certificate Services a mano, come fanno Debian, Ubuntu ESM, Fedora e il workaround di Red Hat, provate poi le connessioni verso i servizi con certificati Sectigo: alcuni server più vecchi inviano ancora una catena che termina in quella root.

Cosa predisporre prima del prossimo incidente

Che un'autorità di certificazione lasci chiavi così deboli è raro. Le revoche di massa no. Ecco le più grandi del 2026 registrate nel bug tracker di Mozilla:

Nessuno di questi cinque casi era un problema di sicurezza. In ciascuno un certificato contraddiceva il documento dell'autorità stessa, e i Baseline Requirements (sezione 4.9.1.1) impongono comunque la revoca entro cinque giorni. Quando una chiave è compromessa, o non si può fare affidamento sulla validazione del dominio, la scadenza è di 24 ore. Nessuno può prorogarla per voi. Nella revoca di 83.267 certificati da parte di DigiCert nel 2024, il Chrome Root Program ha scritto di «non avere l'autorità per concedere eccezioni»; un cliente ha ottenuto un'ordinanza del tribunale per fermare la revoca dei propri certificati, e l'ordinanza è stata annullata quattro giorni dopo.

Il modo in cui sono andate le sostituzioni dice molto. A luglio HARICA ha usato ACME Renewal Information (ARI) per dire ai client ACME dei suoi clienti di rinnovare in anticipo, e ha riemesso direttamente altri certificati; nella più grande delle sue due revoche, alla scadenza era già stato sostituito l'87% dei nomi coinvolti. GoDaddy, i cui clienti scaricano e installano da soli ogni certificato sostitutivo, alla sua scadenza aveva revocato il 42% dei certificati coinvolti.

Il ciclo di rinnovo si sta comunque accorciando:

• Con il ballot SC-081 del CA/Browser Forum, dal 15 marzo 2026 i certificati TLS pubblici hanno una durata massima di 200 giorni. Il limite scende a 100 giorni il 15 marzo 2027 e a 47 giorni il 15 marzo 2029, quando la validazione del dominio potrà essere riutilizzata solo per 10 giorni.
• Let's Encrypt passa per impostazione predefinita a certificati di 64 giorni il 10 febbraio 2027, e a 45 giorni un anno dopo.
• I certificati TLS pubblici stanno perdendo l'autenticazione client. Let's Encrypt ha smesso di includerla l'8 luglio 2026, e il Chrome Root Program richiede che i certificati emessi dal 15 marzo 2027 servano solo all'autenticazione server. Se usate certificati pubblici come certificati client per il mutual TLS, cosa comune nelle integrazioni API B2B, quelle connessioni hanno bisogno di un'autorità di certificazione privata.

A 100 giorni, e poi a 47, installare i certificati a mano smette di essere un'opzione realistica. Un'azienda che automatizza in vista di questo calendario è pronta anche per la prossima revoca di massa. Che cosa serve:

1. Sapere cosa si ha, in entrambe le direzioni. Un elenco di tutti i certificati che i vostri server presentano, con hostname, emittente, scadenza, metodo di rinnovo e responsabile. Un secondo elenco di tutti i trust store su cui si basa il vostro software: il pacchetto del sistema operativo, ogni bundle dei linguaggi, ogni file di CA dentro un'applicazione o un dispositivo. La ricerca in CT vista sopra avvia il primo elenco; una distinta base del software (SBOM) o un inventario delle dipendenze avvia il secondo.
2. Automatizzare emissione e installazione. ACME ovunque possa girare, con ARI (RFC 9773), così che un'autorità di certificazione possa dire ai vostri client di rinnovare in anticipo. Dove un dispositivo non può eseguire ACME, usate l'automazione del vendor, oppure terminate il TLS davanti al dispositivo su qualcosa che possa farlo.
3. Tenere pronta una seconda autorità di certificazione. Un account ACME funzionante presso una seconda autorità, testato, e record CAA nel DNS che le autorizzino entrambe. Quando a un'autorità viene tolta la fiducia o quando revoca in massa, cambiare diventa una modifica di configurazione.
4. Monitorare la CT per i vostri domini. Ricevete un avviso per ogni nuovo certificato emesso per i vostri nomi. Così venite a sapere di un'emissione inattesa il giorno stesso in cui avviene.
5. Trattare i trust store come dipendenze. Aggiornateli con le normali patch, e ricostruite le immagini a cadenza regolare, non solo quando cambia il codice.
6. Scrivere il runbook in funzione dei due orologi. 24 ore e cinque giorni: chi decide, chi ha accesso a ciascun sistema, quali sistemi richiedono passaggi manuali, come raggiungere ciascun vendor. Provatelo una volta all'anno sostituendo il certificato su un servizio che può permettersi un errore. Dal 2025 le autorità di certificazione pubbliche devono avere e testare un proprio piano per le revoche di massa; ai loro clienti serve l'altra metà.

Se realizzate prodotti che altri mettono in esercizio

Se il vostro prodotto contiene un trust store (un dispositivo, un'applicazione installata, un SDK), i vostri clienti sono protetti solo quando il vostro aggiornamento li raggiunge. Rilasciatelo, e dite ai clienti quali versioni contengono la correzione. Il consiglio di Mozilla a chi gestisce un trust store: bloccare le otto CA intermedie se il software lo consente, altrimenti «valutare se sia opportuno rimuovere la fiducia nelle root che hanno firmato queste CA intermedie».

Il Cyber Resilience Act entra in gioco qui in due modi. Il suo obbligo di segnalazione, in vigore dall'11 settembre 2026, riguarda le vulnerabilità attivamente sfruttate, e in questo caso non è stato segnalato alcuno sfruttamento. I suoi requisiti essenziali, che si applicano dall'11 dicembre 2027, prevedono tra l'altro che le vulnerabilità si possano risolvere tramite aggiornamenti di sicurezza; un prodotto il cui elenco delle autorità attendibili non può essere aggiornato non li soddisferebbe. I clienti che rientrano nella NIS2 chiederanno ai loro fornitori con quanta rapidità hanno gestito questo caso, ed è utile avere la risposta per iscritto.

Le questioni ancora aperte

• La root rimanente di eMudhra. Il 21 ottobre Chrome ha posto dodici domande a eMudhra e non ha annunciato alcuna decisione su emSign Root CA - G1. Mozilla non la rimuove «in questo momento».
• Il percorso di migrazione di eMudhra. eMudhra ha detto a Mozilla che sposterà i clienti sulla sua gerarchia G1 (RSA); la sua pagina di stato parla di «una gerarchia di CA alternativa, gestita in modo indipendente e pubblicamente attendibile». Chrome ha chiesto quale.
• Microsoft e Apple. Nessuna delle due ha pubblicato una dichiarazione né tolto dal proprio trust store l'una o l'altra root.
• Correzioni in sospeso. Al 22 ottobre Red Hat, Amazon Linux, Temurin e Corretto non avevano rilasciato nulla; la correzione di Bun era stata integrata ma non rilasciata.
• La causa all'origine. eMudhra non l'ha confermata, e ha detto che verificherà di nuovo ogni cerimonia delle chiavi che ha svolto.
• Sectigo. In un caso separato, aperto dal 5 settembre, Sectigo ha rifiutato di revocare certificati il cui extended key usage non corrispondeva a una frase della sua CPS, sostenendo che la frase era ambigua. Il 18 ottobre ne contava ancora attivi circa 72 milioni. Alcuni partecipanti alla discussione pubblica hanno chiesto di togliere la fiducia a Sectigo; nessun root program ha annunciato una decisione. Le aziende con certificati Sectigo dovrebbero seguire il caso.

Dove trovare aiuto

Un problema di certificati raramente si presenta come tale. Si manifesta come un checkout che non si carica più, un'integrazione che smette di sincronizzarsi o un dispositivo che smette di inviare dati, di solito nel fine settimana. Aiutiamo le aziende ad attraversare settimane come questa senza disservizi, e a organizzarsi perché la prossima sia ordinaria amministrazione:

• Una verifica dell'esposizione. Individuiamo dove i vostri sistemi aprono o accettano connessioni TLS, quale trust store usa ciascuno e quali certificati presentate, compresi container, servizi Java, integrazioni con banche, fornitori di pagamento e di logistica, e dispositivi.
• Le correzioni. Aggiornamenti, immagini ricostruite, chiavi bloccate o certificati sostituiti, applicati seguendo il vostro processo di gestione delle modifiche e verificati con i server di test di Mozilla.
• Automazione per il 2027. ACME con ARI su server, load balancer e appliance, una seconda autorità di certificazione, record CAA, monitoraggio della CT e un runbook, pronti per i certificati a 100 giorni dal 15 marzo 2027.
• I sistemi che nessuno vuole toccare. Vecchie applicazioni Java, appliance e client embedded con i propri trust store sono ciò di cui si occupa il nostro servizio di manutenzione dei sistemi legacy.

Se non siete sicuri di essere coinvolti, scrivete a office@c9group.dev indicando i domini e le piattaforme che gestite, oppure prenotate una chiamata. Vi diremo che cosa controllare per primo.