Panduan masa berlaku sertifikat Booting Aman Microsoft

Karena beberapa sertifikat Booting Aman Microsoft akan berakhir pada tahun 2026, dokumen ini memberikan panduan tentang cara mengupdate instance Shielded VM Compute Engine agar memercayai sertifikat Booting Aman Microsoft yang telah diupdate untuk Booting Aman UEFI (Unified Extensible Firmware Interface). Dua sertifikat paling penting yang akan segera berakhir adalah Microsoft Corporation UEFI CA 2011 (berakhir 27 Juni 2026), yang menandatangani bootloader pihak ketiga seperti Linux Shim, dan Microsoft Windows Production PCA 2011, yang berakhir pada 19 Oktober 2026, dan menandatangani bootloader Windows.

Booting Aman UEFI adalah standar keamanan yang digunakan Shielded VM untuk memastikan bahwa hanya software dan firmware tepercaya yang berjalan selama proses booting VM. Untuk mendukung Booting Aman di berbagai sistem operasi, Microsoft mengelola sertifikat UEFI, menyimpannya dalam variabel Key Exchange Key (KEK) dan Allowed Signature Database (db) dalam firmware instance.

Sertifikat Booting Aman dan tanggal habis masa berlaku

Nama sertifikat Peran Tanggal habis masa berlaku
Microsoft Corporation UEFI CA 2011 Menandatangani bootloader pihak ketiga, seperti Linux Shim 27 Juni 2026
Microsoft Windows Production PCA 2011 Menandatangani bootloader Windows 19 Oktober 2026
Microsoft Corporation KEK CA 2011 Digunakan untuk memperbarui DB dan DBX 24 Juni 2026

Masa berlaku sertifikat ini hanya memengaruhi Anda jika instance komputasi Anda memenuhi kedua prasyarat wajib berikut:

  1. Tanggal pembuatan: Anda membuat instance komputasi sebelum 7 November 2025 (saat Compute Engine memperbarui sertifikat Boot Aman default di firmware UEFI) dan Anda belum memperbaruinya.
  2. Status Booting Aman: Anda mengaktifkan Booting Aman di instance. Google Cloud tidak mengaktifkan Booting Aman secara default saat Anda membuat instance Shielded VM.

Instance yang Anda buat pada atau setelah 7 November 2025, sudah menyertakan sertifikat yang diupdate dalam variabel firmware-nya, asalkan instance tersebut menggunakan image yang mengandalkan set sertifikat default.

Jika instance Anda tidak memenuhi kedua prasyarat, masa berlaku sertifikat tidak akan memengaruhinya, dan Anda tidak perlu melakukan tindakan apa pun.

Dokumen ini menjelaskan cara mengidentifikasi instance yang terpengaruh dan melakukan update yang diperlukan.

Google Cloud selesai meluncurkan sertifikat baru pada 7 November 2025. Instance yang Anda buat pada atau setelah tanggal ini dari image yang mengandalkan kumpulan sertifikat default mencakup sertifikat yang diperbarui dalam variabel NVRAM/firmware-nya (db dan KEK) dan tidak memerlukan tindakan lebih lanjut. Namun, beberapa instance yang Anda buat pada minggu-minggu sebelum tanggal ini mungkin juga menyertakan sertifikat baru. Untuk memeriksa apakah sistem Anda sudah yang terbaru, gunakan perintah di bagian Verifikasi dalam dokumen ini.

Catatan: Masa berlaku sertifikat Booting Aman tidak memengaruhi hal berikut:

  • Instance yang tidak mengaktifkan Booting Aman. Perhatikan bahwa jika Anda menggunakan vTPM Platform Configuration Registers (khususnya PCR7) untuk penyegelan rahasia, setiap update pada variabel UEFI atau pembuatan ulang instance akan tetap mengubah pengukuran PCR7 meskipun dengan Boot Aman dinonaktifkan, meskipun konfigurasi tersebut sangat jarang terjadi.
  • Instance yang menjalankan Container-Optimized OS (COS).
  • Instance tempat Anda menyediakan Kunci Platform (PK) Booting Aman atau Kunci Pendaftaran Kunci (KEK) Anda sendiri.

Untuk instance komputasi yang dibuat sebelum 7 November 2025 yang tidak memiliki sertifikat yang diperbarui, ikuti panduan KEK dan update db untuk memperbarui sertifikat; jika karena alasan apa pun Anda tidak dapat melakukannya, pertimbangkan untuk membuat ulang instance Anda.

