Guida alla scadenza dei certificati di Avvio protetto Microsoft

Poiché più certificati di avvio protetto Microsoft scadono nel 2026, questo documento fornisce indicazioni su come aggiornare le istanze Shielded VM di Compute Engine in modo che considerino attendibili i certificati di avvio protetto Microsoft aggiornati per l'avvio protetto UEFI (Unified Extensible Firmware Interface). I due certificati più critici in scadenza sono Microsoft Corporation UEFI CA 2011 (scade il 27 giugno 2026), che firma i bootloader di terze parti come Linux Shim, e Microsoft Windows Production PCA 2011, che scade il 19 ottobre 2026 e firma il bootloader di Windows.

L'avvio protetto UEFI è uno standard di sicurezza utilizzato dalle Shielded VM per garantire che solo software e firmware attendibili vengano eseguiti durante il processo di avvio della VM. Per supportare l'avvio protetto in vari sistemi operativi, Microsoft gestisce i certificati UEFI, memorizzandoli nelle variabili Key Exchange Key (KEK) e Allowed Signature Database (db) all'interno del firmware dell'istanza.

Certificati di avvio protetto e date di scadenza

Nome del certificato Ruolo Data di scadenza
Microsoft Corporation UEFI CA 2011 Firma i bootloader di terze parti, come Linux Shim 27 giugno 2026
Microsoft Windows Production PCA 2011 Firma il bootloader di Windows 19 ottobre 2026
Microsoft Corporation KEK CA 2011 Utilizzato per aggiornare DB e DBX 24 giugno 2026

La scadenza di questo certificato ti riguarda solo se la tua istanza di computing soddisfa entrambi i seguenti prerequisiti obbligatori:

  1. Data di creazione:hai creato l'istanza di Compute prima del 7 novembre 2025 (quando Compute Engine ha aggiornato i certificati Secure Boot predefiniti nel firmware UEFI) e non l'hai aggiornata.
  2. Stato dell'avvio protetto:hai attivato l'avvio protetto sull'istanza. Google Cloud non attiva l'avvio protetto per impostazione predefinita quando crei un'istanza Shielded VM.

Le istanze create a partire dal 7 novembre 2025 includono già i certificati aggiornati nelle variabili del firmware, a condizione che utilizzino un'immagine che si basa sul set di certificati predefinito.

Se la tua istanza non soddisfa entrambi i prerequisiti, la scadenza del certificato non la riguarda e non devi intervenire.

Questo documento spiega come identificare le istanze interessate ed eseguire gli aggiornamenti necessari.

Google Cloud ha completato l'implementazione dei nuovi certificati il 7 novembre 2025. Le istanze che crei a partire da questa data da immagini che si basano sul set predefinito di certificati includono i certificati aggiornati nelle variabili NVRAM/firmware (db e KEK) e non richiedono ulteriori azioni. Tuttavia, alcune istanze create nelle settimane precedenti questa data potrebbero includere anche i nuovi certificati. Per verificare che il sistema sia aggiornato, utilizza i comandi nella sezione Verifica di questo documento.

Nota:la scadenza del certificato Secure Boot non influisce su quanto segue:

  • Istanze con Avvio protetto non abilitato. Tieni presente che se utilizzi i registri di configurazione della piattaforma vTPM (in particolare PCR7) per la sigillatura dei secret, qualsiasi aggiornamento delle variabili UEFI o la ricreazione dell'istanza modificherà comunque le misurazioni PCR7 anche con Secure Boot disattivato, anche se queste configurazioni sono molto rare.
  • Istanze che eseguono Container-Optimized OS (COS).
  • Istanze in cui fornisci la tua chiave della piattaforma di avvio protetto (PK) o la chiave di registrazione della chiave (KEK).

Per le istanze di Compute create prima del 7 novembre 2025 che non dispongono dei certificati aggiornati, segui la guida all'aggiornamento di KEK e db per aggiornare i certificati. Se per qualsiasi motivo non riesci a farlo, valuta la possibilità di ricreare le istanze.

In che modo la scadenza del certificato di avvio protetto influisce su Shielded VM

