La data è passata; la verifica resta importante

Al 24 settembre 2026, la transizione non è più un avviso relativo a una data futura: il certificato Microsoft Corporation UEFI CA 2011 ha smesso di essere usato per le nuove firme il 26 giugno. Microsoft ha trasferito la firma delle applicazioni UEFI di terze parti alle autorità del 2023, tra cui Microsoft UEFI CA 2023; le Option ROM hanno un’autorità del 2023 separata. La data esatta è importante perché alcuni titoli precedenti facevano pensare che Secure Boot in sé avesse una data di scadenza. Non è così: scadono certificati specifici usati per firmare determinati componenti. (Guida Microsoft per le distribuzioni Linux)

Secure Boot è una funzione del firmware UEFI che verifica le firme dei programmi di avvio prima di consentirne l’esecuzione. La catena può comprendere il boot manager del sistema operativo, caricatori intermedi e driver UEFI, inclusi componenti firmware noti come Option ROM. Il database di attendibilità db contiene certificati o immagini autorizzati; il database di revoca dbx identifica gli elementi che non devono essere caricati. Lo stato di un PC dipende quindi dalle chiavi registrate nel firmware e dalle firme specifiche dei componenti che tenta di avviare, non semplicemente dall’età del computer. (Panoramica Microsoft su OEM Secure Boot)

Scadenza e revoca non sono la stessa cosa

La distinzione fondamentale è tra smettere di emettere nuove firme con un certificato e revocare la fiducia in quel certificato o in un programma firmato con esso. La scadenza del certificato del 2011 ne impedisce l’uso per firmare nuovi componenti attraverso il processo Microsoft; da sola, non rimuove la chiave dal database db del firmware né invalida automaticamente tutti i file firmati in precedenza. Microsoft afferma che uno shim Linux già firmato dall’autorità del 2011 può continuare ad avviarsi se il firmware conserva tale autorità e lo shim o il relativo livello SBAT non sono stati revocati. (Guida Microsoft per le distribuzioni Linux)

La revoca è un’azione diversa: le voci di dbx possono bloccare certificati o componenti specifici. Se un’immagine compare sia nell’elenco di attendibilità sia in quello di revoca, prevale la revoca. Un computer può quindi avviare ancora oggi un vecchio loader e, allo stesso tempo, non essere pronto a ricevere in futuro una versione corretta firmata soltanto con il 2023. Il fatto che si avvii non dimostra che la catena sia aggiornata: conferma solo che il firmware accetta il percorso di avvio usato in quella specifica occasione. (Panoramica Microsoft su OEM Secure Boot)

Cosa si può notare in Windows e su un normale desktop

Per Windows, Microsoft afferma che un dispositivo privo dei nuovi certificati può continuare ad avviarsi e a installare i normali aggiornamenti. La conseguenza principale riguarda il futuro: il PC potrebbe non ricevere o convalidare le protezioni e gli aggiornamenti futuri che interessano l’ambiente precedente all’avvio, come il boot manager e altri componenti eseguiti nelle prime fasi. Questo non equivale a dire che Windows smetterà di funzionare il giorno dopo la scadenza, né che tutti i computer abbiano bisogno subito di un aggiornamento del BIOS. La compatibilità dipende dal modello, dal firmware OEM e dalla situazione effettiva dei database delle chiavi. (Indicazioni Microsoft sull’aggiornamento dei certificati)

La pagina Microsoft per utenti e amministratori descrive scenari di rischio maggiore quando il firmware è vecchio o il processo di aggiornamento non riesce: errori di convalida, richieste di ripristino di BitLocker, blocchi all’avvio o impossibilità di avviare il sistema. Sono problemi possibili in circostanze specifiche, non l’esito inevitabile del raggiungimento di una data sul calendario. È ragionevole mantenere aggiornati Windows e firmware tramite i canali ufficiali del produttore, senza modificare autonomamente le chiavi UEFI nel tentativo di anticipare il problema. Se il computer è gestito da un’organizzazione, segui la relativa procedura e non avviare modifiche manuali. (Indicazioni Microsoft sull’aggiornamento dei certificati)

Linux e dual boot: conta la combinazione di firme e chiavi

In Linux, il componente intermedio abituale in molte distribuzioni con Secure Boot è shim: il firmware ne convalida la firma e shim verifica gli elementi successivi della catena, come GRUB e il kernel. Microsoft documenta due possibili incompatibilità: un sistema con firmware che si fida solo della CA del 2023 non accetterà uno shim firmato esclusivamente dalla CA del 2011; un sistema che si fida solo del 2011 non accetterà uno shim firmato soltanto con il 2023. In entrambi i casi non basta installare “la versione più recente”: il loader installato e i certificati considerati attendibili dal firmware devono essere compatibili. (Guida Microsoft per le distribuzioni Linux)

