Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Leitfaden zum Ablauf von Microsoft Secure Boot-Zertifikaten

Da einige der Secure Boot-Zertifikate von Microsoft 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, 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 (läuft am 19. Oktober 2026 ab), 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.

Secure Boot-Zertifikate und Ablaufdaten

Name des Zertifikats	Rolle	Ablaufdatum
Microsoft Corporation UEFI CA 2011	Signiert Bootloader von Drittanbietern (z. B. 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

Wenn Sie Secure Boot auf Compute Engine-Instanzen verwenden, die vor dem 7. November 2025 erstellt wurden, und weiterhin Firmware-Updates erhalten möchten, um potenzielle Bootprobleme in der Zukunft zu vermeiden, installieren Sie aktualisierte Zertifikate. In diesem Dokument wird beschrieben, wie Sie betroffene Instanzen identifizieren und die erforderlichen Updates durchführen.

Die Einführung der neuen Zertifikate wurde am 7. November 2025 abgeschlossen. Instanzen, die an oder nach diesem Datum erstellt wurden, enthalten die aktualisierten Zertifikate und erfordern keine weiteren Maßnahmen. Einige Instanzen, die in den Wochen vor diesem Datum erstellt wurden, 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, die keine vTPM-Plattformkonfigurationsregister (Platform Configuration Registers, PCRs) für das Versiegeln von Secrets verwenden und für die Secure Boot nicht aktiviert ist. Secure Boot ist beim Erstellen einer Shielded VM-Instanz nicht standardmäßig aktiviert.
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 beendet 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 nach einem Update, das einen Bootloader enthält, der nur mit dem Microsoft UEFI CA 2023-Zertifikat signiert ist, zu Bootproblemen bei der Compute-Instanz kommen. Wenn Sie nichts unternehmen, können Sie möglicherweise keine neuen Bootloader- oder Kernel-Updates anwenden, die Binärdateien enthalten, die nur mit dem Zertifikat von 2023 signiert sind. Dadurch sind Systeme möglicherweise anfälliger für bestimmte Angriffe. Für Compute-Instanzen, die vor dem 7. November 2025 erstellt wurden: Wenn Sie die Zertifikatsaktualisierungen nicht vor Mitte 2026 anwenden, sehen Windows-Kunden möglicherweise die Ereignis-ID 1801 („Secure Boot CA/keys need to be updated“) im Systemereignislog.

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:Wir empfehlen, dass Sie dafür sorgen, dass Instanzen, die mit Ihren Images erstellt werden, dem Microsoft UEFI CA 2023-Zertifikat vertrauen. Wenn Ihr Image eingebettete Zertifikate enthält, die nicht das Microsoft UEFI CA 2023-Zertifikat enthalten, können Sie Ihr Image aktualisieren, indem Sie die entsprechenden Zertifikate bereitstellen, oder Sie können es neu erstellen. Wenn Sie Ihr Image neu erstellen möchten, beginnen Sie mit einem von Google bereitgestellten Basis-Image und wenden Sie Ihre Anpassungen noch einmal an. Von Google bereitgestellte Images enthalten keine eingebetteten Zertifikate. Compute Engine stellt die aktualisierten Zertifikate daher bereit, wenn Sie eine Instanz aus einem solchen Image erstellen.

Empfohlene Maßnahmen

Wenn Sie Compute-Instanzen haben, die vor dem 7. November 2025 mit aktiviertem Secure Boot erstellt wurden oder Software zur vollständigen Festplattenverschlüsselung (Full Disk Encryption, FDE) verwenden (einschließlich BitLocker unter Windows und anderer FDE unter Linux), Virtual Secure Mode (VSM) unter Windows oder vTPM-Plattformkonfigurationsregister (Platform Configuration Registers, PCRs) zum Versiegeln von Geheimnissen, sollten Sie die in den folgenden Abschnitten beschriebenen Maßnahmen ergreifen. Diese Anleitung gilt auch, wenn Sie ein Rollback zu einem Maschinen-Image vor dem 7. November 2025 durchführen.

Betroffene Compute-Instanzen identifizieren und Update planen

Wir empfehlen Ihnen, bis zum 24. Juni 2026 die betroffenen Compute-Instanzen zu identifizieren und die folgenden Schritte auszuführen, um sich auf das Update vorzubereiten:

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,shieldedInstanceConfig.enableIntegrityMonitoring:label=INTEGRITY_MONITORING)"