Se abilitata, Shielded VM applica l'avvio protetto utilizzando il firmware UEFI, che gestisce un insieme di certificati attendibili (nella variabile db) per verificare le firme dei file binari della sequenza di avvio. Se, ad esempio, un aggiornamento del sistema operativo sostituisce un bootloader con uno firmato solo da Microsoft UEFI CA 2023 e il firmware dell'istanza di Compute non considera attendibile l'autorità di questo certificato, la verifica dell'avvio protetto non va a buon fine e l'avvio protetto interrompe il processo di avvio.

Per ulteriori dettagli su questa transizione, consulta le indicazioni di Microsoft e di altri fornitori di sistemi operativi:

Impatto sul sistema operativo

Se hai abilitato l'Avvio protetto su un'istanza Shielded VM creata prima del 7 novembre 2025, ti consigliamo di assicurarti che i certificati 2023 siano installati; in caso contrario, l'istanza di computing riscontrerà problemi di avvio se applichi un aggiornamento contenente un bootloader firmato solo dal certificato Microsoft UEFI CA 2023 (e non con doppia firma con il certificato 2011). Se non intervieni, potresti non essere in grado di applicare futuri aggiornamenti del bootloader o del kernel contenenti binari firmati solo con il certificato 2023. Tieni presente che, poiché i fornitori di sistemi operativi prevedono di firmare in modo duale gli aggiornamenti del bootloader e di shim con i certificati 2011 e 2023 per il prossimo futuro, non è previsto che si verifichino immediatamente errori di avvio o blocchi degli aggiornamenti. Per le istanze di computing create prima del 7 novembre 2025: i clienti Windows potrebbero visualizzare l'ID evento 1801 ("Secure Boot CA/keys need to be updated") nel log eventi di sistema se non hanno applicato gli aggiornamenti dei certificati.

  • Immagini pubbliche fornite da Google:aggiorna i certificati DB e KEK seguendo la guida all'aggiornamento di KEK e DB. In alternativa, valuta la possibilità di ricreare le VM a esecuzione prolungata create prima del 7 novembre 2025.

  • Immagini personalizzate o importate:la maggior parte delle immagini personalizzate o importate si basa su certificati Secure Boot predefiniti. Se non hai eseguito l'override esplicito delle variabili di avvio protetto db o KEK durante la creazione dell'immagine, l'immagine utilizza il set di chiavi predefinito e non richiede alcuna azione a livello di immagine. Compute Engine fornisce automaticamente i certificati aggiornati quando crei un'istanza da qualsiasi immagine che si basa su questi valori predefiniti.

    Devi intervenire solo se hai definito in modo esplicito variabili di Avvio protetto db o KEK personalizzate (ad esempio, per includere il certificato di un fornitore di sicurezza di terze parti insieme ai certificati Microsoft predefiniti) nei metadati dell'immagine durante il processo di compilazione dell'immagine. Poiché la specifica di una variabile db o KEK personalizzata sostituisce completamente i valori predefiniti (e il sistema ignora le chiavi pubbliche predefinite), le variabili personalizzate potrebbero non includere i certificati "Microsoft UEFI CA 2023" o KEK 2023 aggiornati. Se la configurazione dell'immagine personalizzata esclude questi certificati aggiornati, devi ricreare o aggiornare l'immagine protetta per includerli. Per le istruzioni, consulta Creazione di immagini Shielded VM personalizzate.

Se hai istanze di Compute create prima del 7 novembre 2025 con Avvio protetto abilitato, esamina i seguenti requisiti, limitazioni e fattori che complicano la procedura prima di pianificare il percorso di aggiornamento:

  • Requisiti pre-aggiornamento:
    • Verifica l'accesso alla chiave di recupero:se le tue istanze utilizzano la crittografia completa del disco (inclusa BitLocker su Windows o LUKS su Linux), devi assicurarti di avere accesso alle chiavi di recupero prima di aggiornare i certificati o ricreare le istanze. La modifica delle variabili UEFI altera le misurazioni di avvio e attiverà le richieste di ripristino.
    • Gestisci i secret vTPM:se le tue istanze utilizzano i registri di configurazione della piattaforma vTPM (in particolare PCR7) per la sigillatura dei secret, devi dissigillarli o eseguirne il backup prima dell'aggiornamento per evitare di perdere l'accesso in modo permanente.
  • Fattori e limiti che complicano la situazione:
    • Requisito di aggiornamento dell'ordine:per evitare errori di verifica della CA e cicli di avvio del sistema, devi installare i nuovi certificati db e KEK prima di applicare nuovi aggiornamenti del kernel o di shim.
    • Rollback del firmware:il ripristino di un'istanza su un'immagine macchina legacy acquisita prima del 7 novembre 2025 ripristina il vecchio firmware e rimuove l'attendibilità dei certificati del 2023. Se esegui il rollback, devi applicare nuovamente gli aggiornamenti del certificato.

