Leitfaden zum Ablauf von Microsoft Secure Boot-Zertifikaten

Da mehrere Microsoft Secure Boot-Zertifikate im Jahr 2026 ablaufen, enthält dieses Dokument eine Anleitung zum Aktualisieren von Compute Engine-Shielded VM-Instanzen, damit sie den aktualisierten Microsoft Secure Boot-Zertifikaten für UEFI (Unified Extensible Firmware Interface) Secure Boot vertrauen. Die beiden kritischsten Zertifikate, deren Ablaufdatum sich nähert, sind die Microsoft Corporation UEFI CA 2011 (läuft am 27. Juni 2026 ab), mit der Drittanbieter-Bootloader wie der Linux-Shim signiert werden, und die Microsoft Windows Production PCA 2011, die am 19. Oktober 2026 abläuft und mit der der Windows-Bootloader signiert wird.

UEFI Secure Boot ist ein Sicherheitsstandard, der von Shielded VMs verwendet wird, um sicherzustellen, dass während des VM-Bootvorgangs nur vertrauenswürdige Software und Firmware ausgeführt werden. Um Secure Boot für verschiedene Betriebssysteme zu unterstützen, verwaltet Microsoft UEFI-Zertifikate und speichert sie in den Variablen „Key Exchange Key“ (KEK) und „Allowed Signature Database“ (db) in der Instanz-Firmware.

Hinweise für Nutzer des Backup- und DR-Dienstes

Da der Backup- und DR-Dienst ein verwalteter Dienst ist,werden das zugrunde liegende Betriebssystem und die Secure Boot-Zertifikatsupdates für Ihre Appliances automatisch von Google Cloud verwaltet. Sie müssen nichts unternehmen: Ihre vorhandenen Appliances werden weiterhin normal gestartet und funktionieren wie gewohnt. Neue Appliances, die Sie bereitstellen, enthalten automatisch die aktualisierten Secure Boot-Zertifikate.

Secure Boot-Zertifikate und Ablaufdaten

Microsoft verwaltet die UEFI Secure Boot-Zertifikate, die zum Validieren von Bootloader-Signaturen während des VM-Bootvorgangs verwendet werden. In den folgenden Abschnitten werden die 2011-Zertifikate, die ablaufen, und die neueren 2023-Zertifikate, die sie ersetzen, aufgeführt.

Ablaufende Zertifikate

In der folgenden Tabelle wird das endgültige Ablaufdatum für die alten Secure Boot-Zertifikate beschrieben:

Name des Zertifikats Rolle Ablaufdatum
Microsoft Corporation UEFI CA 2011 Signiert Drittanbieter-Bootloader wie den Linux-Shim 27. Juni 2026
Microsoft Windows Production PCA 2011 Signiert den Windows-Bootloader 19. Oktober 2026
Microsoft Corporation KEK CA 2011 Wird zum Aktualisieren der DB und DBX verwendet. 24. Juni 2026

Neue Zertifikate

In der folgenden Tabelle wird das endgültige Ablaufdatum für die neuen Secure Boot-Zertifikate beschrieben:

Name des Zertifikats Rolle Ablaufdatum
Microsoft UEFI CA 2023 Signiert Drittanbieter-Bootloader wie den Linux-Shim 13. Juni 2038
Windows UEFI CA 2023 Signiert den Windows-Bootloader 13. Juni 2035
Microsoft Corporation KEK 2K CA 2023 Wird zum Aktualisieren der DB und DBX verwendet. 2. März 2038
Microsoft Option ROM UEFI CA 2023 UEFI-Treiber und Option-ROMs signieren 26. Okt. 2038

Das Ablaufen dieses Zertifikats betrifft Sie nur, wenn Ihre Compute-Instanz die beiden folgenden obligatorischen Voraussetzungen erfüllt:

  1. Erstellungsdatum:Sie haben die Compute-Instanz vor dem 7. November 2025 erstellt (als Compute Engine die standardmäßigen Secure Boot-Zertifikate in der UEFI-Firmware aktualisiert hat) und sie nicht aktualisiert.
  2. Secure Boot-Status:Sie haben Secure Boot für die Instanz aktiviert. Google Cloud aktiviert Secure Boot nicht standardmäßig, wenn Sie eine Shielded VM-Instanz erstellen.

Instanzen, die Sie am oder nach dem 7. November 2025 erstellen, enthalten die aktualisierten Zertifikate bereits in ihren Firmware-Variablen, sofern sie ein Image verwenden, das auf dem Standardzertifikatsatz basiert.

Wenn Ihre Instanz nicht beide Voraussetzungen erfüllt, wirkt sich der Zertifikatsablauf nicht auf sie aus und Sie müssen nichts unternehmen.

In diesem Dokument wird beschrieben, wie Sie betroffene Instanzen identifizieren und die erforderlichen Updates durchführen.

Google Cloud haben wir die neuen Zertifikate am 7. November 2025 eingeführt. Bei Instanzen, die Sie ab diesem Datum aus Images erstellen, die auf dem Standardsatz von Zertifikaten basieren, sind die aktualisierten Zertifikate in den NVRAM-/Firmware-Variablen (db und KEK) enthalten. Es sind keine weiteren Maßnahmen erforderlich. Einige Instanzen, die Sie in den Wochen vor diesem Datum erstellt haben, enthalten möglicherweise auch die neuen Zertifikate. Verwenden Sie die Befehle im Abschnitt Bestätigung dieses Dokuments, um zu prüfen, ob Ihr System auf dem neuesten Stand ist.