Datenintegrität sicherstellen:Sorgen Sie dafür, dass Sie aktuelle Datensicherungen und Zugriff auf alle FDE- oder BitLocker-Wiederherstellungsschlüssel haben, bevor Sie Änderungen vornehmen.
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 am oder nach dem 7. November 2025 erstellt wurde und die Zertifikate von 2023 enthält. Folgen Sie dazu der Anleitung unter Compute-Instanz aus einem Laufwerk-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. relevante 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:

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())")

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
```
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

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
```
sudo yum install efitools
```
SLES
```
sudo zypper install efitools
```

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"

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 Secure Boot deaktivieren, ändern sich die PCR-Werte (insbesondere PCR7). Dies kann sich auf die Funktionen für das Versiegeln von vertraulichen Daten oder die 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
```
Wenden Sie nach dem Starten der Instanz die erforderlichen Betriebssystem- und Bootkomponenten-Updates an und aktivieren Sie dann Secure Boot wieder:
```
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, die bald ablaufen, sind die Microsoft Corporation UEFI CA 2011 (läuft im Juni 2026 ab), mit der Bootloader von Drittanbietern (z. B. der Linux-Shim) signiert werden, und die Microsoft Windows Production PCA 2011 (läuft im Oktober 2026 ab), mit der der Windows-Bootloader signiert wird.

Betrifft das Ablaufdatum sowohl Windows- als auch Linux-Kunden?

Ja, das Ablaufdatum betrifft sowohl Windows- als auch Linux-Kunden.

Wen betrifft der Ablauf des Zertifikats?

Dieses Problem betrifft möglicherweise nur Kunden mit Compute-Instanzen, die vor dem 7. November 2025 erstellt wurden und lange ausgeführt werden. Folgende Instanzen sind betroffen:

Linux- und Windows-VMs mit aktiviertem Secure Boot.
Alle Instanzen, die PCRs (Platform Configuration Registers) des Virtual Trusted Platform Module (vTPM) für das Versiegeln von Geheimnissen verwenden.
Windows-Compute-Instanzen, die Festplattenverschlüsselung (BitLocker) oder den virtuellen sicheren Modus (Virtual Secure Mode, VSM) verwenden.
Linux-VMs, die FDE verwenden.
Instanzen, die auf ein Maschinen-Image vor November 2025 zurückgesetzt werden.

Wer ist nicht vom Ablauf des Zertifikats betroffen?

Sie sind nicht betroffen, wenn Sie in eine der folgenden Kategorien fallen:

Sie verwenden weder Secure Boot noch die Versiegelung von Secrets in vTPM-PCRs oder die vollständige Festplattenverschlüsselung (einschließlich BitLocker).
Sie verwenden Container-Optimized OS-Linux-Instanzen (COS).
Sie stellen Ihren eigenen Plattformschlüssel (PK) oder Schlüsselregistrierungsschlüssel (KEK) bereit. Wenn Sie Ihren eigenen PK oder KEK verwenden, verwendet Compute Engine Ihre benutzerdefinierten Schlüssel. Das Ablaufdatum der Standardzertifikate hat dann keine Auswirkungen auf Sie. Sie sind jedoch dafür verantwortlich, Ihre eigenen Schlüssel zu verwalten und dafür zu sorgen, dass Ihre Zertifikate auf dem neuesten Stand sind.

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 keine neuen Bootloader- oder Kernel-Updates anwenden können, die Binärdateien enthalten, die nur mit dem Zertifikat von 2023 signiert sind. Dadurch sind Systeme möglicherweise anfälliger für bestimmte Angriffe. Wenn Sie für Compute-Instanzen, die vor dem 7. November 2025 erstellt wurden, keine Zertifikatsaktualisierungen vor Mitte 2026 vornehmen, sehen Windows-Kunden möglicherweise die Ereignis-ID 1801 („Secure Boot CA/keys need to be updated“) im Systemereignislog.

Wird verhindert, dass Windows-Instanzen gestartet werden, wenn Zertifikate nicht aktualisiert werden?

Nein. Wenn Sie das Problem nicht beheben, wird der Windows-Systemstart nicht verhindert. Möglicherweise sehen Sie jedoch die Ereignis-ID 1801 („Secure Boot CA/keys need to be updated“) im Systemereignisprotokoll und 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 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.

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 feststellen. 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, anstatt die Instanz neu zu erstellen, lesen Sie den Leitfaden zum Aktualisieren von KEK und Datenbank. Alternativ können Sie alle Compute-Instanzen mit langer Laufzeit, die vor dem 7. November 2025 erstellt wurden, neu erstellen, da die erforderlichen Zertifikate bereits in neuen Instanzen enthalten sind.

Welche Methoden werden empfohlen, um betroffene Instanzen neu zu erstellen oder zu migrieren?

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:

Erstellen Sie einen Snapshot des Bootlaufwerks der Instanz.
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.