Pengaruh masa berlaku sertifikat Booting Aman terhadap Shielded VM

Jika diaktifkan, Shielded VM akan menerapkan Booting Aman menggunakan firmware UEFI, yang mempertahankan serangkaian sertifikat tepercaya (dalam variabel db) untuk memverifikasi tanda tangan biner urutan booting. Misalnya, jika update OS mengganti bootloader dengan bootloader yang hanya ditandatangani oleh Microsoft UEFI CA 2023, dan firmware instance komputasi tidak memercayai otoritas sertifikat ini, verifikasi Booting Aman akan gagal, dan Booting Aman akan menghentikan proses booting.

Untuk mengetahui detail selengkapnya tentang transisi ini, lihat panduan dari Microsoft dan vendor OS lainnya:

Dampak sistem operasi

Jika Anda mengaktifkan Booting Aman pada instance VM Terlindungi yang dibuat sebelum 7 November 2025, sebaiknya pastikan sertifikat 2023 telah diinstal; jika tidak, instance komputasi akan mengalami masalah booting jika Anda menerapkan update yang berisi bootloader yang hanya ditandatangani oleh sertifikat Microsoft UEFI CA 2023 (dan tidak ditandatangani ganda dengan sertifikat 2011). Jika Anda tidak mengambil tindakan, Anda mungkin tidak dapat menerapkan update bootloader atau kernel pada masa mendatang yang berisi biner yang ditandatangani hanya dengan sertifikat 2023. Perhatikan bahwa karena vendor OS berencana menandatangani ganda update bootloader dan shim dengan sertifikat 2011 dan 2023 untuk waktu yang tidak dapat diprediksi, kegagalan booting atau pemblokiran update tidak akan terjadi secara langsung. Untuk instance komputasi yang dibuat sebelum 7 November 2025: Pelanggan Windows mungkin melihat ID Peristiwa 1801 ("CA/kunci Boot Aman perlu diperbarui") di log peristiwa Sistem jika mereka belum menerapkan update sertifikat.

  • Image publik yang disediakan Google: Perbarui sertifikat DB dan KEK dengan mengikuti panduan update KEK dan DB. Atau, pertimbangkan untuk membuat ulang VM yang berjalan lama yang dibuat sebelum 7 November 2025.
  • Gambar kustom atau yang diimpor: Sebagian besar gambar kustom atau yang diimpor mengandalkan sertifikat Boot Aman default. Jika Anda tidak secara eksplisit mengganti variabel Boot Aman db atau KEK saat membuat image, image akan menggunakan kumpulan kunci default dan tidak memerlukan tindakan di tingkat image. Compute Engine secara otomatis menyediakan sertifikat yang diupdate saat Anda membuat instance dari image apa pun yang mengandalkan default ini.

    Anda hanya perlu mengambil tindakan jika Anda secara eksplisit menentukan variabel Boot Aman db atau KEK kustom (misalnya, untuk menyertakan sertifikat vendor keamanan pihak ketiga bersama dengan sertifikat Microsoft default) dalam metadata image selama proses pembuatan image. Karena menentukan variabel db atau KEK kustom akan menggantikan nilai default sepenuhnya (dan sistem mengabaikan kunci publik default), variabel kustom Anda mungkin tidak memiliki sertifikat "Microsoft UEFI CA 2023" atau KEK 2023 yang telah diupdate. Jika konfigurasi image kustom Anda tidak menyertakan sertifikat yang diperbarui ini, Anda harus membuat ulang atau memperbarui image Terlindungi Anda untuk menyertakannya. Untuk mengetahui petunjuknya, lihat Membuat image Shielded VM kustom.