Hinweis:Das Ablaufen des Zertifikats für den sicheren Start hat keine Auswirkungen auf Folgendes:

  • Instanzen, für die Secure Boot nicht aktiviert ist. Wenn Sie vTPM-Plattformkonfigurationsregister (insbesondere PCR7) für das Versiegeln von Geheimnissen verwenden, werden durch Aktualisierungen von UEFI-Variablen oder das Neuerstellen der Instanz weiterhin PCR7-Messungen geändert, auch wenn Secure Boot deaktiviert ist. Solche Konfigurationen sind jedoch sehr selten.
  • Instanzen, auf denen Container-Optimized OS (COS) ausgeführt wird.
  • Instanzen, in denen Sie benutzerdefinierte Secure Boot-Variablen verwenden (z. B. ein benutzerdefiniertes PK, KEK oder db) und Ihr Bootloader mit Ihrem eigenen benutzerdefinierten Zertifikat anstelle der ablaufenden Microsoft Corporation UEFI CA 2011 signiert ist. Wenn Sie benutzerdefinierte Schlüssel verwenden, aber weiterhin auf die ablaufende Microsoft-Zertifizierungsstelle zum Signieren Ihres Bootloaders angewiesen sind, finden Sie unter Instanzen mit benutzerdefinierten PK- oder KEK-Konfigurationen Informationen zu den Anforderungen für die Schlüsselaktualisierung.
  • Google Cloud Backup- und DR-Appliances. Diese Geräte werden verwaltet. Das Ablaufen des Zertifikats hat keine Auswirkungen auf den Betrieb Ihrer Geräte und Sie müssen sie nicht manuell aktualisieren. Google Cloudverwaltet alle Zertifikatsaktualisierungen automatisch.

Für Compute-Instanzen, die vor dem 7. November 2025 erstellt wurden und nicht über die aktualisierten Zertifikate verfügen, folgen Sie der Anleitung zum Aktualisieren von KEK und Datenbank, um die Zertifikate zu aktualisieren. Wenn Sie das aus irgendeinem Grund nicht tun können, sollten Sie die Instanzen neu erstellen.

Auswirkungen des Ablaufs von Secure Boot-Zertifikaten auf Shielded VM

Wenn Secure Boot aktiviert ist, wird es von Shielded VMs mit UEFI-Firmware erzwungen. Diese enthält eine Reihe vertrauenswürdiger Zertifikate (in der Variablen db), mit denen die Signaturen der Binärdateien der Startsequenz überprüft werden. Wenn beispielsweise durch ein Betriebssystemupdate ein Bootloader durch einen ersetzt wird, der nur von Microsoft UEFI CA 2023 signiert ist, und die Firmware der Compute-Instanz die Zertifizierungsstelle dieses Zertifikats nicht als vertrauenswürdig einstuft, schlägt die Secure Boot-Überprüfung fehl und Secure Boot stoppt den Bootvorgang.

Weitere Informationen zu dieser Umstellung finden Sie in den Anleitungen von Microsoft und anderen Betriebssystemanbietern:

Auswirkungen auf das Betriebssystem

Wenn Sie Secure Boot auf einer Shielded VM-Instanz aktiviert haben, die vor dem 7. November 2025 erstellt wurde, empfehlen wir, dass Sie die 2023-Zertifikate installieren. Andernfalls treten bei der Compute-Instanz Startprobleme auf, wenn Sie ein Update anwenden, das einen Bootloader enthält, der nur mit dem Microsoft UEFI CA 2023-Zertifikat signiert ist (und nicht mit dem 2011-Zertifikat doppelt signiert ist). Wenn Sie nichts unternehmen, können Sie möglicherweise keine zukünftigen Bootloader- oder Kernel-Updates anwenden, die Binärdateien enthalten, die nur mit dem Zertifikat von 2023 signiert sind. Da Betriebssystemanbieter in absehbarer Zukunft planen, Bootloader- und Shim-Updates sowohl mit den Zertifikaten von 2011 als auch mit denen von 2023 zu signieren, sind Bootfehler oder Update-Blockierungen nicht sofort zu erwarten. Für Compute-Instanzen, die vor dem 7. November 2025 erstellt wurden: Windows-Kunden sehen möglicherweise die Ereignis-ID 1801 („Secure Boot CA/keys need to be updated“) im Systemereignisprotokoll, wenn sie die Zertifikatsupdates nicht angewendet haben.

  • Von Google bereitgestellte öffentliche Images:Aktualisieren Sie DB- und KEK-Zertifikate gemäß der Anleitung zum Aktualisieren von KEK und DB. Alternativ können Sie alle VMs, die vor dem 7. November 2025 erstellt wurden und lange ausgeführt werden, neu erstellen.

  • Benutzerdefinierte oder importierte Images:Die meisten benutzerdefinierten oder importierten Images basieren auf standardmäßigen Secure Boot-Zertifikaten. Wenn Sie die Secure Boot-Variablen db oder KEK beim Erstellen des Images nicht explizit überschrieben haben, verwendet das Image den Standardschlüsselsatz und es sind keine Maßnahmen auf Image-Ebene erforderlich. Compute Engine stellt die aktualisierten Zertifikate automatisch bereit, wenn Sie eine Instanz aus einem Image erstellen, das auf diesen Standardeinstellungen basiert.

    Sie müssen nur dann Maßnahmen ergreifen, wenn Sie während des Image-Erstellungsprozesses benutzerdefinierte db- oder KEK-Variablen für den sicheren Start in den Image-Metadaten explizit definiert haben, z. B. um das Zertifikat eines Drittanbieters für Sicherheit neben den Standardzertifikaten von Microsoft einzufügen. Da durch die Angabe einer benutzerdefinierten db- oder KEK-Variable die Standardeinstellungen vollständig überschrieben werden (und das System die öffentlichen Standardschlüssel ignoriert), fehlen in Ihren benutzerdefinierten Variablen möglicherweise die aktualisierten Zertifikate „Microsoft UEFI CA 2023“ oder 2023 KEK. Wenn Ihre benutzerdefinierte Image-Konfiguration diese aktualisierten Zertifikate ausschließt, müssen Sie Ihr Shielded Image neu erstellen oder aktualisieren, damit sie enthalten sind. Eine Anleitung finden Sie unter Benutzerdefinierte Shielded VM-Images erstellen.