Per una suddivisione dettagliata delle tempistiche, dei passaggi di controllo e dei processi di migrazione, consulta le seguenti istruzioni.

Impatto su configurazioni guest specifiche

Comprendi in che modo la scadenza del certificato influisce su ogni configurazione solo se la tua istanza soddisfa entrambi i prerequisiti obbligatori (l'hai creata prima del 7 novembre 2025 e ha l'avvio protetto abilitato):

  • Sigillatura del segreto PCR vTPM:
    • Quando diventa un fattore:quando utilizzi i registri di configurazione della piattaforma vTPM (in particolare PCR7) per sigillare i secret, ad esempio le chiavi di decrittografia.
    • Impatto:l'aggiornamento dei certificati di avvio protetto (utilizzando la guida all'aggiornamento di KEK e db o ricreando l'istanza da uno snapshot del disco) modifica le variabili UEFI, cambiando il valore di misurazione PCR7 al successivo avvio. Questa modifica impedisce al sistema operativo guest o alle applicazioni di sbloccare o decriptare questi secret a meno che tu non li sblocchi o esegua il backup prima dell'aggiornamento e poi li sigilli di nuovo con il nuovo valore di PCR7.
    • Quando non è interessata:se hai creato la VM a partire dal 7 novembre 2025 da un'immagine che si basa sui certificati predefiniti, non devi aggiornare i certificati, PCR7 rimane invariato e la sigillatura dei secret funziona normalmente.
  • Istanze di calcolo Windows che utilizzano BitLocker o la modalità sicura virtuale (VSM):
    • Quando diventa un fattore: quando le tue VM Windows utilizzano la crittografia completa del disco BitLocker o VSM, entrambe si basano sull'avvio protetto UEFI e su PCR7 per sigillare le chiavi di crittografia.
    • Impatto: la modifica dei certificati di avvio protetto UEFI o la ricreazione dell'istanza da uno snapshot modifica le misurazioni di avvio di PCR7. Al riavvio successivo, BitLocker rileva la modifica alla configurazione, non riesce a rilasciare automaticamente la chiave e si avvia in una schermata di recupero di BitLocker che richiede la chiave di recupero.
    • Correzione:prima di aggiornare i certificati o eseguire la migrazione delle istanze, devi verificare di avere a disposizione le chiavi di ripristino di BitLocker. Dopodiché, segui le indicazioni riportate in Aggiornare il database e la KEK su Windows.
    • Quando non è interessato:la scadenza del certificato non influisce sulle istanze Windows senza BitLocker o VSM abilitati o su quelle senza l'avvio protetto abilitato.
  • VM Linux che utilizzano FDE:
    • Quando diventa un fattore: quando le tue istanze Linux utilizzano FDE, ad esempio LUKS, in cui sigilli le chiavi di decrittografia ai PCR vTPM (in particolare PCR7).
    • Impatto:l'aggiornamento dei certificati di Avvio protetto o la ricreazione della VM modifica PCR7, impedendo la decrittografia automatica del volume di avvio. Il sistema si arresta durante l'avvio e ti chiede una passphrase di decrittografia.
    • Correzione:conferma di avere le frasi di recupero o le chiavi prima di eseguire gli aggiornamenti. Svincola o sblocca le chiavi LUKS dal TPM prima dell'aggiornamento e riassociale o bloccale di nuovo con il nuovo valore PCR7 dopo aver completato l'aggiornamento.
    • Quando non è interessata:la scadenza del certificato non influisce sulle VM Linux che non utilizzano la decrittografia LUKS sigillata con FDE o vTPM o quelle che non hanno l'avvio protetto attivato.
  • Istanze che eseguono il rollback a un'immagine macchina precedente a novembre 2025:
    • Quando diventa un fattore: quando ripristini o esegui il rollback di una VM a un'immagine macchina acquisita prima del 7 novembre 2025 con l'avvio protetto attivato.
    • Impatto:l'istanza di cui è stato eseguito il rollback ripristina la configurazione e l'archivio certificati del firmware UEFI precedente, che non include i certificati del 2023. Ciò rende l'istanza vulnerabile a futuri errori di avvio dopo successivi aggiornamenti del bootloader, il che richiede di riapplicare gli aggiornamenti del certificato.
    • Quando non è interessata:il rollback a un'immagine macchina non influisce sull'istanza se disattivi l'avvio protetto o se hai creato l'immagine macchina il 7 novembre 2025 o dopo questa data da un'immagine che si basa sui certificati predefiniti.