Jika Anda memiliki instance komputasi yang dibuat sebelum 7 November 2025, dengan Boot Aman diaktifkan, tinjau persyaratan, batasan, dan faktor-faktor yang mempersulit berikut sebelum merencanakan jalur update Anda:

  • Persyaratan sebelum update:
    • Verifikasi akses kunci pemulihan: Jika instance Anda menggunakan FDE (termasuk BitLocker di Windows atau LUKS di Linux), Anda harus memastikan bahwa Anda memiliki akses ke kunci pemulihan sebelum memperbarui sertifikat atau membuat ulang instance. Mengubah variabel UEFI akan mengubah pengukuran booting dan akan memicu perintah pemulihan.
    • Mengelola secret vTPM: Jika instance Anda menggunakan Platform Configuration Registers (PCR) vTPM (khususnya PCR7) untuk penyegelan secret, Anda harus membuka segel atau mencadangkan secret ini sebelum mengupdate untuk mencegah hilangnya akses secara permanen.
  • Faktor dan batas yang memperumit:
    • Persyaratan urutan update: Untuk mencegah kegagalan verifikasi CA dan loop booting sistem, Anda harus menginstal sertifikat db dan KEK baru sebelum menerapkan update kernel atau shim baru.
    • Rollback firmware: Memulihkan instance ke image mesin lama yang diambil sebelum 7 November 2025 akan memulihkan firmware lama dan menghapus kepercayaan untuk sertifikat 2023. Jika Anda melakukan rollback, Anda harus menerapkan ulang update sertifikat.

Untuk mengetahui perincian mendetail tentang linimasa, langkah-langkah audit, dan proses migrasi, tinjau petunjuk berikut.

Dampak pada konfigurasi tamu tertentu

Pahami pengaruh masa berlaku sertifikat terhadap setiap konfigurasi hanya jika instance Anda memenuhi kedua prasyarat wajib (Anda membuatnya sebelum 7 November 2025, dan instance tersebut mengaktifkan Boot Aman):

  • Penyegelan rahasia PCR vTPM:
    • Saat menjadi faktor: Saat Anda menggunakan vTPM Platform Configuration Registers (khususnya PCR7) untuk menyegel rahasia, seperti kunci dekripsi.
    • Dampak: Memperbarui sertifikat Secure Boot (baik dengan menggunakan panduan update KEK dan db atau dengan membuat ulang instance dari snapshot disk) akan mengubah variabel UEFI, sehingga mengubah nilai pengukuran PCR7 saat booting berikutnya. Perubahan ini mencegah OS atau aplikasi tamu membuka atau mendekripsi rahasia ini kecuali jika Anda terlebih dahulu membuka atau mencadangkan rahasia sebelum update, dan kemudian menyegelnya kembali ke nilai PCR7 yang baru setelahnya.
    • Jika tidak terpengaruh: Jika Anda membuat VM pada atau setelah 7 November 2025, dari image yang mengandalkan sertifikat default, Anda tidak perlu memperbarui sertifikat, PCR7 tetap tidak berubah, dan penyegelan rahasia berperilaku normal.
  • Instance komputasi Windows yang menggunakan BitLocker atau Virtual Secure Mode (VSM):
    • Saat menjadi faktor: Saat VM Windows Anda menggunakan enkripsi disk penuh BitLocker atau VSM, keduanya memercayai Booting Aman UEFI dan PCR7 untuk menyegel kunci enkripsinya.
    • Dampak: Mengubah sertifikat Booting Aman UEFI—atau membuat ulang instance dari snapshot—akan mengubah pengukuran booting PCR7. Saat reboot berikutnya, BitLocker mendeteksi perubahan konfigurasi, gagal merilis kunci secara otomatis, dan melakukan booting ke layar Pemulihan BitLocker yang meminta kunci pemulihan.
    • Perbaikan: Anda harus memverifikasi bahwa Anda memiliki kunci pemulihan BitLocker yang tersedia sebelum memperbarui sertifikat atau memigrasikan instance. Setelah itu, ikuti panduan di Memperbarui db dan KEK di Windows.
    • Jika tidak terpengaruh: Masa berlaku sertifikat tidak memengaruhi instance Windows yang tidak mengaktifkan BitLocker atau VSM, atau yang tidak mengaktifkan Booting Aman.
  • VM Linux yang menggunakan FDE:
    • Saat menjadi faktor: Saat instance Linux Anda menggunakan FDE, seperti LUKS, tempat Anda menyegel kunci dekripsi ke PCR vTPM (khususnya PCR7).
    • Dampak: Mengupdate sertifikat Booting Aman atau membuat ulang VM akan mengubah PCR7, sehingga mencegah dekripsi otomatis volume booting. Sistem berhenti selama booting dan meminta Anda memasukkan frasa sandi dekripsi.
    • Perbaikan: Pastikan Anda memiliki frasa sandi atau kunci pemulihan sebelum menjalankan update. Lepaskan atau buka segel kunci LUKS dari TPM sebelum update, lalu ikat ulang atau segel ulang ke nilai PCR7 baru setelah menyelesaikan update.
    • Jika tidak terpengaruh: Masa berlaku sertifikat tidak memengaruhi VM Linux yang tidak menggunakan dekripsi LUKS yang disegel vTPM atau FDE, atau VM yang tidak mengaktifkan Booting Aman.
  • Instance yang di-roll back ke image mesin sebelum November 2025:
    • Kapan hal ini menjadi faktor: Saat Anda memulihkan atau mengembalikan VM ke image mesin yang diambil sebelum 7 November 2025, dengan Boot Aman diaktifkan.
    • Dampak: Instance yang di-roll back memulihkan konfigurasi firmware UEFI dan penyimpanan sertifikat yang lebih lama yang tidak memiliki sertifikat 2023. Hal ini membuat instance rentan terhadap kegagalan booting di masa mendatang setelah update bootloader berikutnya, sehingga Anda harus menerapkan ulang update sertifikat.
    • Saat tidak terpengaruh: Mengembalikan ke image mesin tidak memengaruhi instance jika Anda menonaktifkan Secure Boot, atau jika Anda membuat image mesin pada atau setelah 7 November 2025, dari image yang mengandalkan sertifikat default.

