Microsoft セキュアブート証明書の有効期限ガイド

複数の Microsoft セキュアブート証明書が 2026 年に期限切れになるため、このドキュメントでは、UEFI（Unified Extensible Firmware Interface）セキュアブート用に更新された Microsoft セキュアブート証明書を信頼するように Compute Engine Shielded VM インスタンスを更新する方法について説明します。有効期限が近づいている最も重要な 2 つの証明書は、Linux Shim などのサードパーティ製ブートローダーに署名する Microsoft Corporation UEFI CA 2011（2026 年 6 月 27 日に有効期限切れ）と、Windows ブートローダーに署名する Microsoft Windows Production PCA 2011（2026 年 10 月 19 日に有効期限切れ）です。

UEFI セキュアブートは、Shielded VM が VM 起動プロセス中に信頼できるソフトウェアとファームウェアのみが実行されるようにするために使用するセキュリティ標準です。さまざまなオペレーティング システムでセキュアブートをサポートするため、Microsoft は UEFI 証明書を管理し、インスタンス ファームウェア内の Key Exchange Key（KEK）変数と Allowed Signature Database（db）変数に保存します。

Backup and DR サービス ユーザーに関する考慮事項

Backup and DR Service はマネージド サービスであるため、アプライアンスの基盤となるオペレーティング システムとセキュアブート証明書の更新を自動的に管理します。 Google Cloud お客様側での対応は必要ありません。既存のアプライアンスは引き続き正常に起動して機能し、デプロイする新しいアプライアンスには更新されたセキュアブート証明書が自動的に含まれます。

セキュアブートの証明書と有効期限

証明書名 ロール 有効期限
Microsoft Corporation UEFI CA 2011 Linux Shim などのサードパーティ製ブートローダーに署名する 2026 年 6 月 27 日
Microsoft Windows Production PCA 2011 Windows ブートローダーに署名する 2026 年 10 月 19 日
Microsoft Corporation KEK CA 2011 DB と DBX の更新に使用されます 2026 年 6 月 24 日

この証明書の有効期限切れは、コンピューティング インスタンスが次の両方の必須前提条件を満たしている場合にのみ影響します。

  1. 作成日: 2025 年 11 月 7 日（Compute Engine が UEFI ファームウェアのデフォルトのセキュアブート証明書を更新した日）より前にコンピューティング インスタンスを作成し、更新していない。
  2. セキュアブートの状態: インスタンスでセキュアブートを有効にしました。Shielded VM インスタンスを作成するとき、 Google Cloud はデフォルトでセキュアブートを有効にしません。

2025 年 11 月 7 日以降に作成するインスタンスでは、デフォルトの証明書セットに依存するイメージを使用している場合、ファームウェア変数に更新された証明書がすでに含まれています。

インスタンスが両方の前提条件を満たしていない場合、証明書の有効期限は影響しないため、対応は不要です。

このドキュメントでは、影響を受けるインスタンスを特定し、必要な更新を行う方法について説明します。

Google Cloud 2025 年 11 月 7 日に新しい証明書のロールアウトを完了しました。この日付以降に、デフォルトの証明書セットに依存するイメージから作成したインスタンスには、更新された証明書が NVRAM/ファームウェア変数（db と KEK）に含まれており、追加の操作は必要ありません。ただし、この日付の数週間前に作成したインスタンスにも新しい証明書が含まれている場合があります。システムが最新かどうかを確認するには、このドキュメントの確認セクションのコマンドを使用します。

注: セキュアブート証明書の有効期限が切れても、次のものには影響しません。

  • セキュアブートが有効になっていないインスタンス。シークレット シーリングに vTPM プラットフォーム構成レジスタ（特に PCR7）を使用する場合、セキュアブートが無効になっていても、UEFI 変数の更新やインスタンスの再作成によって PCR7 の測定値が変更されます。ただし、このような構成は非常にまれです。
  • Container-Optimized OS（COS）を実行しているインスタンス。
  • カスタム セキュアブート変数（カスタム PK、KEK、db など）を使用し、ブートローダーが期限切れになる Microsoft Corporation UEFI CA 2011 ではなく、独自のカスタム証明書を使用して署名されているインスタンス。カスタム鍵を使用しているが、期限切れの Microsoft CA に依存してブートローダーに署名している場合は、鍵の更新要件についてカスタム PK または KEK 構成のインスタンスをご覧ください。
  • Google Cloud バックアップと DR アプライアンス。これらは管理対象アプライアンスです。証明書の有効期限が切れてもアプライアンスの動作に影響はなく、手動で更新する必要もありません。 Google Cloudはすべての証明書の更新を自動的に管理します。