Identificare le istanze di computing interessate e pianificare l'aggiornamento

Nel corso del 2026, ti consigliamo di identificare le istanze di calcolo interessate e di seguire questi passaggi per prepararti all'aggiornamento:

  1. Identifica le istanze:puoi utilizzare il comando gcloud compute instances list per identificare le istanze in cui è abilitato l'avvio protetto e che sono state create prima della data limite:

    gcloud compute instances list \
--filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
--format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"

  2. (Facoltativo) Controlla le variabili personalizzate: se utilizzi immagini personalizzate o importate, verifica se definiscono esplicitamente le variabili di avvio protetto db o KEK (che sostituiscono completamente i valori predefiniti). Se si basano su certificati predefiniti, non richiedono alcuna azione a livello di immagine:

    • Per controllare un'istanza VM, esegui:

      gcloud compute instances describe INSTANCE_NAME \
    --zone=ZONE \
    --format="yaml(shieldedInstanceInitialState)"

    • Per controllare un'immagine del disco di origine, esegui:

      gcloud compute images describe IMAGE_NAME \
    --format="yaml(shieldedInstanceInitialState)"

    Se l'output è vuoto o restituisce null, l'istanza o l'immagine utilizza i certificati predefiniti e non richiede alcuna azione a livello di immagine.

  3. Garantisci l'integrità dei dati:assicurati di avere backup recenti dei dati e l'accesso alle chiavi di recupero FDE o BitLocker prima di procedere con qualsiasi modifica.

  4. Aggiorna i certificati:aggiorna i certificati DB e KEK seguendo la guida all'aggiornamento di KEK e DB. In alternativa, esegui la migrazione a un'istanza di Compute che crei a partire dal 7 novembre 2025, che include i certificati 2023 (a condizione che la nuova istanza utilizzi un'immagine che si basa sui certificati predefiniti), seguendo le istruzioni riportate in Ricrea un'istanza di Compute da uno snapshot del disco.

Ricrea un'istanza di computing da uno snapshot del disco

Quando crei uno snapshot del disco e crei una nuova istanza da questo snapshot, la nuova istanza di Compute eredita uno stato firmware (vTPM/NVRAM) nuovo che considera attendibili i valori predefiniti aggiornati ed elimina i vecchi certificati.

Prima di ricreare un'istanza di computing da uno snapshot, assicurati che il sistema operativo guest abbia installato tutti gli aggiornamenti necessari (ad esempio le KB Microsoft pertinenti per Windows o l'ultimo shim per le distribuzioni Linux) per considerare attendibili i certificati del 2023.

