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

複数の Microsoft セキュアブート証明書が 2026 年に期限切れになるため、このドキュメントでは、Compute Engine Shielded VM インスタンスを更新して、UEFI（Unified Extensible Firmware Interface）セキュアブート用の更新された Microsoft セキュアブート証明書を信頼する方法について説明します。有効期限が近づいている最も重要な 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 証明書を管理し、インスタンス ファームウェア内の鍵交換鍵（KEK）変数と許可された署名データベース（db）変数に保存します。

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

証明書名	ロール	有効期限
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）を指定するインスタンス。

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

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

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

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

• Windows セキュアブート証明書の有効期限と CA の更新 - Microsoft サポート
• 2026 年のセキュアブート証明書の変更: RHEL 環境向けのガイダンス - Red Hat カスタマー ポータル

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

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 には、証明書の有効期限切れの影響はありません。
• 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 のみ。RHEL/CentOS リポジトリでは efitools は使用できません）

   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 月以降にセキュアブート エラーが原因でインスタンスが起動しない場合は、次のいずれかのオプションを試して復元してください。

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

  注: セキュアブートを無効にすると、PCR 値（特に PCR7）が変更され、シークレット シーリングまたはディスク暗号化機能に影響する可能性があります。

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

  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 変数を明示的に定義して管理している場合、デフォルトの証明書の有効期限切れは影響しません。ただし、独自の証明書の更新と保守はお客様の責任で行っていただく必要があります。

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

対応しない場合、インスタンスは既存のバイナリを使用して通常どおり起動し、動作を続けます。ただし、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 日以降に作成したインスタンス（デフォルトの証明書を使用）に移行することをおすすめします。

次のステップ

• Shielded VM の詳細を確認する。
• Shielded VM オプションを変更する方法について学習する。
• 詳細については、セキュアブートをご覧ください。