Wenn Sie Compute-Instanzen haben, die vor dem 7. November 2025 mit aktiviertem sicheren Start erstellt wurden, sollten Sie sich die folgenden Anforderungen, Einschränkungen und erschwerenden Faktoren ansehen, bevor Sie Ihren Aktualisierungspfad planen:

  • Voraussetzungen für die Aktualisierung:
    • Zugriff auf Wiederherstellungsschlüssel prüfen:Wenn Ihre Instanzen FDE verwenden (einschließlich BitLocker unter Windows oder LUKS unter Linux), müssen Sie sicherstellen, dass Sie Zugriff auf Ihre Wiederherstellungsschlüssel haben, bevor Sie Zertifikate aktualisieren oder Instanzen neu erstellen. Durch das Ändern von UEFI-Variablen werden die Boot-Messungen geändert und es werden Wiederherstellungsaufforderungen ausgelöst.
    • vTPM-Secrets verwalten:Wenn Ihre Instanzen vTPM-Plattformkonfigurationsregister (insbesondere PCR7) für das Versiegeln von Secrets verwenden, müssen Sie diese Secrets vor dem Aktualisieren entsiegeln oder sichern, um einen dauerhaften Verlust des Zugriffs zu verhindern.
  • Einschränkungen und Faktoren, die die Analyse erschweren:
    • Anforderung für die Aktualisierungsreihenfolge:Damit CA-Prüfungen nicht fehlschlagen und das System nicht in einer Bootschleife hängen bleibt, müssen Sie die neuen db- und KEK-Zertifikate installieren, bevor Sie neue Kernel- oder Shim-Updates anwenden.
    • Firmware-Rollbacks:Wenn Sie eine Instanz auf ein altes Maschinen-Image zurücksetzen, das vor dem 7. November 2025 aufgenommen wurde, wird die alte Firmware wiederhergestellt und das Vertrauen in die Zertifikate von 2023 wird entfernt. Wenn Sie ein Rollback durchführen, müssen Sie die Zertifikatsaktualisierungen noch einmal anwenden.

Eine detaillierte Aufschlüsselung der Zeitpläne, Prüfschritte und Migrationsprozesse finden Sie in der folgenden Anleitung.

Auswirkungen auf bestimmte Gastkonfigurationen