Per gestire questa migrazione, puoi utilizzare la seguente sequenza di comandi gcloud:

  1. Identifica il disco di avvio:determina il nome del disco di avvio collegato all'istanza di computing di origine:

    SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
    --zone=ZONE \
    --format="value(disks[0].source.basename())")

  2. Crea uno snapshot del disco:esegui uno snapshot del disco di avvio. Per un'integrità ottimale dei dati, arresta l'istanza di computing prima di eseguire questo comando:

    gcloud compute disks snapshot $SOURCE_DISK \
    --snapshot-names="migration-snapshot-$(date +%s)" \
    --zone=ZONE \
    --storage-location=REGION

  3. Crea una nuova istanza di computing:esegui il provisioning di una nuova istanza di computing utilizzando lo snapshot come origine di avvio. Se l'avvio protetto è abilitato nell'istanza di origine, includi il flag --shielded-secure-boot per abilitare l'avvio protetto nella nuova istanza.

    gcloud compute instances create NEW_INSTANCE_NAME \
    --zone=ZONE \
    --machine-type=MACHINE_TYPE \
    --create-disk=name=NEW_DISK_NAME,source-snapshot=SNAPSHOT_NAME,boot=yes \
    --shielded-secure-boot

Nota:le istanze di cui è stato eseguito il provisioning utilizzando questo approccio ricevono nuovi indirizzi IP interni ed esterni, a meno che non siano allocati staticamente e riassegnati in modo specifico. I metadati, i tag e i service account a livello di istanza non vengono replicati automaticamente e devono essere configurati in modo esplicito durante la ricreazione.

Verifica

Dopo aver aggiornato il firmware e il sistema operativo delle istanze di calcolo, puoi verificare che i certificati del 2023 siano presenti. Se entrambe le variabili KEK e db mostrano che i certificati del 2023 sono presenti, la tua istanza è aggiornata e non sono necessarie ulteriori azioni.

Linux

Puoi verificare i database delle firme su Linux utilizzando il comando efi-readvar del pacchetto efitools o (sulle distribuzioni in cui efitools non è disponibile, ad esempio RHEL 8/9) utilizzando mokutil.

Metodo 1: utilizzo di efi-readvar

  1. Se efi-readvar non è presente, installa il pacchetto efitools. Per l'installazione su Linux, esegui il comando per la tua distribuzione:

    Debian/Ubuntu

    sudo apt update && sudo apt install efitools

    RHEL/CentOS/Fedora (solo Fedora; efitools non è disponibile nei repository RHEL/CentOS)

    sudo yum install efitools

    SLES

    sudo zypper install efitools

  2. Controlla i certificati nelle variabili KEK e db:

    sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
sudo efi-readvar -v db | grep "UEFI CA 2023"

Metodo 2: utilizzare mokutil

Nelle distribuzioni come Red Hat Enterprise Linux (RHEL) in cui efitools non è disponibile, utilizza l'utilità mokutil, che è installata per impostazione predefinita:

sudo mokutil --kek | grep "KEK 2K CA 2023"
sudo mokutil --db | grep "UEFI CA 2023"

Windows (PowerShell)

Esegui il seguente comando in un prompt di PowerShell amministratore. Ogni comando deve restituire True.

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

Risoluzione dei problemi

Se un'istanza non si avvia a causa di un errore di avvio protetto dopo giugno 2026, prova una delle seguenti opzioni per recuperarla:

  • Disabilita temporaneamente l'avvio protetto:in questo modo puoi avviare l'istanza per applicare gli aggiornamenti.

    Nota:la disattivazione dell'avvio protetto modifica i valori PCR, in particolare PCR7, il che potrebbe influire sulla funzionalità di sigillatura dei secret o di crittografia del disco.

    Per disattivare l'avvio protetto, esegui questo comando:

    gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot

    Dopo aver applicato gli aggiornamenti necessari al bootloader/shim, riattiva l'avvio protetto:

    gcloud compute instances update INSTANCE_NAME --shielded-secure-boot

  • Ripristina dal backup: ripristina l'istanza da un'immagine macchina creata prima dell'inizio dei problemi di avvio.

  • Ricrea istanza:ricrea l'istanza e recupera i dati da uno snapshot.

Se continui a riscontrare problemi o hai bisogno di aiuto, contatta l'assistenza clienti Google Cloud.

Domande frequenti

Questa sezione fornisce risposte alle domande più comuni sulla scadenza del certificato Microsoft Secure Boot.

Quando scadono i certificati di avvio protetto?

I certificati di avvio protetto di Microsoft scadranno nel 2026. In particolare:

  • I due certificati più critici che si avvicinano alla fine del ciclo di vita sono Microsoft Corporation UEFI CA 2011 (scade a giugno 2026), che firma bootloader di terze parti come Linux Shim, e Microsoft Windows Production PCA 2011, che scade a ottobre 2026 e firma il bootloader di Windows.