Mengidentifikasi instance komputasi yang terpengaruh dan merencanakan update

Sepanjang tahun 2026, sebaiknya Anda mengidentifikasi instance komputasi yang terpengaruh, dan melakukan langkah-langkah berikut untuk bersiap menghadapi update:

  1. Mengidentifikasi instance: Anda dapat menggunakan perintah gcloud compute instances list untuk mengidentifikasi instance yang mengaktifkan Boot Aman dan dibuat sebelum tanggal batas waktu:

    gcloud compute instances list \
    --filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
    --format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"
    
  2. Periksa variabel kustom (Opsional): Jika Anda menggunakan gambar kustom atau yang diimpor, verifikasi apakah gambar tersebut secara eksplisit menentukan variabel Boot Aman db atau KEK kustom (yang sepenuhnya menggantikan default). Jika mengandalkan sertifikat default, Anda tidak perlu melakukan tindakan apa pun di tingkat gambar:

    • Untuk memeriksa instance VM, jalankan:

      gcloud compute instances describe INSTANCE_NAME \
          --zone=ZONE \
          --format="yaml(shieldedInstanceInitialState)"
      
    • Untuk memeriksa image disk sumber, jalankan:

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

    Jika output kosong atau menampilkan null, instance atau image menggunakan sertifikat default dan tidak memerlukan tindakan di tingkat image.

  3. Pastikan integritas data: Pastikan Anda memiliki cadangan data terbaru dan akses ke kunci pemulihan FDE atau BitLocker sebelum melanjutkan perubahan apa pun.

  4. Perbarui sertifikat: Perbarui sertifikat DB dan KEK dengan mengikuti panduan pembaruan KEK dan DB. Atau, lakukan migrasi ke instance komputasi yang Anda buat pada atau setelah 7 November 2025, yang mencakup sertifikat 2023 (asalkan instance baru menggunakan image yang mengandalkan sertifikat default), dengan mengikuti petunjuk di Membuat ulang instance komputasi dari snapshot disk.

Membuat ulang instance komputasi dari snapshot disk

Saat Anda mengambil snapshot disk dan membuat instance baru darinya, instance komputasi baru akan mewarisi status firmware (vTPM/NVRAM) baru yang memercayai default yang diperbarui dan menghapus sertifikat lama.

Sebelum membuat ulang instance komputasi dari snapshot, pastikan OS tamu telah menginstal semua update yang diperlukan (seperti KB Microsoft yang relevan untuk Windows, atau Shim terbaru untuk distribusi Linux) agar dapat memercayai sertifikat 2023.

Anda dapat menggunakan urutan perintah gcloud berikut untuk mengelola migrasi ini:

  1. Identifikasi boot disk: Tentukan nama boot disk yang terpasang pada instance komputasi sumber Anda:

    SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
        --zone=ZONE \
        --format="value(disks[0].source.basename())")
    
  2. Buat snapshot disk: Ambil snapshot disk booting tersebut. Untuk integritas data yang optimal, hentikan instance komputasi sebelum menjalankan perintah ini:

    gcloud compute disks snapshot $SOURCE_DISK \
        --snapshot-names="migration-snapshot-$(date +%s)" \
        --zone=ZONE \
        --storage-location=REGION
    
  3. Buat instance komputasi baru: Sediakan instance komputasi baru dengan menggunakan snapshot sebagai sumber booting. Jika Booting Aman diaktifkan di instance sumber, sertakan flag --shielded-secure-boot untuk mengaktifkan Booting Aman di instance baru.

    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
    