Die Auswirkungen des Zertifikatsablaufs auf die einzelnen Konfigurationen sind nur relevant, wenn Ihre Instanz beide obligatorischen Voraussetzungen erfüllt: Sie wurde vor dem 7. November 2025 erstellt und Secure Boot ist aktiviert.

  • vTPM-PCR-Secret-Sealing:
    • Wann wird es zu einem Faktor? Wenn Sie vTPM-Plattformkonfigurationsregister (insbesondere PCR7) verwenden, um Secrets wie Entschlüsselungsschlüssel zu versiegeln.
    • Auswirkungen:Wenn Sie Secure Boot-Zertifikate aktualisieren (entweder mit der Anleitung zum Aktualisieren von KEK und db oder durch Neuerstellen der Instanz aus einem Laufwerk-Snapshot), werden UEFI-Variablen geändert. Dadurch ändert sich der PCR7-Messwert beim nächsten Booten. Durch diese Änderung wird verhindert, dass das Gastbetriebssystem oder Anwendungen diese vertraulichen Daten entsiegeln oder entschlüsseln, es sei denn, Sie entsiegeln oder sichern die vertraulichen Daten vor dem Update und versiegeln sie anschließend mit dem neuen PCR7-Wert.
    • Nicht betroffen:Wenn Sie die VM am oder nach dem 7. November 2025 aus einem Image erstellt haben, das auf den Standardzertifikaten basiert, müssen Sie die Zertifikate nicht aktualisieren. PCR7 bleibt unverändert und die geheime Versiegelung funktioniert normal.
  • Windows-Compute-Instanzen mit BitLocker oder Virtual Secure Mode (VSM):
    • Wann wird es zu einem Faktor? Wenn Ihre Windows-VMs die BitLocker-Vollverschlüsselung oder VSM verwenden, die beide UEFI Secure Boot und PCR7 zum Versiegeln ihrer Verschlüsselungsschlüssel nutzen.
    • Auswirkungen:Wenn Sie UEFI Secure Boot-Zertifikate ändern oder die Instanz aus einem Snapshot neu erstellen, ändern sich die PCR7-Boot-Messwerte. Beim nächsten Neustart erkennt BitLocker die Konfigurationsänderung, kann den Schlüssel nicht automatisch freigeben und startet mit dem BitLocker-Wiederherstellungsbildschirm, auf dem der Wiederherstellungsschlüssel angefordert wird.
    • Abhilfemaßnahmen:Sie müssen bestätigen, dass Sie Ihre BitLocker-Wiederherstellungsschlüssel verfügbar haben, bevor Sie Zertifikate aktualisieren oder Instanzen migrieren. Folgen Sie anschließend der Anleitung unter Datenbank und KEK unter Windows aktualisieren.
    • Wenn nicht betroffen:Das Ablaufen des Zertifikats hat keine Auswirkungen auf Windows-Instanzen ohne aktiviertes BitLocker oder VSM oder ohne aktiviertes Secure Boot.
  • Linux-VMs mit FDE:
    • Wann wird es zu einem Faktor? Wenn Ihre Linux-Instanzen FDE wie LUKS verwenden, bei der Sie die Entschlüsselungsschlüssel an vTPM-PCRs (insbesondere PCR7) binden.
    • Auswirkungen:Wenn Sie die Secure Boot-Zertifikate aktualisieren oder die VM neu erstellen, wird PCR7 geändert. Dadurch kann das Bootlaufwerk nicht automatisch entschlüsselt werden. Das System wird während des Startvorgangs angehalten und Sie werden aufgefordert, eine Entschlüsselungs-Passphrase einzugeben.
    • Abhilfe:Prüfen Sie, ob Sie die Wiederherstellungs-Passphrasen oder -Schlüssel haben, bevor Sie Updates ausführen. Heben Sie die Bindung oder Versiegelung der LUKS-Schlüssel vom TPM vor dem Update auf und binden oder versiegeln Sie sie nach dem Update neu mit dem neuen PCR7-Wert.
    • Nicht betroffen:Das Ablaufen des Zertifikats wirkt sich nicht auf Linux-VMs aus, die keine FDE oder vTPM-versiegelte LUKS-Entschlüsselung verwenden oder für die Secure Boot nicht aktiviert ist.
  • Instanzen mit benutzerdefinierten PK- oder KEK-Konfigurationen:
    • Wann wird es zu einem Faktor? Wenn auf Ihrer Instanz benutzerdefinierte Secure Boot-Variablen (z. B. ein benutzerdefiniertes PK oder KEK) verwendet werden, aber Ihr Bootloader weiterhin mit Standardzertifikaten von Microsoft in der Datenbank (db) signiert wird.
    • Auswirkungen:Ein Standard-Update des db-Zertifikats ist erforderlich, um nachfolgende Bootloader-Updates zu starten, die nur von Microsoft UEFI CA 2023 signiert sind. Da Sie jedoch benutzerdefinierte Schlüssel verwenden, können die Standard-Aktualisierungsdateien (DBUpdate3P2023.bin oder kek2023update.bin) aus der Anleitung von Google nicht angewendet werden. Die UEFI-Firmware prüft die Signatur und erfordert, dass Updates mit dem privaten Schlüssel des KEK (oder PK) signiert werden, der auf dem System vorhanden ist.
    • Abhilfe:Sie müssen die Zertifikatsupdatedateien mit den privaten Schlüsseln signieren, die mit Ihrem benutzerdefinierten PK oder KEK verknüpft sind, bevor Sie sie anwenden. Alternativ können Sie diese Updates über Ihre benutzerdefinierte Zertifizierungsstelle verwalten.
    • Wenn nicht betroffen:Wenn Ihr Bootloader mit Ihrer eigenen benutzerdefinierten Zertifizierungsstelle oder Ihren eigenen benutzerdefinierten Schlüsseln signiert ist (z. B. mit einem benutzerdefinierten db-Zertifikat und nicht mit der ablaufenden Microsoft Corporation UEFI CA 2011), wirkt sich das Ablaufen der Standardzertifikate von Microsoft nicht auf Sie aus und Sie müssen keine Updates durchführen.
  • Instanzen, die auf ein Maschinen-Image von vor November 2025 zurückgesetzt werden:
    • Wann wird es relevant? Wenn Sie eine VM auf ein Maschinen-Image zurücksetzen oder wiederherstellen, das vor dem 7. November 2025 aufgenommen wurde und für das Secure Boot aktiviert ist.
    • Auswirkungen:Bei der zurückgesetzten Instanz wird die ältere UEFI-Firmwarekonfiguration und der Zertifikatspeicher wiederhergestellt, in dem die Zertifikate von 2023 fehlen. Dadurch ist die Instanz anfällig für zukünftige Bootfehler nach nachfolgenden Bootloader-Updates. Sie müssen die Zertifikatsupdates dann noch einmal anwenden.
    • Wenn nicht betroffen:Das Zurücksetzen auf ein Maschinen-Image hat keine Auswirkungen auf die Instanz, wenn Sie Secure Boot deaktivieren oder wenn Sie das Maschinen-Image am oder nach dem 7. November 2025 aus einem Image erstellt haben, das auf den Standardzertifikaten basiert.