Chi è interessato dalla scadenza del certificato?

La scadenza di questo certificato ti riguarda solo se la tua istanza di computing soddisfa entrambi i seguenti prerequisiti obbligatori:

  1. Hai creato l'istanza prima del 7 novembre 2025, quando Compute Engine ha aggiornato i certificati di avvio protetto predefiniti nel firmware UEFI, e non l'hai aggiornata.
  2. Hai abilitato l'avvio protetto sull'istanza.

Le istanze che crei a partire dal 7 novembre 2025 non sono interessate, a condizione che le crei da un'immagine che si basa sul set di certificati predefinito.

Se la tua istanza soddisfa entrambi i prerequisiti, la scadenza del certificato influisce sulle seguenti configurazioni in circostanze specifiche:

  • Sigillatura dei secret PCR vTPM:se l'istanza utilizza i registri di configurazione della piattaforma (PCR) del Virtual Trusted Platform Module (vTPM), in particolare PCR7, per sigillare chiavi di crittografia o secret.
  • Windows BitLocker / VSM:se la tua istanza Windows utilizza la crittografia del disco BitLocker o la modalità protetta virtuale (VSM) con l'avvio protetto.
  • Linux FDE:se la tua istanza Linux utilizza FDE che sigilli ai PCR vTPM (in particolare PCR7).
  • Rollback delle istanze:se ripristini o esegui il rollback della VM a un'immagine della macchina che hai creato prima del 7 novembre 2025.

Per un'analisi dettagliata dell'impatto e dei passaggi di correzione per ciascuna di queste configurazioni, vedi Impatto su configurazioni guest specifiche.

Chi non è interessato dalla scadenza del certificato?

La scadenza del certificato non ti riguarda se si verifica una delle seguenti condizioni:

  • L'avvio protetto è disabilitato:se l'avvio protetto non è abilitato nella tua istanza Shielded VM, non convalida né utilizza i certificati UEFI in scadenza. L'avvio protetto è disattivato per impostazione predefinita. Tuttavia, tieni presente che se utilizzi i registri di configurazione della piattaforma vTPM (in particolare PCR7) per la sigillatura dei secret, qualsiasi aggiornamento delle variabili UEFI o la ricreazione dell'istanza modificherà comunque le misurazioni di PCR7 anche con Secure Boot disattivato, anche se queste configurazioni sono molto rare.
  • Creata a partire dal 7 novembre 2025: hai creato l'istanza a partire da questa data, quindi il suo firmware include già i certificati aggiornati del 2023, a condizione che tu l'abbia creata da un'immagine che si basa sul set di certificati predefinito.
  • Esecuzione di Container-Optimized OS (COS): questi aggiornamenti dei certificati non influiscono sugli ambienti COS.
  • Variabili PK, KEK o db personalizzate: se definisci e gestisci esplicitamente le tue variabili personalizzate di Avvio protetto PK, KEK o db senza fare affidamento sui certificati UEFI Microsoft predefiniti, la scadenza dei certificati predefiniti non ti riguarda. Tuttavia, sei responsabile dell'aggiornamento e della manutenzione dei tuoi certificati.

Cosa succede se non intervengo?

Se non intraprendi alcuna azione, l'istanza continua ad avviarsi e a funzionare normalmente con i relativi file binari esistenti. Tuttavia, potresti non essere in grado di applicare futuri aggiornamenti del bootloader o del kernel contenenti binari firmati solo con il certificato 2023. Tieni presente che, poiché i fornitori di sistemi operativi firmano due volte gli aggiornamenti del bootloader e di shim con i certificati 2011 e 2023, non è previsto che si verifichino immediatamente errori di avvio o blocchi degli aggiornamenti.

Se non riesco ad aggiornare i certificati, le istanze Windows non si avvieranno?

No. La mancata correzione non impedirà l'avvio del sistema Windows. Tuttavia, potresti visualizzare l'ID evento 1801 ("È necessario aggiornare CA/chiavi di avvio protetto") nel log eventi di sistema e non potrai applicare nuovi aggiornamenti di sicurezza del kernel o del bootloader contenenti file binari firmati solo con il nuovo certificato 2023.