2025 年 11 月 7 日より前に作成されたコンピューティング インスタンスで、更新された証明書がない場合は、KEK と DB の更新ガイドに沿って証明書を更新します。何らかの理由で更新できない場合は、インスタンスの再作成を検討してください。

セキュアブート証明書の有効期限が Shielded VM に与える影響

有効にすると、Shielded VM は UEFI ファームウェアを使用してセキュアブートを適用します。これにより、ブート シーケンス バイナリの署名を検証するための一連の信頼できる証明書（db 変数内）が維持されます。たとえば、OS の更新によってブートローダーが Microsoft UEFI CA 2023 によってのみ署名されたものに置き換えられ、コンピューティング インスタンスのファームウェアがこの証明書の認証局を信頼していない場合、セキュアブートの検証が失敗し、セキュアブートがブートプロセスを停止します。

この移行について詳しくは、Microsoft や他の OS ベンダーのガイダンスをご覧ください。

オペレーティング システムへの影響

2025 年 11 月 7 日より前に作成された Shielded VM インスタンスでセキュアブートを有効にしている場合は、2023 年の証明書がインストールされていることを確認することをおすすめします。そうしないと、Microsoft UEFI CA 2023 証明書のみで署名されたブートローダー（2011 年の証明書とのデュアル署名ではない）を含む更新プログラムを適用すると、コンピューティング インスタンスで起動の問題が発生します。対応しない場合、2023 年の証明書のみで署名されたバイナリを含むブートローダーやカーネルのアップデートを適用できなくなる可能性があります。OS ベンダーは、当面の間、2011 年と 2023 年の両方の証明書でブートローダーと shim のアップデートにデュアル署名する予定であるため、ブートの失敗やアップデートのブロックが直ちに発生することはありません。2025 年 11 月 7 日より前に作成されたコンピューティング インスタンスの場合: 証明書の更新を適用していない場合、Windows のお客様はシステム イベント ログにイベント ID 1801（「セキュアブートの CA/鍵を更新する必要があります」）が表示されることがあります。

  • Google 提供の公開イメージ: KEK と DB の更新ガイドに沿って、DB 証明書と KEK 証明書を更新します。または、2025 年 11 月 7 日より前に作成された、長時間実行されている VM を再作成することを検討してください。

  • カスタム イメージまたはインポートされたイメージ: カスタム イメージまたはインポートされたイメージの大部分は、デフォルトのセキュアブート証明書に依存しています。イメージの作成時に db または KEK セキュアブート変数を明示的にオーバーライドしなかった場合、イメージはデフォルトの鍵セットを使用し、イメージレベルでの操作は必要ありません。これらのデフォルトに依存するイメージからインスタンスを作成すると、Compute Engine は更新された証明書を自動的に提供します。

    イメージのビルド プロセス中に、カスタムの db または KEK セキュア ブート変数（デフォルトの Microsoft 証明書とともにサードパーティのセキュリティ ベンダーの証明書を含めるなど）をイメージ メタデータで明示的に定義した場合にのみ、対応が必要です。カスタムの db または KEK 変数を指定すると、デフォルトが完全にオーバーライドされ（システムはデフォルトの公開鍵を無視します）、カスタム変数に更新された「Microsoft UEFI CA 2023」または 2023 KEK 証明書が含まれていない可能性があります。カスタム イメージ構成でこれらの更新された証明書が除外されている場合は、Shielded イメージを再作成または更新して、これらの証明書を含める必要があります。手順については、カスタム Shielded VM イメージの作成をご覧ください。