Betroffene Compute-Instanzen identifizieren und Update planen

Wir empfehlen Ihnen, im Laufe des Jahres 2026 die betroffenen Compute-Instanzen zu identifizieren und die folgenden Schritte auszuführen, um sich auf das Update vorzubereiten:

  1. Instanzen identifizieren:Mit dem gcloud compute instances list-Befehl können Sie Instanzen identifizieren, für die Secure Boot aktiviert ist und die vor dem Stichtag erstellt wurden:

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

  2. Nach benutzerdefinierten Variablen suchen (optional): Wenn Sie benutzerdefinierte oder importierte Bilder verwenden, prüfen Sie, ob darin benutzerdefinierte db- oder KEK-Variablen für Secure Boot explizit definiert sind (die die Standardeinstellungen vollständig überschreiben). Wenn sie auf Standardzertifikaten basieren, sind keine Maßnahmen auf Image-Ebene erforderlich:

    • Führen Sie Folgendes aus, um eine VM-Instanz zu prüfen:

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

    • Führen Sie Folgendes aus, um ein Quelllaufwerk-Image zu prüfen:

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

    Wenn die Ausgabe leer ist oder null zurückgibt, verwendet die Instanz oder das Image die Standardzertifikate und es sind keine Maßnahmen auf Image-Ebene erforderlich.

  3. Datenintegrität sicherstellen:Sorgen Sie dafür, dass Sie aktuelle Datensicherungen und Zugriff auf die Wiederherstellungsschlüssel für die vollständige Festplattenverschlüsselung (Full Disk Encryption, FDE) oder BitLocker haben, bevor Sie Änderungen vornehmen.

  4. Zertifikate aktualisieren:Aktualisieren Sie DB- und KEK-Zertifikate gemäß der Anleitung zum Aktualisieren von KEK und DB. Alternativ können Sie zu einer Compute-Instanz migrieren, die Sie am oder nach dem 7. November 2025 erstellen und die die Zertifikate von 2023 enthält (vorausgesetzt, die neue Instanz verwendet ein Image, das auf den Standardzertifikaten basiert). Folgen Sie dazu der Anleitung unter Compute-Instanz aus einem Laufwerks-Snapshot neu erstellen.

Compute-Instanz aus einem Laufwerk-Snapshot neu erstellen

Wenn Sie einen Laufwerks-Snapshot erstellen und daraus eine neue Instanz erstellen, erbt die neue Compute-Instanz einen neuen Firmware-Status (vTPM/NVRAM), der den aktualisierten Standardeinstellungen vertraut und alte Zertifikate löscht.

Bevor Sie eine Compute-Instanz aus einem Snapshot neu erstellen, müssen Sie dafür sorgen, dass auf dem Gastbetriebssystem alle erforderlichen Updates installiert sind, damit die Zertifikate von 2023 vertrauenswürdig sind. Das können z. B. die relevanten Microsoft-KBs für Windows oder der aktuelle Shim für Linux-Distributionen sein.

Sie können die Migration mit der folgenden Abfolge von gcloud-Befehlen verwalten:

  1. Bootlaufwerk ermitteln:Ermitteln Sie den Namen des Bootlaufwerks, das an Ihre Quell-Compute-Instanz angehängt ist:

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

  2. Laufwerk-Snapshot erstellen:Erstellen Sie einen Snapshot des Bootlaufwerks. Für eine optimale Datenintegrität sollten Sie die Compute-Instanz beenden, bevor Sie diesen Befehl ausführen:

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

  3. Neue Compute-Instanz erstellen:Stellen Sie eine neue Compute-Instanz bereit und verwenden Sie den Snapshot als Bootquelle. Wenn Secure Boot auf der Quellinstanz aktiviert ist, fügen Sie das Flag --shielded-secure-boot ein, um Secure Boot auf der neuen Instanz zu aktivieren.

    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

Hinweis:Instanzen, die mit diesem Ansatz bereitgestellt werden, erhalten neue interne und externe IP-Adressen, sofern sie nicht statisch zugewiesen und speziell neu zugewiesen werden. Metadaten, Tags und Dienstkonten auf Instanzebene werden nicht automatisch repliziert und müssen beim Neuerstellen explizit konfiguriert werden.

Überprüfung

Nachdem Sie die Firmware und das Betriebssystem für Ihre Compute-Instanzen aktualisiert haben, können Sie prüfen, ob die Zertifikate für 2023 vorhanden sind. Wenn sowohl die Variable KEK als auch die Variable db die Zertifikate für 2023 enthalten, ist Ihre Instanz auf dem neuesten Stand und es sind keine weiteren Maßnahmen erforderlich.