Quali condizioni specifiche attivano errori di avvio su Linux?

Un errore di avvio può verificarsi su Linux in condizioni specifiche:

  • L'istanza ha Avvio protetto abilitato.
  • La variabile UEFI db non viene aggiornata per considerare attendibile il certificato "Microsoft UEFI CA 2023".
  • Il sistema operativo aggiorna un bootloader (o shim) che si basa rigorosamente su questo certificato (e non è firmato due volte con il certificato del 2011).

Se non applichi gli aggiornamenti dei certificati o gli aggiornamenti degli shim che fanno riferimento ai nuovi certificati, l'istanza Linux continuerà ad avviarsi correttamente.

Come faccio a determinare se la mia istanza dispone dei certificati aggiornati?

Per determinare se la tua istanza include i nuovi certificati nel firmware, consulta i comandi descritti nella sezione Verifica. Se mancano i certificati, puoi aggiornarli seguendo la guida all'aggiornamento di KEK e db o ricreare l'istanza.

Il riavvio di un'istanza interessata risolve il problema?

No. Il riavvio di un'istanza di computing non aggiorna i relativi certificati di avvio protetto, ma l'istanza continua ad avviarsi e a funzionare normalmente con i certificati esistenti finché non viene applicato un aggiornamento del bootloader o del kernel che contiene binari firmati solo con il certificato 2023. Se riavvii l'istanza di computing, questa conserva i vecchi certificati se è stata creata originariamente prima del 7 novembre 2025. I certificati fanno parte del firmware dell'istanza (vTPM/NVRAM). Pertanto, devi seguire la guida all'aggiornamento di KEK e db o ricreare l'istanza per applicare i nuovi certificati.

Come devo prepararmi alla scadenza del certificato?

Per prepararti, segui questi passaggi:

  • Identifica:controlla l'utilizzo di Shielded VM, Avvio protetto, FDE, BitLocker o qualsiasi software che si basa sui PCR vTPM.
  • Chiavi di recupero e backup:garantisci la pronta disponibilità delle chiavi di recupero (per FDE/BitLocker) e degli ultimi backup dei dati.
  • Gestisci immagini:identifica le immagini personalizzate legacy e interrompine l'utilizzo o assicurati che includano i nuovi certificati.
  • Aggiorna o esegui la migrazione: se vuoi aggiornare i certificati, consulta la guida all'aggiornamento di KEK e db. In alternativa, valuta la possibilità di ricreare le istanze di computing a lunga esecuzione che hai creato prima del 7 novembre 2025, poiché le nuove istanze includono già i certificati necessari (a condizione che tu crei la nuova istanza da un'immagine che si basa sui certificati predefiniti).

Gli snapshot standard del disco forniscono il metodo più affidabile. Uno snapshot è una copia a livello di blocco del disco e non contiene variabili UEFI o metadati a livello di istanza. Per eseguire il ripristino utilizzando uno snapshot:

  1. Crea uno snapshot del disco di avvio dell'istanza.
  2. Crea una nuova istanza di computing e seleziona lo snapshot come origine per il disco di avvio.

Non devi utilizzare le immagini macchina, la clonazione delle istanze o il servizio di Backup e DR per questa migrazione perché replicano il firmware dell'istanza e conservano i vecchi certificati per qualsiasi istanza di computing di origine creata prima del 7 novembre 2025.

Cosa devo fare se il mio sistema smette di avviarsi dopo giugno 2026?

Se ritieni che questo problema abbia causato un errore di avvio, consulta la sezione Risoluzione dei problemi.

In che modo Google Cloud gestisce la scadenza dei certificati di avvio protetto Microsoft?

Google Cloud inclusi automaticamente i nuovi certificati per le istanze di calcolo create dopo il 7 novembre 2025. Solo i clienti che vogliono mantenere in esecuzione le istanze di calcolo precedenti al 7 novembre 2025 potrebbero dover applicare un aggiornamento futuro, ma consigliamo di eseguire la migrazione a un'istanza creata a partire dal 7 novembre 2025 (che si basa su certificati predefiniti).

Passaggi successivi