Nel dual boot, Windows può fungere da canale di distribuzione per alcuni aggiornamenti sui computer compatibili, ma questo non dimostra che il loader Linux o tutte le distribuzioni siano già pronte. I manutentori devono pubblicare componenti firmati dalle nuove autorità, verificare che il firmware di destinazione le riconosca e tenere conto degli elenchi di revoca e dei criteri SBAT. Red Hat, per esempio, consiglia di aggiornare sia il database di attendibilità del firmware, quando è disponibile un aggiornamento adatto, sia lo shim della distribuzione; avverte inoltre che revocare semplicemente il certificato del 2011 potrebbe impedire l’avvio dei componenti che dipendono ancora da esso. Non estendere il calendario di una distribuzione a tutte le altre. (Guida Microsoft per le distribuzioni Linux)

Come controllare lo stato senza modificare le chiavi alla cieca

Su un PC Windows domestico, controlla Windows Update e la sezione Sicurezza dispositivo > Avvio sicuro dell’app Sicurezza di Windows, se disponibile nella tua versione. Microsoft documenta notifiche e stati relativi all’aggiornamento dei certificati; sui computer gestiti, visibilità e distribuzione possono essere controllate in modo diverso. Per gli amministratori, la documentazione indica elementi come il valore del registro UEFICA2023Status e gli eventi di sistema, tra cui gli eventi 1801 e 1795. Questi dati aiutano a distinguere un aggiornamento in attesa da un errore del firmware, ma un utente non dovrebbe interpretare un singolo messaggio senza consultare le indicazioni per la propria edizione e il proprio dispositivo. (Centro messaggi Microsoft Windows)

Nelle distribuzioni Linux, strumenti come mokutil consentono di verificare se Secure Boot è attivo e di esaminare i certificati nel database del firmware; la guida Red Hat mostra anche come identificare le firme di shim. I risultati vanno interpretati con attenzione: la presenza di una CA del 2023 non garantisce da sola che tutti i componenti siano aggiornati, e la sua assenza può essere rilevante per un nuovo percorso di avvio senza significare che il computer avrà problemi ora. Su un sistema con cifratura, avvio misurato o sblocco automatico legato al TPM, modificare i database UEFI può cambiare misurazioni come PCR7 e richiedere una verifica della configurazione. Fai un inventario prima di cambiare qualsiasi cosa. (Indicazioni Red Hat sui certificati Secure Boot)

Cosa fare se il produttore non offre un aggiornamento

Per prima cosa, identifica il modello esatto della scheda madre o del desktop e consulta la relativa pagina di supporto: gli aggiornamenti dei database UEFI dipendono spesso dal produttore del firmware o dall’OEM. In Windows, installa gli aggiornamenti proposti da Windows Update e controlla lo stato indicato dal sistema; in Linux, usa il meccanismo consigliato dalla distribuzione, come fwupd quando dispositivo e aggiornamento sono compatibili. Sui computer gestiti, una prova pilota e una distribuzione graduale sono più prudenti che applicare una modifica a un’intera flotta senza convalida, soprattutto in presenza di BitLocker, dual boot o criteri personalizzati per le chiavi. Microsoft consiglia di verificare prima il firmware OEM e di provare aggiornamenti rappresentativi prima di estendere la distribuzione. (Indicazioni Microsoft sull’aggiornamento dei certificati)

Se non è disponibile un aggiornamento del firmware, non esiste una risposta universale che garantisca la compatibilità futura. Chiedi indicazioni al produttore e alla distribuzione specifica, conserva le informazioni di ripristino di BitLocker e i dati importanti, ed evita di eliminare la vecchia CA, scrivere variabili UEFI seguendo istruzioni generiche o disattivare Secure Boot come reazione automatica. Red Hat avverte che rimuovere o revocare l’autorità del 2011 può rendere inutilizzabili loader o Option ROM che ne dipendono; anche Microsoft descrive configurazioni incompatibili capaci di impedire l’avvio. La conclusione pratica è circoscritta: la scadenza da sola non spegne il desktop, ma aggiornare e verificare la catena di attendibilità aiuta a conservare la possibilità di ricevere future firme e protezioni di avvio. (Indicazioni Red Hat sui certificati Secure Boot)