Linux

Sie können die Signaturdatenbanken unter Linux entweder mit dem Befehl efi-readvar aus dem Paket efitools oder (auf Distributionen, auf denen efitools nicht verfügbar ist, z. B. RHEL 8/9) mit mokutil überprüfen.

Methode 1: efi-readvar verwenden

  1. Wenn efi-readvar nicht vorhanden ist, installieren Sie das efitools-Paket. Führen Sie zur Installation unter Linux den Befehl für Ihre Distribution aus:

    Debian/Ubuntu

    sudo apt update && sudo apt install efitools

    RHEL/CentOS/Fedora (nur Fedora; efitools ist in RHEL/CentOS-Repositories nicht verfügbar)

    sudo yum install efitools

    SLES

    sudo zypper install efitools

  2. Prüfen Sie, ob die Zertifikate in den Variablen KEK und db vorhanden sind:

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

Methode 2: mokutil verwenden

Verwenden Sie auf Distributionen wie Red Hat Enterprise Linux (RHEL), auf denen efitools nicht verfügbar ist, das Dienstprogramm mokutil, das standardmäßig installiert ist:

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

Windows (PowerShell)

Führen Sie die folgenden Befehle in einer PowerShell-Eingabeaufforderung mit Administratorrechten aus. Jeder Befehl sollte True zurückgeben.

# 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

Fehlerbehebung

Wenn eine Instanz nach Juni 2026 aufgrund eines Secure Boot-Fehlers nicht gestartet werden kann, versuchen Sie, sie mit einer der folgenden Optionen wiederherzustellen:

  • Secure Boot vorübergehend deaktivieren:So können Sie die Instanz starten, um Updates anzuwenden.

    Führen Sie den folgenden Befehl aus, um Secure Boot zu deaktivieren:

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

    Aktivieren Sie Secure Boot wieder, nachdem Sie die erforderlichen Updates für den Bootloader/Shim angewendet haben:

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

  • Aus Sicherung wiederherstellen:Stellen Sie die Instanz aus einem Maschinen-Image wieder her, das erstellt wurde, bevor die Bootprobleme aufgetreten sind.

  • Instanz neu erstellen:Die Instanz wird neu erstellt und Daten werden aus einem Snapshot wiederhergestellt.

Wenn weiterhin Probleme auftreten oder Sie Hilfe benötigen, wenden Sie sich an Cloud Customer Care.

FAQ

In diesem Abschnitt finden Sie Antworten auf häufig gestellte Fragen zum Ablauf des Microsoft Secure Boot-Zertifikats.

Wann laufen Secure Boot-Zertifikate ab?

Die Secure Boot-Zertifikate von Microsoft laufen 2026 ab. Zum Beispiel:

  • Die beiden kritischsten Zertifikate, deren Ablaufdatum sich nähert, sind die Microsoft Corporation UEFI CA 2011 (läuft im Juni 2026 ab), mit der Drittanbieter-Bootloader wie der Linux-Shim signiert werden, und die Microsoft Windows Production PCA 2011, die im Oktober 2026 abläuft und mit der der Windows-Bootloader signiert wird.

Wen betrifft der Ablauf des Zertifikats?

Das Ablaufen dieses Zertifikats betrifft Sie nur, wenn Ihre Compute-Instanz die beiden folgenden obligatorischen Voraussetzungen erfüllt:

  1. Sie haben die Instanz vor dem 7. November 2025 erstellt, als Compute Engine die standardmäßigen Secure Boot-Zertifikate in der UEFI-Firmware aktualisiert hat, und Sie haben sie nicht aktualisiert.
  2. Sie haben Secure Boot auf der Instanz aktiviert.

Instanzen, die Sie am oder nach dem 7. November 2025 erstellen, sind nicht betroffen, sofern Sie sie aus einem Image erstellen, das auf dem Standardzertifikatsatz basiert.

Wenn Ihre Instanz beide Voraussetzungen erfüllt, wirkt sich der Zertifikatsablauf unter bestimmten Umständen auf die folgenden Konfigurationen aus:

  • vTPM-PCR-Secret-Sealing:Wenn die Instanz Platform Configuration Registers (PCRs) des Virtual Trusted Platform Module (vTPM) (insbesondere PCR7) verwendet, um Verschlüsselungsschlüssel oder Secrets zu versiegeln.
  • Windows BitLocker / VSM:Wenn auf Ihrer Windows-Instanz die BitLocker-Festplattenverschlüsselung oder der Virtual Secure Mode (VSM) mit Secure Boot verwendet wird.
  • Linux-FDE:Wenn Ihre Linux-Instanz FDE verwendet, die Sie an vTPM-PCRs (insbesondere PCR7) binden.
  • Rollback-Instanzen:Wenn Sie die VM auf ein Maschinen-Image zurücksetzen oder wiederherstellen, das Sie vor dem 7. November 2025 erstellt haben.

Eine detaillierte Aufschlüsselung der Auswirkungen und der Schritte zur Fehlerbehebung für jede dieser Konfigurationen finden Sie unter Auswirkungen auf bestimmte Gastkonfigurationen.

Wer ist vom Ablauf des Zertifikats nicht betroffen?