Catatan: Instance yang disediakan menggunakan pendekatan ini akan menerima alamat IP internal dan eksternal baru, kecuali jika dialokasikan secara statis dan ditetapkan ulang secara khusus. Metadata, tag, dan akun layanan tingkat instance tidak direplikasi secara otomatis dan harus dikonfigurasi secara eksplisit selama pembuatan ulang.

Verifikasi

Setelah mengupdate firmware dan OS untuk instance komputasi, Anda dapat memverifikasi bahwa sertifikat 2023 ada. Jika variabel KEK dan db menunjukkan bahwa sertifikat 2023 ada, instance Anda sudah diupdate dan tidak ada tindakan lebih lanjut yang diperlukan.

Linux

Anda dapat memverifikasi database tanda tangan di Linux dengan menggunakan perintah efi-readvar dari paket efitools, atau (pada distribusi yang tidak menyediakan efitools, seperti RHEL 8/9) dengan menggunakan mokutil.

Metode 1: Menggunakan efi-readvar

  1. Jika efi-readvar tidak ada, instal paket efitools. Untuk menginstal di Linux, jalankan perintah untuk distribusi Anda:

    Debian/Ubuntu

    sudo apt update && sudo apt install efitools
    

    RHEL/CentOS/Fedora (Khusus Fedora; efitools tidak tersedia di repositori RHEL/CentOS)

    sudo yum install efitools
    

    SLES

    sudo zypper install efitools
    
  2. Periksa sertifikat dalam variabel KEK dan db:

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

Metode 2: Menggunakan mokutil

Pada distribusi seperti Red Hat Enterprise Linux (RHEL) yang tidak menyediakan efitools, gunakan utilitas mokutil, yang diinstal secara default:

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

Windows (PowerShell)

Jalankan perintah berikut di command prompt PowerShell administrator. Setiap perintah harus menampilkan 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

Pemecahan masalah

Jika instance gagal di-boot karena error Booting Aman setelah Juni 2026, coba salah satu opsi berikut untuk memulihkannya:

  • Menonaktifkan Secure Boot untuk sementara: Tindakan ini memungkinkan Anda mem-booting instance untuk menerapkan update.

    Catatan: Menonaktifkan Boot Aman akan mengubah nilai PCR, khususnya PCR7, yang dapat memengaruhi fungsi penyegelan rahasia atau enkripsi disk.

    Untuk menonaktifkan Secure Boot, jalankan perintah berikut:

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

    Setelah menerapkan update yang diperlukan ke bootloader/shim, aktifkan kembali Booting Aman:

    gcloud compute instances update INSTANCE_NAME --shielded-secure-boot
    
  • Pulihkan dari cadangan: Pulihkan instance dari image mesin yang dibuat sebelum masalah booting dimulai.

  • Buat ulang instance: Buat ulang instance dan pulihkan data dari snapshot.

Jika Anda masih mengalami masalah atau memerlukan bantuan, hubungi Cloud Customer Care.

Pertanyaan umum (FAQ)

Bagian ini memberikan jawaban atas pertanyaan umum tentang masa berlaku sertifikat Microsoft Secure Boot.

Kapan masa berlaku sertifikat Booting Aman berakhir?

Masa berlaku sertifikat Booting Aman Microsoft akan berakhir pada tahun 2026. Secara khusus:

  • Dua sertifikat paling penting yang mendekati akhir masa pakainya adalah Microsoft Corporation UEFI CA 2011 (berakhir pada Juni 2026), yang menandatangani bootloader pihak ketiga seperti Linux Shim, dan Microsoft Windows Production PCA 2011, yang berakhir pada Oktober 2026 dan menandatangani bootloader Windows.

Siapa yang terpengaruh oleh masa berlaku sertifikat yang berakhir?

