Il 19 ottobre scade il certificato che firma l’avvio di Windows: sui server nessuno lo sostituirà al posto vostro

Lunedì 19 ottobre scade il certificato Microsoft Windows Production PCA 2011. Il nome dice poco, il ruolo molto: è l’autorità che firma il boot loader di Windows, il codice che Secure Boot verifica prima di lasciar partire il sistema operativo. È l’ultima di tre scadenze annunciate da tempo: le altre due, il KEK e la UEFI CA del 2011, sono passate a fine giugno.

Sui PC la sostituzione arriva con gli aggiornamenti mensili. Sui server no: Microsoft lo ha scritto a febbraio, nel playbook dedicato a Windows Server, dove serve un intervento manuale. Chi non l’ha ancora fatto ha una settimana, e un problema che nessun monitoraggio segnalerà da solo.

Cosa scade, e cosa succede il giorno dopo

I certificati di Secure Boot vivono nel firmware, in due database: il KEK, che autorizza le modifiche, e il DB, che elenca le firme ammesse all’avvio. I tre certificati del 2011 vengono sostituiti da quattro del 2023: la nuova catena separa anche la firma dei boot loader di terze parti da quella delle option ROM.

Il 20 ottobre nessun server smetterà di avviarsi. Secondo Microsoft, i sistemi rimasti ai certificati 2011 continuano a partire e a installare gli aggiornamenti ordinari. Perdono però la possibilità di ricevere le nuove protezioni della fase di avvio: aggiornamenti del Boot Manager, revoche nel database delle firme non più fidate, mitigazioni per le vulnerabilità che verranno scoperte a quel livello. Microsoft segnala anche possibili effetti su BitLocker e sui boot loader di terze parti.

Il 20 ottobre non si fermerà niente, ed è proprio questo il problema: un server che smette di ricevere le protezioni dell’avvio non lo segnala a nessuno.

Il livello di avvio è quello dei bootkit, il malware che si carica prima del sistema operativo, e quindi prima di antivirus ed EDR. Restare sui certificati vecchi significa congelare le difese proprio lì.

Perché sui server tocca a voi

Per Windows Server il playbook descrive un percorso a carico dell’amministratore, in cinque fasi: inventario, verifica dello stato di Secure Boot, aggiornamento del firmware del produttore, pilota, gestione dei problemi. Fanno eccezione i sistemi Windows Server 2025 su piattaforme certificate, che hanno già i certificati 2023 nel firmware.

L’ordine conta. Il firmware viene prima dei certificati: su alcuni server l’aggiornamento non va a buon fine finché non è installato un UEFI più recente, e Microsoft invita a valutare la sostituzione di quelli che non riescono ad aggiornarsi. Per la distribuzione (registro, Group Policy, Intune o Configuration Manager) la raccomandazione è usare un solo metodo per macchina, procedere a ondate e verificare l’esito dagli eventi di sistema, mettendo in conto riavvii e circa 48 ore per dispositivo.

Le macchine virtuali, il caso più insidioso

In un data center virtualizzato la maggior parte dei “server” sono VM, con il firmware emulato dall’hypervisor (su Hyper-V, solo le VM di seconda generazione hanno Secure Boot). Le VM nuove possono nascere con i certificati aggiornati; per quelle in esercizio da anni l’aggiornamento passa da Windows, se il firmware virtuale lo consente.

Su VMware non sempre lo consente. Broadcom documenta che le VM create su versioni di ESXi precedenti alla 9.0 hanno una Platform Key con firma nulla, che blocca l’aggiornamento del KEK e, a cascata, quello del DB. Il sintomo: Windows segnala certificati disponibili ma non applicati, vCenter un allarme sulla Platform Key. La correzione automatica è parziale: dipende dalla versione di ESXi, dalla presenza del vTPM e dal sistema operativo ospite. Per le VM con vTPM su ESXi 8, a inizio settembre Broadcom la indicava ancora come rilascio futuro.

Prima di toccare il firmware

Dalle indicazioni di Microsoft e dei produttori si ricava una lista breve:

• Inventario reale: server fisici, VM di seconda generazione, versioni di firmware e di hypervisor. Il rischio sta nelle macchine dimenticate.
• Chiavi di ripristino BitLocker a portata di mano: tra gli scenari documentati dai produttori di server c’è la richiesta della chiave al riavvio dopo l’aggiornamento. Per la procedura manuale su VMware, Broadcom chiede anche di sospendere la cifratura legata al TPM e fare uno snapshot.
• Pilota per famiglia di hardware, non su un server a caso: Microsoft suggerisce di provare almeno quattro dispositivi per ogni categoria.
• Supporti di avvio e ripristino: immagini WinPE e PXE, chiavette per il bare-metal restore. Le guide dei produttori contemplano il supporto che non parte più dopo la transizione: meglio scoprirlo ora che durante un ripristino.

Il 12 gennaio, lo stesso parco macchine

Domani, 13 ottobre, finisce il supporto di Windows 10 Enterprise LTSB 2016, la versione tipica di postazioni industriali e dispositivi dedicati; il 12 gennaio 2027 tocca a Windows Server 2016. Gli aggiornamenti di sicurezza estesi, a pagamento, coprono fino a tre anni, ma senza supporto tecnico. In molte sale server i sistemi più indietro sul Secure Boot e quelli in uscita dal supporto saranno le stesse macchine: affrontarli insieme costa meno che farlo in due tempi.

Per chi rientra nella NIS2 c’è anche un tema di conformità: in queste settimane molti soggetti arrivano al termine per le misure di sicurezza di base, tra cui la gestione delle vulnerabilità. Un sistema che non riceve più mitigazioni è un rischio da trattare e documentare.

Il nostro punto di vista

Le scadenze del ciclo di vita non fanno rumore: non generano allarmi, non fermano i servizi, e per questo scivolano in fondo alla lista. Nei progetti data center che seguiamo il primo passo è sempre lo stesso: un inventario che leghi ogni sistema a hardware, firmware, hypervisor e data di fine supporto. Con quella mappa il 19 ottobre e il 12 gennaio diventano un piano di lavoro con priorità chiare, invece di due emergenze.

Il resto è manutenzione con metodo: firmware, certificati e sistemi operativi aggiornati a ondate, con un pilota e un rientro previsto, come facciamo nei nostri Managed Services. Con un’attenzione in più ai supporti di ripristino, perché una procedura di disaster recovery vale quanto il supporto da cui riparte.