Das Ablaufen des Zertifikats hat keine Auswirkungen auf Sie, wenn einer der folgenden Fälle zutrifft:

  • Secure Boot ist deaktiviert:Wenn Secure Boot auf Ihrer Shielded VM-Instanz nicht aktiviert ist, werden die ablaufenden UEFI-Zertifikate nicht validiert oder verwendet. Secure Boot ist standardmäßig deaktiviert. Wenn Sie jedoch vTPM-Plattformkonfigurationsregister (insbesondere PCR7) für das Versiegeln von Secrets verwenden, werden alle Aktualisierungen von UEFI-Variablen oder das Neuerstellen der Instanz die PCR7-Messungen auch bei deaktiviertem Secure Boot ändern. Solche Konfigurationen sind jedoch sehr selten.
  • Erstellt am oder nach dem 7. November 2025:Sie haben die Instanz an oder nach diesem Datum erstellt. Die Firmware enthält also bereits die aktualisierten Zertifikate von 2023, sofern Sie sie aus einem Image erstellt haben, das auf dem Standardzertifikatsatz basiert.
  • Container-Optimized OS (COS) wird ausgeführt: Diese Zertifikatsaktualisierungen haben keine Auswirkungen auf COS-Umgebungen.

  • Benutzerdefinierte PK-, KEK- oder db-Variablen:Wenn Sie Ihre eigenen benutzerdefinierten Secure Boot-Variablen PK, KEK oder db explizit definieren und verwalten, ohne auf die standardmäßigen Microsoft-UEFI-Zertifikate zurückzugreifen (z. B. wenn Ihr Bootloader mit Ihrem eigenen benutzerdefinierten db-Zertifikat anstelle der ablaufenden Microsoft Corporation UEFI CA 2011 signiert ist), wirkt sich das Ablaufen von Standardzertifikaten nicht auf Sie aus.

    Wenn Ihre benutzerdefinierte Konfiguration weiterhin auf das ablaufende Microsoft-Zertifikat angewiesen ist, um Ihren Bootloader zu signieren, sind Sie vom Ablauf betroffen. Da Sie jedoch einen benutzerdefinierten PK oder KEK verwenden, schlagen die in dieser Anleitung bereitgestellten Standard-Aktualisierungsdateien (DBUpdate3P2023.bin oder kek2023update.bin) fehl, da UEFI erfordert, dass Aktualisierungen mit dem privaten Schlüssel des KEK (oder PK) signiert werden, der auf dem System vorhanden ist. Sie müssen die Zertifikatsupdatedateien mit den privaten Schlüsseln Ihres benutzerdefinierten PK oder KEK signieren, um sie anzuwenden.

Wirkt sich das Ablaufdatum auf Managed Service for Apache Spark (ehemals Dataproc), Dataflow oder Vertex AI Workbench-Instanzen aus?

Das Ablaufen dieses Zertifikats hat keine Auswirkungen auf Dataflow, da die zugehörigen Instanzen standardmäßig unter Container-Optimized OS (COS) ausgeführt werden. Diese Zertifikatsaktualisierungen haben keine Auswirkungen auf COS-Umgebungen.

Bei Managed Service for Apache Spark-Instanzen (ehemals Dataproc) und Vertex AI Workbench-Instanzen betrifft dieser Ablauf nur Instanzen, die beide der folgenden obligatorischen Voraussetzungen erfüllen:

  1. Sie haben die Instanzen vor dem 7. November 2025 erstellt.
  2. Sie haben Secure Boot auf den Instanzen aktiviert. Bei diesen Diensten ist Secure Boot nicht standardmäßig aktiviert.

Wenn Ihre Instanzen beide Voraussetzungen erfüllen, wirkt sich der Zertifikatsablauf auf sie aus. Es gibt jedoch keine unmittelbaren Auswirkungen, da Betriebssystemanbieter in absehbarer Zukunft planen, Bootloader- und Shim-Updates doppelt zu signieren. Ihre Instanzen sind davon nicht betroffen, es sei denn, Sie installieren ein zukünftiges Update, das nur mit dem Zertifikat von 2023 signiert ist.

Was passiert, wenn ich nichts unternehme?

Wenn Sie nichts unternehmen, wird Ihre Instanz weiterhin mit den vorhandenen Binärdateien gestartet und funktioniert wie gewohnt. Es kann jedoch sein, dass Sie zukünftige Bootloader- oder Kernel-Updates, die Binärdateien enthalten, die nur mit dem Zertifikat von 2023 signiert sind, nicht anwenden können. Da Betriebssystemanbieter Bootloader- und Shim-Updates sowohl mit den Zertifikaten von 2011 als auch von 2023 dual signieren, sind Bootfehler oder Update-Blockierungen nicht sofort zu erwarten.

Wird das Starten von Windows-Instanzen verhindert, wenn Zertifikate nicht aktualisiert werden?

Nein. Wenn Sie das Problem nicht beheben, wird der Windows-Systemstart nicht verhindert. Möglicherweise wird jedoch die Ereignis-ID 1801 („Secure Boot CA/keys need to be updated“) im Systemereignisprotokoll angezeigt und Sie können keine neuen Kernel- oder Bootloader-Sicherheitsupdates anwenden, die Binärdateien enthalten, die nur mit dem neuen Zertifikat von 2023 signiert sind.