2025 年 11 月 7 日より前に作成されたセキュアブートが有効になっているコンピューティング インスタンスがある場合は、更新パスを計画する前に、次の要件、制限事項、複雑な要因を確認してください。

  • 更新前の要件:
    • 復元キーへのアクセスを確認する: インスタンスで FDE（Windows の BitLocker や Linux の LUKS など）を使用している場合は、証明書の更新やインスタンスの再作成を行う前に、復元キーにアクセスできることを確認する必要があります。UEFI 変数を変更すると、ブート測定が変更され、復元プロンプトがトリガーされます。
    • vTPM シークレットを管理する: インスタンスがシークレット シーリングに vTPM プラットフォーム構成レジスタ（特に PCR7）を使用している場合は、更新前にこれらのシークレットをアンシールまたはバックアップして、アクセスが永久に失われるのを防ぐ必要があります。
  • 複雑化の要因と境界:
    • 更新順序の要件: CA 検証の失敗やシステムのブートループを防ぐため、新しいカーネルまたは shim の更新を適用する前に、新しい db 証明書と KEK 証明書をインストールする必要があります。
    • ファームウェアのロールバック: 2025 年 11 月 7 日より前にキャプチャされた以前のマシンイメージにインスタンスを復元すると、古いファームウェアが復元され、2023 年の証明書の信頼が削除されます。ロールバックする場合は、証明書の更新を再度適用する必要があります。

タイムライン、監査手順、移行プロセスの詳細な内訳については、以下の手順をご覧ください。

特定のゲスト構成への影響

インスタンスが両方の必須前提条件（2025 年 11 月 7 日より前に作成され、セキュアブートが有効になっている）を満たしている場合にのみ、証明書の有効期限が各構成に及ぼす影響を理解します。

  • vTPM PCR シークレット シーリング:
    • 影響を受ける場合: vTPM プラットフォーム構成レジスタ（特に PCR7）を使用して、復号鍵などのシークレットを封印する場合。
    • 影響: セキュアブート証明書を更新すると（KEK と db の更新ガイドを使用するか、ディスク スナップショットからインスタンスを再作成する）、UEFI 変数が変更され、次の起動時に PCR7 測定値が変更されます。この変更により、更新前にシークレットを封印解除またはバックアップしてから、新しい PCR7 値に再封印しない限り、ゲスト OS またはアプリケーションがこれらのシークレットを封印解除または復号化できなくなります。
    • 影響を受けない場合: 2025 年 11 月 7 日以降にデフォルトの証明書に依存するイメージから VM を作成した場合、証明書を更新する必要はありません。PCR7 は変更されず、シークレット シーリングは正常に動作します。
  • BitLocker または仮想セキュアモード（VSM）を使用している Windows コンピューティング インスタンス:
    • 要因となる場合: Windows VM で BitLocker フルディスク暗号化または VSM を使用している場合。どちらも UEFI セキュアブートと PCR7 を信頼して暗号鍵を封印します。
    • 影響: UEFI セキュアブート証明書を変更するか、スナップショットからインスタンスを再作成すると、PCR7 ブート測定値が変更されます。再起動すると、BitLocker は構成の変更を検出し、キーの自動リリースに失敗して、復元キーを要求する BitLocker 復元画面が起動します。
    • 修復: 証明書を更新する前、またはインスタンスを移行する前に、BitLocker 復元キーが使用可能であることを確認する必要があります。その後、Windows で db と KEK を更新するのガイダンスに従います。
    • 影響を受けない場合: 証明書の有効期限切れは、BitLocker または VSM が有効になっていない Windows インスタンス、またはセキュアブートが有効になっていない Windows インスタンスには影響しません。
  • FDE を使用する Linux VM:
    • 要因となる場合: Linux インスタンスで LUKS などの FDE を使用し、復号鍵を vTPM PCR（特に PCR7）に封印する場合。
    • 影響: セキュアブート証明書を更新するか、VM を再作成すると PCR7 が変更され、ブート ボリュームの自動復号が防止されます。起動中にシステムが停止し、復号パスフレーズの入力を求められます。
    • 修復: アップデートを実行する前に、復元パスフレーズまたは復元キーがあることを確認します。更新前に LUKS 鍵を TPM からバインド解除または封印解除し、更新完了後に新しい PCR7 値にバインドまたは封印し直します。
    • 影響を受けない場合: FDE または vTPM シール付き LUKS 復号を使用しない Linux VM、またはセキュアブートが有効になっていない Linux VM は、証明書の有効期限の影響を受けません。
  • カスタム PK または KEK 構成のインスタンス:
    • 考慮すべき場合: インスタンスがシステムでカスタム セキュアブート変数（カスタム PK や KEK など）を使用しているが、データベース（db）の標準の Microsoft 証明書に依存してブートローダーに署名している場合。
    • 影響: Microsoft UEFI CA 2023 のみで署名された後続のブートローダー アップデートを起動するには、標準の db 証明書の更新が必要です。ただし、カスタムキーを使用しているため、Google のガイドで提供されている標準の更新ファイル（DBUpdate3P2023.bin または kek2023update.bin）は適用されません。UEFI ファームウェアは署名を確認し、システムに存在する KEK（または PK）の秘密鍵で更新に署名することを要求します。
    • 修復: 証明書更新ファイルを適用する前に、カスタム PK または KEK に関連付けられた秘密鍵を使用して署名するか、カスタム認証局を通じてこれらの更新を管理する必要があります。
    • 影響を受けない場合: ブートローダーが独自のカスタム認証局または鍵（カスタム db 証明書など。期限切れになる Microsoft Corporation UEFI CA 2011 ではない）で署名されている場合、Microsoft のデフォルト証明書の期限切れの影響は受けず、更新を行う必要はありません。
  • 2025 年 11 月より前のマシンイメージにロールバックするインスタンス:
    • 影響を受ける場合: セキュアブートが有効になっている状態で、2025 年 11 月 7 日より前にキャプチャされたマシンイメージに VM を復元またはロールバックする場合。
    • 影響: ロールバックされたインスタンスは、2023 年の証明書がない古い UEFI ファームウェア構成と証明書ストアを復元します。これにより、インスタンスは後続のブートローダーの更新後にブート障害が発生しやすくなり、証明書の更新を再度適用する必要があります。
    • 影響を受けない場合: セキュアブートを無効にするか、デフォルトの証明書に依存するイメージから 2025 年 11 月 7 日以降にマシンイメージを作成した場合、マシンイメージへのロールバックはインスタンスに影響しません。