Masa berlaku sertifikat ini hanya memengaruhi Anda jika instance komputasi Anda memenuhi kedua prasyarat wajib berikut:

  1. Anda membuat instance sebelum 7 November 2025—saat Compute Engine memperbarui sertifikat Booting Aman default di firmware UEFI—dan Anda belum memperbaruinya.
  2. Anda mengaktifkan Booting Aman di instance.

Instance yang Anda buat pada atau setelah 7 November 2025 tidak terpengaruh, asalkan Anda membuatnya dari image yang mengandalkan set sertifikat default.

Jika instance Anda memenuhi kedua prasyarat, masa berlaku sertifikat akan memengaruhi konfigurasi berikut dalam keadaan tertentu:

  • Penyegelan secret PCR vTPM: Jika instance menggunakan Platform Configuration Registers (PCR) Virtual Trusted Platform Module (vTPM) (khususnya PCR7) untuk menyegel kunci enkripsi atau secret.
  • Windows BitLocker / VSM: Jika instance Windows Anda menggunakan enkripsi disk BitLocker atau Virtual Secure Mode (VSM) dengan Booting Aman.
  • FDE Linux: Jika instance Linux Anda menggunakan FDE yang Anda segel ke PCR vTPM (khususnya PCR7).
  • Mengembalikan instance: Jika Anda memulihkan atau mengembalikan VM ke image mesin yang Anda buat sebelum 7 November 2025.

Untuk mengetahui perincian mendetail tentang dampak dan langkah-langkah perbaikan untuk setiap konfigurasi ini, lihat Dampak pada konfigurasi tamu tertentu.

Siapa yang tidak terpengaruh oleh masa berlaku sertifikat yang berakhir?

Masa berlaku sertifikat tidak akan memengaruhi Anda jika salah satu hal berikut berlaku:

  • Booting Aman dinonaktifkan: Jika Booting Aman tidak diaktifkan pada instance Shielded VM Anda, instance tersebut tidak akan memvalidasi atau menggunakan sertifikat UEFI yang akan segera berakhir. Secure Boot dinonaktifkan secara default. Namun, perhatikan bahwa jika Anda menggunakan vTPM Platform Configuration Registers (khususnya PCR7) untuk penyegelan rahasia, setiap update pada variabel UEFI atau pembuatan ulang instance akan tetap mengubah pengukuran PCR7 meskipun dengan Secure Boot dinonaktifkan, meskipun konfigurasi tersebut sangat jarang terjadi.
  • Dibuat pada atau setelah 7 November 2025: Anda membuat instance pada atau setelah tanggal ini, sehingga firmwarenya sudah menyertakan sertifikat 2023 yang telah diupdate, asalkan Anda membuatnya dari image yang mengandalkan set sertifikat default.
  • Menjalankan Container-Optimized OS (COS): Update sertifikat ini tidak memengaruhi lingkungan COS.
  • Variabel PK, KEK, atau db kustom: Jika Anda secara eksplisit menentukan dan mengelola variabel PK, KEK, atau db Booting Aman kustom Anda sendiri tanpa mengandalkan sertifikat UEFI Microsoft default, masa berlaku sertifikat default tidak akan memengaruhi Anda. Namun, Anda bertanggung jawab untuk memperbarui dan memelihara sertifikat Anda sendiri.

Apa yang terjadi jika saya tidak mengambil tindakan?

Jika Anda tidak melakukan tindakan apa pun, instance Anda akan terus melakukan booting dan beroperasi seperti biasa dengan biner yang ada. Namun, Anda mungkin tidak dapat menerapkan update bootloader atau kernel mendatang yang berisi biner yang hanya ditandatangani dengan sertifikat 2023. Perhatikan bahwa karena vendor OS menandatangani ganda update bootloader dan shim dengan sertifikat tahun 2011 dan 2023, kegagalan booting atau pemblokiran update tidak akan terjadi secara langsung.

Apakah gagal memperbarui sertifikat akan mencegah instance Windows melakukan booting?

Tidak. Kegagalan untuk memperbaiki tidak akan mencegah startup sistem Windows. Namun, Anda mungkin melihat ID Peristiwa 1801 ("CA/kunci Boot Aman perlu diperbarui") di log peristiwa Sistem, dan Anda tidak akan dapat menerapkan update keamanan kernel atau bootloader baru yang berisi biner yang hanya ditandatangani dengan sertifikat 2023 baru.

Kondisi spesifik apa yang memicu kegagalan booting di Linux?