Unter welchen spezifischen Bedingungen treten Bootfehler unter Linux auf?

Unter bestimmten Bedingungen kann es unter Linux zu einem Bootfehler kommen:

  • Auf der Instanz ist Secure Boot aktiviert.
  • Die UEFI-Variable „db“ wird nicht aktualisiert, um dem Zertifikat „Microsoft UEFI CA 2023“ zu vertrauen.
  • Das Betriebssystem aktualisiert einen Bootloader (oder Shim), der ausschließlich auf diesem Zertifikat basiert (und nicht mit dem Zertifikat von 2011 dual signiert ist).

Wenn Sie keine Zertifikats- oder Shim-Updates anwenden, die auf die neuen Zertifikate verweisen, wird Ihre Linux-Instanz weiterhin erfolgreich gestartet.

Wie finde ich heraus, ob meine Instanz die aktualisierten Zertifikate hat?

Ob Ihre Instanz die neuen Zertifikate in ihrer Firmware enthält, können Sie anhand der Befehle im Abschnitt Bestätigung ermitteln. Wenn Zertifikate fehlen, können Sie sie aktualisieren, indem Sie der Anleitung zum Aktualisieren von KEK und Datenbank folgen, oder die Instanz neu erstellen.

Kann das Problem durch einen Neustart oder Reboot einer betroffenen Instanz behoben werden?

Nein. Beim Neustarten oder Rebooten einer Compute-Instanz werden die Secure Boot-Zertifikate nicht aktualisiert. Die Instanz wird jedoch weiterhin normal mit den vorhandenen Zertifikaten gestartet und ausgeführt, bis ein Bootloader- oder Kernel-Update angewendet wird, das Binärdateien enthält, die nur mit dem Zertifikat von 2023 signiert sind. Wenn Sie die Compute-Instanz neu starten, behält sie die alten Zertifikate bei, sofern sie ursprünglich vor dem 7. November 2025 erstellt wurde. Die Zertifikate sind Teil der Firmware der Instanz (vTPM/NVRAM). Daher müssen Sie der Anleitung zum Aktualisieren von KEK und Datenbank folgen oder die Instanz neu erstellen, um die neuen Zertifikate anzuwenden.

Wie kann ich mich auf den Ablauf des Zertifikats vorbereiten?

So bereiten Sie sich vor:

  • Identifizieren:Prüfen Sie Ihre Nutzung von Shielded VMs, Secure Boot, FDE, BitLocker oder Software, die auf vTPM-PCRs basiert.
  • Wiederherstellungsschlüssel und Back-ups:Sorgen Sie für die sofortige Verfügbarkeit von Wiederherstellungsschlüsseln (für FDE/BitLocker) und aktuellen Datensicherungen.
  • Images verwalten:Identifizieren Sie benutzerdefinierte Legacy-Images und stellen Sie die Verwendung ein oder sorgen Sie dafür, dass sie die neuen Zertifikate enthalten.
  • Aktualisieren oder migrieren:Wenn Sie Zertifikate aktualisieren möchten, lesen Sie den Leitfaden zum Aktualisieren von KEK und Datenbank. Alternativ können Sie alle Compute-Instanzen, die Sie vor dem 7. November 2025 erstellt haben, neu erstellen. Neue Instanzen enthalten bereits die erforderlichen Zertifikate, sofern Sie die neue Instanz aus einem Image erstellen, das auf den Standardzertifikaten basiert.

Standard-Laufwerk-Snapshots sind die zuverlässigste Methode. Ein Snapshot ist eine Kopie des Laufwerks auf Blockebene und enthält keine UEFI-Variablen oder Metadaten auf Instanzebene. So stellen Sie Daten mithilfe eines Snapshots wieder her:

  1. Erstellen Sie einen Snapshot des Bootlaufwerks der Instanz.
  2. Erstellen Sie eine neue Compute-Instanz und wählen Sie den Snapshot als Quelle für das Bootlaufwerk aus.

Sie sollten für diese Migration keine Maschinen-Images, kein Instanzklonen und keine Sicherungen des Backup and DR Service verwenden, da sie die Instanz-Firmware replizieren und die alten Zertifikate für alle vor dem 7. November 2025 erstellten Quell-Compute-Instanzen beibehalten.

Was soll ich tun, wenn mein System nach Juni 2026 nicht mehr startet?

Wenn Sie der Meinung sind, dass dieses Problem einen Startfehler verursacht hat, lesen Sie den Abschnitt Fehlerbehebung.

Wie wird Google Cloud mit dem Ablauf der Microsoft Secure Boot-Zertifikate umgehen?

Google Cloud automatisch die neuen Zertifikate für Compute-Instanzen enthalten, die nach dem 7. November 2025 erstellt wurden. Nur Kunden, die ihre Compute-Instanzen, die vor dem 7. November 2025 erstellt wurden, weiterhin ausführen möchten, müssen möglicherweise ein zukünftiges Update anwenden. Wir empfehlen jedoch, zu einer Instanz zu migrieren, die am oder nach dem 7. November 2025 erstellt wurde (mit Standardzertifikaten).

Nächste Schritte