影響を受けるコンピューティング インスタンスを特定し、更新を計画する

2026 年を通して、影響を受けるコンピューティング インスタンスを特定し、次の手順で更新の準備を行うことをおすすめします。

  1. インスタンスを特定する: gcloud compute instances list コマンドを使用すると、セキュアブートが有効になっていて、カットオフ日より前に作成されたインスタンスを特定できます。

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

  2. カスタム変数の確認（省略可）: カスタム イメージまたはインポートされたイメージを使用する場合は、カスタムの db または KEK セキュアブート変数が明示的に定義されているかどうかを確認します（デフォルトが完全にオーバーライドされます）。デフォルトの証明書を使用している場合、イメージ レベルで操作は必要ありません。

    • VM インスタンスを確認するには、次のコマンドを実行します。

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

    • ソースディスク イメージを確認するには、次のコマンドを実行します。

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

    出力が空の場合、または null が返された場合、インスタンスまたはイメージはデフォルトの証明書を使用しており、イメージ レベルでの操作は必要ありません。

  3. データの完全性を確保する: 変更を行う前に、最新のデータ バックアップと FDE または BitLocker の復元キーにアクセスできることを確認します。

  4. 証明書を更新する: KEK と DB の更新ガイドに沿って、DB 証明書と KEK 証明書を更新します。または、2025 年 11 月 7 日以降に作成するコンピューティング インスタンスに移行します。これには、2023 年の証明書が含まれます（新しいインスタンスがデフォルトの証明書に依存するイメージを使用している場合）。ディスク スナップショットからコンピューティング インスタンスを再作成するの手順に沿って操作します。

ディスク スナップショットからコンピューティング インスタンスを再作成する

ディスク スナップショットを作成し、そのスナップショットから新しいインスタンスを作成すると、新しいコンピューティング インスタンスは、更新されたデフォルトを信頼し、古い証明書をクリアする新しいファームウェア（vTPM/NVRAM）状態を継承します。

スナップショットからコンピューティング インスタンスを再作成する前に、ゲスト OS に 2023 証明書を信頼するために必要な更新（Windows の関連する Microsoft KB や Linux ディストリビューションの最新の Shim など）がすべてインストールされていることを確認してください。

