Menerbitkan ulang sertifikat web PKI secara manual
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini memberikan petunjuk untuk memicu penerbitan ulang sertifikat secara manual untuk endpoint web air-gapped Google Distributed Cloud (GDC) Anda.
Sebelum memulai
Untuk mendapatkan izin yang Anda perlukan guna mengakses sertifikat di namespace, minta Admin IAM Organisasi Anda untuk memberi Anda peran Admin Sertifikat TLS Web (web-tls-cert-admin).
Pertimbangkan persyaratan akun berikut saat melakukan penerbitan ulang sertifikat:
Gunakan akun Operator Infrastruktur (IO) untuk mengakses sertifikat di namespace sistem. Minta IO Anda untuk melakukan tugas ini.
Gunakan akun Administrator Platform untuk mengakses sertifikat di namespace lain.
Menerbitkan ulang sertifikat
Anda dapat menerbitkan ulang sertifikat secara manual dengan pembaruan anotasi. Jika penerbit sertifikat default berubah, Distributed Cloud tidak akan otomatis menerbitkan ulang sertifikat yang ditandatangani oleh penerbit sertifikat default sebelumnya, kecuali jika masa berlaku sertifikat akan segera berakhir.
Untuk memicu penerbitan ulang sertifikat secara manual, gunakan kubectl CLI untuk
melakukan langkah-langkah berikut:
Tetapkan anotasi manual-reissuance ke requested untuk target
Certificate. Contoh berikut memperbarui sertifikat default-wildcard-cert di namespace istio-system yang menggunakan penerbit sertifikat default saat ini:
Anda mungkin melihat nilai anotasi in-progress sebagai status transisi
saat sertifikat diterbitkan ulang. Tunggu hingga nilai anotasi manual-reissuance
menampilkan finished:
Verifikasi penerbit sertifikat; penerbit harus cocok dengan penerbit yang disebutkan dalam spesifikasi sertifikat atau, jika tidak ditentukan, penerbit harus cocok dengan penerbit default saat ini:
Saat memicu dan menyelesaikan rotasi sertifikat bawa sendiri (BYO cert) secara manual, Anda harus menandatangani Permintaan Penandatanganan Sertifikat (CSR) yang baru dibuat untuk sertifikat BYO yang sebelumnya ditandatangani. Untuk mengetahui informasi selengkapnya, lihat
Menandatangani sertifikat BYO.
Selama rotasi, Distributed Cloud membuat pasangan kunci pribadi dan publik baru. Hal ini membuat sertifikat bertanda tangan yang diupload sebelumnya tidak kompatibel dengan
CSR baru. Jika spesifikasi sertifikat tidak berubah sejak upload awal,
sertifikat yang diupload sebelumnya tetap digunakan hingga masa berlakunya berakhir. Jika spesifikasi berubah, salah satu peristiwa berikut akan terjadi:
Distributed Cloud menggunakan sertifikat yang cocok dan sudah ada.
Pada contoh berikut, Anda akan melihat output untuk sertifikat BYO yang sebelumnya ditandatangani dan dipicu
untuk rotasi manual:
Di signedCertStatus, kolom reason menampilkan Rejected karena
sertifikat yang ditandatangani sebelumnya tidak lagi cocok dengan CSR baru setelah rotasi.
Peringatan penandatanganan sertifikat untuk penerbitan awal, rotasi, dan masa berlaku harus ditangani oleh IO Anda menggunakan langkah-langkah pemecahan masalah yang didokumentasikan di bagian-bagian runbook PKI berikut:
Untuk errorCode subCA: PLATAUTH2001, lihat PLATAUTH-R2001.
Untuk errorCode sertifikat BYO: PLATAUTH2002, lihat PLATAUTH-R2002.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[[["\u003cp\u003eThis page guides you through manually reissuing certificates for Google Distributed Cloud (GDC) air-gapped web endpoints using annotation updates via the \u003ccode\u003ekubectl\u003c/code\u003e CLI.\u003c/p\u003e\n"],["\u003cp\u003eReissuance of certificates is necessary when the default certificate issuer changes, as Distributed Cloud will not automatically reissue certificates from the previous issuer unless they are about to expire.\u003c/p\u003e\n"],["\u003cp\u003eTo access certificates in the system namespace you need an Infrastructure Operator (IO) account, whereas in other namespaces a Platform Administrator account is required.\u003c/p\u003e\n"],["\u003cp\u003eWhen performing a manual bring-your-own certificate (BYO cert) rotation, a new Certificate Signing Request (CSR) is created, and the previously signed certificate will be incompatible; requiring you to sign the newly generated CSR.\u003c/p\u003e\n"],["\u003cp\u003eCertificate signing alerts, such as \u003ccode\u003ePLATAUTH2001\u003c/code\u003e and \u003ccode\u003ePLATAUTH2002\u003c/code\u003e, must be addressed by the Infrastructure Operator (IO) using the troubleshooting steps found in the PKI runbook.\u003c/p\u003e\n"]]],[],null,["# Manually reissue PKI web certificates\n\nThis page provides instructions to manually trigger certificate reissuance for your\nGoogle Distributed Cloud (GDC) air-gapped web endpoints.\n\nBefore you begin\n----------------\n\nTo get the permissions you need to access certificates in a namespace, ask your\nOrganization IAM Admin to grant you the Web TLS Certificate\nAdmin (`web-tls-cert-admin`) role.\n\nConsider the following account requirements when performing certificate reissuance:\n\n- Use an Infrastructure Operator (IO) account to access the certificate in the system namespace. Ask your IO to perform this task.\n\n\u003c!-- --\u003e\n\n- Use a Platform Administrator account to access certificates in other namespaces.\n\nReissue a certificate\n---------------------\n\nYou can manually reissue a certificate with an annotation update. If the default\ncertificate issuer changes, Distributed Cloud won't automatically reissue\ncertificates signed by the previous default certificate issuer unless the\ncertificate is about to expire.\n\nTo manually trigger the reissuance of a certificate, use the `kubectl` CLI to\nperform the following steps:\n\n1. Set the `manual-reissuance` annotation to `requested` for target\n `Certificate`. The following example updates the `default-wildcard-cert`\n certificate in the `istio-system` namespace which uses the current default\n certificate issuer:\n\n kubectl annotate --overwrite certificate.pki.security.gdc.goog\n default-wildcard-cert -n istio-system\n pki.security.gdc.goog/manual-reissuance='requested'\n\n2. You might see an `in-progress` annotation value as a transitioning state\n while the certificate is being reissued. Wait for the `manual-reissuance`\n annotation value to show `finished`:\n\n kubectl -n istio-system get\n certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r '\n .metadata.annotations.\"pki.security.gdc.goog/manual-reissuance\"'\n\n The output looks similar to the following: \n\n finished\n\n3. Verify the certificate issuer; it must either match the issuer mentioned in\n the certificate specification or, if not specified, the issuer must match the\n current default issuer:\n\n kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r '\n .status.issuedBy'\n\n The output looks similar to the following: \n\n {\n \"name\": \"byo-cert-issuer\",\n \"namespace\": \"pki-system\"\n }\n\n### Bring-your-own certificate manual rotation\n\nWhen you trigger and complete a manual bring-your-own certificate (BYO cert)\nrotation, you must sign the newly generated Certificate Signing Request (CSR) for\na previously signed BYO cert. For more information, see\n[Sign the BYO certificate](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/pki/transition-pki-modes#sign-byo-cert).\n\nDuring rotation, Distributed Cloud creates a new private and public key\npair. This makes the signed certificate uploaded earlier incompatible with the\nnew CSR. If the certificate specification hasn't changed since the initial upload,\nthe previously uploaded certificate remains in use until it expires. If the\nspecification changes, one of the following events occur:\n\n- Distributed Cloud uses an existing matching certificate.\n- A fallback Certificate Authority (CA) issues a new certificate.\n\n#### BYO cert manual rotation example\n\nIn the following example, you see a previously signed BYO cert triggered\nfor manual rotation:\n\n- The `byoCertStatus` shows the certificate `type` value is `Ready`,\n- The `reason` value is `Issued` with an earlier `lastTransitionTime` value than\n the previous value:\n\n {\n \"byoCertStatus\": {\n \"csrStatus\": {\n \"conditions\": [\n {\n \"lastTransitionTime\": \"2024-05-03T22:38:43Z\",\n \"message\": \"\",\n \"observedGeneration\": 2,\n \"reason\": \"WaitingForSigning\",\n \"status\": \"False\",\n \"type\": \"Ready\"\n }\n ],\n \"csr\": \"LS0tLS1CRUdJTiBDRVJ...\"\n },\n \"signedCertStatus\": {\n \"conditions\": [\n {\n \"lastTransitionTime\": \"2024-05-03T22:38:43Z\",\n \"message\": \"RawSubjectPublickKeyInfo does not match with the CSR\",\n \"observedGeneration\": 2,\n \"reason\": \"Rejected\",\n \"status\": \"False\",\n \"type\": \"Ready\"\n }\n ]\n }\n },\n ```\n\nIn the following example, you see output for a previously signed BYO cert triggered\nfor manual rotation:\n\n- In the `signedCertStatus`, the `reason` field shows `Rejected` because the previously signed certificate no longer matches the new CSR after rotation.\n- The CSR `reason` states `WaitingForSigning`:\n\n \"conditions\": [\n {\n \"lastTransitionTime\": \"2024-05-03T08:42:10Z\",\n \"message\": \"Certificate is issued\",\n \"observedGeneration\": 2,\n \"reason\": \"Issued\",\n \"status\": \"True\",\n \"type\": \"Ready\"\n }\n ],\n \"errorStatus\": {\n \"errors\": [\n {\n \"code\": \"PLATAUTH2002\",\n \"message\": \"Waiting for CSR signing\"\n }\n ],\n \"lastUpdateTime\": \"2024-05-03T22:38:43Z\"\n },\n \"issuedBy\": {\n \"name\": \"byo-cert-issuer\",\n \"namespace\": \"pki-system\"\n }\n }\n\n Manage certificate signing alerts\n ---------------------------------\n\nCertificate signing alerts for initial issuance, rotation, and expiration must be\naddressed by your IO using the troubleshooting steps documented in these sections\nof the PKI runbook:\n\n- For subCA errorCode: `PLATAUTH2001`, see PLATAUTH-R2001.\n\n- For BYO cert errorCode: `PLATAUTH2002`, see PLATAUTH-R2002."]]
