Leitfaden zum Ablauf von Microsoft Secure Boot-Zertifikaten

Da mehrere Microsoft Secure Boot-Zertifikate im Jahr 2026 ablaufen, enthält dieses Dokument eine Anleitung dazu, wie Sie Compute Engine-Shielded VM-Instanzen aktualisieren, damit sie den aktualisierten Microsoft Secure Boot-Zertifikaten für UEFI (Unified Extensible Firmware Interface) Secure Boot vertrauen. Die beiden kritischsten Zertifikate, die bald ablaufen, 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.

Secure Boot-Zertifikate und Ablaufdaten

Name des Zertifikats Rolle Ablaufdatum
Microsoft Corporation UEFI CA 2011 Signiert Bootloader von Drittanbietern 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 verwendet, um die DB und DBX zu aktualisieren. 24. Juni 2026

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 Ablauf des Zertifikats 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 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 und 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. Beachten Sie, dass bei Verwendung von vTPM-Plattformkonfigurationsregistern (insbesondere PCR7) für das Versiegeln von Secrets Aktualisierungen von UEFI-Variablen oder das Neuerstellen der Instanz weiterhin PCR7-Messungen ändern, 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 Ihren eigenen Secure Boot-Plattformschlüssel (PK) oder Schlüsselregistrierungsschlüssel (KEK) bereitstellen.

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 dies 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 der Zertifizierungsstelle dieses Zertifikats nicht vertraut, 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 kann es bei der Compute-Instanz zu Startproblemen kommen, 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 Bootloader- und Shim-Updates in absehbarer Zukunft sowohl mit den Zertifikaten von 2011 als auch mit denen von 2023 dual signieren möchten, 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-Build-Prozesses 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 Standardwerte 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 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 erschwerende Faktoren:
    • Anforderung für die Aktualisierungsreihenfolge:Damit keine Fehler bei der CA-Überprüfung und keine Boot-Schleifen auftreten, 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 Legacy-Maschinenimage 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 Zertifikatsupdates 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 folgenden Informationen zur Zertifikatsablaufzeit gelten nur, 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 Start. 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 Geheimnisversiegelung 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 verwenden.
    • 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.
    • Abhilfe:Sie müssen prüfen, ob Sie Ihre BitLocker-Wiederherstellungsschlüssel verfügbar haben, bevor Sie Zertifikate aktualisieren oder Instanzen migrieren. Folgen Sie danach 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 der sichere Start nicht aktiviert ist.
  • Instanzen, die auf ein Maschinen-Image vor November 2025 zurückgesetzt werden:
    • Wann wird es zu einem Faktor? Wenn Sie eine VM auf ein Maschinen-Image zurücksetzen oder ein Rollback durchführen, 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 Images 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, z. B. die relevanten Microsoft-KBs für Windows oder der aktuelle Shim für Linux-Distributionen, damit die Zertifikate von 2023 vertrauenswürdig sind.

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

  1. Bootlaufwerk identifizieren: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, indem Sie den Snapshot als Bootquelle verwenden. 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 den Befehl für Ihre Distribution aus, um die Software unter Linux zu installieren:

    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 standardmäßig installierte Dienstprogramm mokutil:

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.

    Hinweis:Wenn Sie den sicheren Start deaktivieren, ändern sich die PCR-Werte, insbesondere PCR7. Dies kann sich auf die Funktionen zum Versiegeln von vertraulichen Daten oder zur Festplattenverschlüsselung auswirken.

    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 Lebenszyklus bald endet, 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 nicht vom Ablauf des Zertifikats betroffen?

Der Ablauf 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, wirkt sich das Ablaufen von Standardzertifikaten nicht auf Sie aus. Sie sind jedoch für die Aktualisierung und Verwaltung Ihrer eigenen Zertifikate verantwortlich.

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.

Kann es passieren, dass Windows-Instanzen nicht mehr gestartet werden, 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 Umständen 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.
  • Bilder 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 keinen Backup and DR-Dienst verwenden, da dadurch die Instanz-Firmware repliziert und die alten Zertifikate für alle vor dem 7. November 2025 erstellten Quell-Compute-Instanzen beibehalten werden.

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 bei Google Cloud der Ablauf der Microsoft Secure Boot-Zertifikate behandelt?

Google Cloud automatisch die neuen Zertifikate für Compute-Instanzen einbezogen, 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