この移行を管理するには、次の gcloud コマンドのシーケンスを使用します。

  1. ブートディスクを特定する: ソース コンピューティング インスタンスに接続されているブートディスクの名前を特定します。

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

  2. ディスクのスナップショットを作成する: ブートディスクのスナップショットを作成します。データの完全性を最適化するには、このコマンドを実行する前にコンピューティング インスタンスを停止します。

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

  3. 新しいコンピューティング インスタンスを作成する: スナップショットをブートソースとして使用して、新しいコンピューティング インスタンスをプロビジョニングします。ソース インスタンスでセキュアブートが有効になっている場合は、--shielded-secure-boot フラグを含めて、新しいインスタンスでセキュアブートを有効にします。

    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

注: この方法でプロビジョニングされたインスタンスは、静的に割り当てられて明示的に再割り当てされない限り、新しい内部 IP アドレスと外部 IP アドレスを受け取ります。インスタンス レベルのメタデータ、タグ、サービス アカウントは自動的に複製されないため、再作成時に明示的に構成する必要があります。

検証

コンピューティング インスタンスのファームウェアと OS を更新したら、2023 年の証明書が存在することを確認できます。KEK 変数と db 変数の両方で 2023 年の証明書が存在することが示されている場合、インスタンスは最新の状態であり、追加の操作は必要ありません。

Linux

Linux で署名データベースを確認するには、efitools パッケージの efi-readvar コマンドを使用するか（RHEL 8/9 など、efitools が使用できないディストリビューションの場合）、mokutil を使用します。

方法 1: efi-readvar を使用する

  1. efi-readvar が存在しない場合は、efitools パッケージをインストールします。Linux にインストールするには、ディストリビューションのコマンドを実行します。

    Debian/Ubuntu

    sudo apt update && sudo apt install efitools

    RHEL/CentOS/Fedora（Fedora のみ。efitools は RHEL/CentOS リポジトリでは使用できません）

    sudo yum install efitools

    SLES

    sudo zypper install efitools

  2. KEK 変数と db 変数で証明書を確認します。

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

方法 2: mokutil を使用する

efitools が使用できない Red Hat Enterprise Linux（RHEL）などのディストリビューションでは、デフォルトでインストールされている mokutil ユーティリティを使用します。

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

Windows（PowerShell）

管理者 PowerShell プロンプトで次のコマンドを実行します。各コマンドは 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

トラブルシューティング

2026 年 6 月以降にセキュアブート エラーが原因でインスタンスが起動しない場合は、次のいずれかの方法で復元してみてください。

  • セキュアブートを一時的に無効にする: これにより、インスタンスを起動して更新を適用できます。

    セキュアブートを無効にするには、次のコマンドを実行します。

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

    ブートローダー/shim に必要なアップデートを適用したら、セキュアブートを再度有効にします。

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

  • バックアップから復元する: 起動の問題が発生する前に作成されたマシンイメージからインスタンスを復元します。

  • インスタンスを再作成する: インスタンスを再作成し、スナップショットからデータを復元します。

問題が解決しない場合やサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

よくある質問

このセクションでは、Microsoft Secure Boot 証明書の有効期限に関するよくある質問とその回答を紹介します。

セキュアブートの証明書の有効期限はいつですか？

Microsoft のセキュアブート証明書は 2026 年に期限切れになります。詳細は以下のとおりです。

  • サポート終了が迫っている最も重要な 2 つの証明書は、Linux Shim などのサードパーティ製ブートローダーに署名する Microsoft Corporation UEFI CA 2011（2026 年 6 月に有効期限切れ）と、Windows ブートローダーに署名する Microsoft Windows Production PCA 2011（2026 年 10 月に有効期限切れ）です。

証明書の有効期限切れの影響を受けるのは誰ですか？

この証明書の有効期限切れは、コンピューティング インスタンスが次の両方の必須前提条件を満たしている場合にのみ影響します。

  1. 2025 年 11 月 7 日より前にインスタンスを作成し、更新していない。この日、Compute Engine は UEFI ファームウェアのデフォルトのセキュアブート証明書を更新しました。
  2. インスタンスでセキュアブートを有効にしている。

2025 年 11 月 7 日以降に作成するインスタンスは、デフォルトの証明書セットに依存するイメージから作成する場合、影響を受けません。