Kegagalan booting dapat terjadi di Linux dalam kondisi tertentu:

  • Instance telah mengaktifkan Booting Aman.
  • Variabel UEFI db tidak diperbarui untuk mempercayai sertifikat "Microsoft UEFI CA 2023".
  • OS mengupdate bootloader (atau shim) yang bergantung sepenuhnya pada sertifikat tersebut (dan tidak ditandatangani ganda dengan sertifikat 2011).

Jika Anda tidak menerapkan update sertifikat atau update shim yang mereferensikan sertifikat baru, instance Linux Anda akan terus berhasil di-boot.

Bagaimana cara mengetahui apakah instance saya memiliki sertifikat yang diupdate?

Untuk menentukan apakah instance Anda menyertakan sertifikat baru dalam firmware-nya, lihat perintah yang diuraikan di bagian Verifikasi. Jika sertifikat tidak ada, Anda dapat memperbaruinya dengan mengikuti panduan update KEK dan db, atau membuat ulang instance.

Apakah memulai ulang atau melakukan reboot pada instance yang terpengaruh dapat menyelesaikan masalah?

Tidak. Memulai ulang atau melakukan booting ulang instance komputasi tidak akan mengupdate sertifikat booting amannya, tetapi instance akan terus melakukan booting dan beroperasi secara normal dengan sertifikat yang ada hingga update bootloader atau kernel yang berisi biner yang ditandatangani hanya dengan sertifikat 2023 diterapkan. Jika Anda memulai ulang instance komputasi, instance tersebut akan mempertahankan sertifikat lama jika awalnya dibuat sebelum 7 November 2025. Sertifikat adalah bagian dari firmware instance (vTPM/NVRAM). Oleh karena itu, Anda harus mengikuti panduan KEK dan update DB atau membuat ulang instance untuk menerapkan sertifikat baru.

Bagaimana cara mempersiapkan masa berlaku sertifikat yang akan berakhir?

Untuk bersiap, lakukan langkah-langkah berikut:

  • Identifikasi: Audit penggunaan Shielded VM, Booting Aman, FDE, BitLocker, atau software apa pun yang mengandalkan PCR vTPM.
  • Kunci pemulihan & cadangan: Pastikan ketersediaan kunci pemulihan (untuk FDE/BitLocker) dan cadangan data terbaru dengan cepat.
  • Mengelola image: Identifikasi image kustom lama dan hentikan penggunaannya atau pastikan image tersebut menyertakan sertifikat baru.
  • Memperbarui atau memigrasikan: Jika Anda ingin memperbarui sertifikat, lihat panduan pembaruan KEK dan db. Atau, pertimbangkan untuk membuat ulang instance komputasi yang berjalan lama yang Anda buat sebelum 7 November 2025, karena instance baru sudah menyertakan sertifikat yang diperlukan (asalkan Anda membuat instance baru dari image yang mengandalkan sertifikat default).

Snapshot disk standar memberikan metode yang paling andal. Snapshot adalah salinan tingkat blok dari disk dan tidak berisi variabel UEFI atau metadata tingkat instance. Untuk memulihkan menggunakan snapshot, lakukan hal berikut:

  1. Buat snapshot boot disk instance.
  2. Buat instance komputasi baru dan pilih snapshot sebagai sumber untuk boot disk.

Anda tidak boleh menggunakan image mesin, cloning instance, atau Backup and DR Service untuk migrasi ini karena layanan tersebut mereplikasi firmware instance dan mempertahankan sertifikat lama untuk instance komputasi sumber yang dibuat sebelum 7 November 2025.

Apa yang harus saya lakukan jika sistem saya berhenti melakukan booting setelah Juni 2026?

Jika Anda yakin masalah ini menyebabkan kegagalan booting, lihat Pemecahan masalah.

Bagaimana cara Google Cloud menangani masa berlaku sertifikat Microsoft Secure Boot yang telah berakhir?

Google Cloud secara otomatis menyertakan sertifikat baru untuk instance komputasi yang dibuat setelah 7 November 2025. Hanya pelanggan yang ingin mempertahankan instance komputasi yang berjalan sebelum 7 November 2025 yang mungkin perlu menerapkan update mendatang, tetapi sebaiknya Anda bermigrasi ke instance yang Anda buat pada atau setelah 7 November 2025 (mengandalkan sertifikat default).

Langkah berikutnya