インスタンスが両方の前提条件を満たしている場合、特定の状況下では、証明書の有効期限が次の構成に影響します。

  • vTPM PCR シークレット シーリング: インスタンスが仮想トラステッド プラットフォーム モジュール（vTPM）プラットフォーム構成レジスタ（特に PCR7）を使用して暗号鍵またはシークレットをシールする場合。
  • Windows BitLocker / VSM: Windows インスタンスで BitLocker ディスク暗号化またはセキュアブートで仮想セキュアモード（VSM）を使用している場合。
  • Linux FDE: Linux インスタンスで vTPM PCR（特に PCR7）にシールする FDE を使用している場合。
  • インスタンスをロールバックする: 2025 年 11 月 7 日より前に作成したマシンイメージに VM を復元またはロールバックする場合。

これらの各構成の影響と修復手順の詳細については、特定のゲスト構成への影響をご覧ください。

証明書の有効期限の影響を受けないのは誰ですか？

次のいずれかに該当する場合、証明書の有効期限は影響しません。

  • セキュアブートが無効になっている: Shielded VM インスタンスでセキュアブートが有効になっていない場合、期限切れの UEFI 証明書は検証されず、使用されません。セキュアブートはデフォルトで無効になっています。ただし、シークレット シーリングに vTPM プラットフォーム構成レジスタ（特に PCR7）を使用している場合、セキュアブートが無効になっていても、UEFI 変数の更新やインスタンスの再作成によって PCR7 測定値が変更されます。このような構成は非常にまれです。
  • 2025 年 11 月 7 日以降に作成された場合: この日付以降にインスタンスを作成した場合は、デフォルトの証明書セットに依存するイメージから作成したものであれば、ファームウェアに更新された 2023 証明書がすでに含まれています。
  • Container-Optimized OS（COS）を実行している場合: これらの証明書の更新は COS 環境に影響しません。

  • カスタム PK、KEK、db 変数: 既定の Microsoft UEFI 証明書に依存せずに、独自のカスタム セキュアブート PK、KEK、db 変数を明示的に定義して管理している場合（たとえば、有効期限が切れる Microsoft Corporation UEFI CA 2011 ではなく、独自のカスタム db 証明書を使用してブートローダーに署名している場合）、既定の証明書の有効期限切れは影響しません。

    カスタム構成で、有効期限切れの Microsoft 証明書を使用してブートローダーに署名している場合は、有効期限切れの影響を受けます。ただし、カスタムの PK または KEK を使用しているため、このガイドで提供されている標準の更新ファイル（DBUpdate3P2023.bin または kek2023update.bin）は失敗します。これは、UEFI では、システムに存在する KEK（または PK）の秘密鍵で更新に署名する必要があるためです。証明書の更新ファイルを適用するには、カスタム PK または KEK の秘密鍵で署名する必要があります。

この有効期限は、Managed Service for Apache Spark（旧称 Dataproc）、Dataflow、Vertex AI Workbench インスタンスに影響しますか？

この証明書の有効期限切れは、Dataflow のインスタンスがデフォルトで Container-Optimized OS（COS）で実行されるため、Dataflow には影響しません。これらの証明書の更新は COS 環境には影響しません。

Managed Service for Apache Spark（旧称 Dataproc）インスタンスと Vertex AI Workbench インスタンスの場合、この有効期限は、インスタンスが次の両方の必須前提条件を満たしている場合にのみ影響します。

  1. 2025 年 11 月 7 日より前にインスタンスを作成した。
  2. インスタンスでセキュアブートを有効にしている。これらのサービスでは、デフォルトでセキュアブートは有効になりません。

インスタンスが両方の前提条件を満たしている場合、証明書の有効期限がインスタンスに影響します。ただし、OS ベンダーは当面の間、ブートローダーと shim の更新にデュアル署名する予定であるため、直ちに影響はありません。2023 証明書のみで署名された今後のアップデートをインストールしない限り、インスタンスに影響はありません。

対応しなかった場合はどうなりますか？

対応しない場合、インスタンスは既存のバイナリで通常どおり起動して動作します。ただし、2023 年の証明書のみで署名されたバイナリを含むブートローダーやカーネルのアップデートは、今後適用できなくなる可能性があります。OS ベンダーは 2011 年と 2023 年の両方の証明書でブートローダーと shim のアップデートにデュアル署名するため、ブートの失敗やアップデートのブロックはすぐに発生しないと考えられます。

証明書の更新に失敗すると、Windows インスタンスが起動しなくなりますか？

いいえ。修復に失敗しても、Windows システムの起動が妨げられることはありません。ただし、システム イベント ログにイベント ID 1801（「セキュアブートの CA/鍵を更新する必要があります」）が表示されることがあります。また、新しい 2023 年の証明書のみで署名されたバイナリを含む新しいカーネルやブートローダーのセキュリティ アップデートを適用できなくなります。

Linux で起動エラーが発生する具体的な条件は何ですか？

特定の条件下では、Linux で起動に失敗することがあります。

  • インスタンスでセキュアブートが有効になっている。
  • 「Microsoft UEFI CA 2023」証明書を信頼するように db UEFI 変数が更新されない。
  • OS は、その証明書に厳密に依存する（2011 年の証明書で二重署名されていない）ブートローダー（またはシム）を更新します。

新しい証明書を参照する証明書の更新または shim の更新を適用しない場合でも、Linux インスタンスは引き続き正常に起動します。

インスタンスに更新された証明書があるかどうかを確認するにはどうすればよいですか？

インスタンスのファームウェアに新しい証明書が含まれているかどうかを確認するには、検証セクションで説明されているコマンドを参照してください。証明書がない場合は、KEK と DB の更新ガイドに沿って更新するか、インスタンスを再作成します。

影響を受けるインスタンスを再起動または再起動すると、問題は解決しますか？

いいえ。コンピューティング インスタンスを再起動しても、セキュアブート証明書は更新されません。ただし、2023 年の証明書のみで署名されたバイナリを含むブートローダーまたはカーネルの更新が適用されるまで、インスタンスは既存の証明書を使用して通常どおりに起動して動作し続けます。コンピューティング インスタンスを再起動すると、元々 2025 年 11 月 7 日より前に作成された場合、古い証明書が保持されます。証明書はインスタンスのファームウェア（vTPM/NVRAM）の一部です。そのため、KEK と DB の更新ガイドに沿って操作するか、インスタンスを再作成して新しい証明書を適用する必要があります。

証明書の有効期限切れに備えるにはどうすればよいですか？

準備するには、次の手順を行います。

  • 状況を把握する: Shielded VM、セキュアブート、FDE、BitLocker、または vTPM PCR に依存するソフトウェアの使用状況を監査します。
  • 復元キーとバックアップ: 復元キー（FDE/BitLocker 用）と最新のデータ バックアップをすぐに利用できるようにします。
  • イメージを管理する: 以前のカスタム イメージを特定して使用を停止するか、新しい証明書が含まれていることを確認します。
  • 更新または移行: 証明書を更新する場合は、KEK と DB の更新ガイドを参照してください。または、2025 年 11 月 7 日より前に作成した長時間実行されているコンピューティング インスタンスを再作成することを検討してください。新しいインスタンスには必要な証明書がすでに含まれています（デフォルトの証明書に依存するイメージから新しいインスタンスを作成する場合）。

標準ディスク スナップショットは、最も信頼性の高い方法です。スナップショットはディスクのブロックレベルのコピーであり、UEFI 変数やインスタンスレベルのメタデータは含まれません。スナップショットを使用して復元する手順は次のとおりです。

  1. インスタンスのブートディスクのスナップショットを作成します。
  2. 新しいコンピューティング インスタンスを作成し、ブートディスクのソースとしてスナップショットを選択します。

この移行では、マシンイメージ、インスタンスのクローン作成、Backup and DR サービスのバックアップを使用しないでください。これらはインスタンス ファームウェアを複製し、2025 年 11 月 7 日より前に作成されたソース コンピューティング インスタンスの古い証明書を保持するためです。

2026 年 6 月以降にシステムが起動しなくなった場合はどうすればよいですか？

この問題が原因で起動に失敗したと思われる場合は、トラブルシューティングをご覧ください。

Google Cloud は Microsoft セキュアブート証明書の有効期限切れにどのように対応していますか？

Google Cloud では、2025 年 11 月 7 日以降に作成されたコンピューティング インスタンスに新しい証明書が自動的に含まれます。2025 年 11 月 7 日より前に実行したコンピューティング インスタンスを維持したいお客様のみ、今後の更新を適用する必要がありますが、2025 年 11 月 7 日以降に作成したインスタンス（デフォルトの証明書を使用）に移行することをおすすめします。

次のステップ