Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie eine Anleitung zum manuellen Auslösen der Neuausstellung von Zertifikaten für Ihre Air-Gap-Webendpunkte von Google Distributed Cloud (GDC).
Hinweise
Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Web TLS Certificate Admin“ (web-tls-cert-admin) zuzuweisen, um die Berechtigungen zu erhalten, die Sie für den Zugriff auf Zertifikate in einem Namespace benötigen.
Beachten Sie bei der Neuausstellung von Zertifikaten die folgenden Kontoanforderungen:
Verwenden Sie ein Infrastructure Operator-Konto (IO), um auf das Zertifikat im System-Namespace zuzugreifen. Bitte deinen IO, diese Aufgabe auszuführen.
Verwenden Sie ein Plattformadministratorkonto, um auf Zertifikate in anderen Namespaces zuzugreifen.
Zertifikat neu ausstellen
Sie können ein Zertifikat mit einer Anmerkungsaktualisierung manuell neu ausstellen. Wenn sich der Standardaussteller von Zertifikaten ändert, werden von Distributed Cloud nicht automatisch Zertifikate neu ausgestellt, die vom vorherigen Standardaussteller von Zertifikaten signiert wurden, es sei denn, das Zertifikat läuft bald ab.
Wenn Sie die Neuausstellung eines Zertifikats manuell auslösen möchten, führen Sie die folgenden Schritte mit der kubectl CLI aus:
Legen Sie die Anmerkung manual-reissuance für das Ziel Certificate auf requested fest. Im folgenden Beispiel wird das default-wildcard-cert-Zertifikat im Namespace istio-system aktualisiert, für das der aktuelle Standardzertifikataussteller verwendet wird:
Möglicherweise sehen Sie den in-progress-Hinweiswert als Übergangszustand, während das Zertifikat neu ausgestellt wird. Warten Sie, bis für den Annotationswert manual-reissuance der Wert finished angezeigt wird:
Prüfen Sie den Zertifikataussteller. Er muss entweder mit dem in der Zertifikatspezifikation angegebenen Aussteller übereinstimmen oder, falls nicht angegeben, mit dem aktuellen Standardaussteller:
Wenn Sie eine manuelle BYO-Zertifikatsrotation (Bring Your Own Certificate) auslösen und abschließen, müssen Sie die neu generierte Zertifikatsignierungsanfrage (Certificate Signing Request, CSR) für ein zuvor signiertes BYO-Zertifikat signieren. Weitere Informationen finden Sie unter BYO-Zertifikat signieren.
Während der Rotation erstellt Distributed Cloud ein neues privates und öffentliches Schlüsselpaar. Das zuvor hochgeladene signierte Zertifikat ist daher nicht mit dem neuen CSR kompatibel. Wenn sich die Zertifikatspezifikation seit dem ersten Upload nicht geändert hat, wird das zuvor hochgeladene Zertifikat bis zum Ablaufdatum verwendet. Wenn sich die Spezifikation ändert, tritt eines der folgenden Ereignisse ein:
Distributed Cloud verwendet ein vorhandenes übereinstimmendes Zertifikat.
Eine Fallback-Zertifizierungsstelle stellt ein neues Zertifikat aus.
Beispiel für die manuelle Rotation eines selbst bereitgestellten Zertifikats
Im folgenden Beispiel sehen Sie ein zuvor signiertes BYO-Zertifikat, das für die manuelle Rotation ausgelöst wurde:
Der byoCertStatus-Wert des Zertifikats type ist Ready.
Der reason-Wert ist Issued mit einem früheren lastTransitionTime-Wert als der vorherige Wert:
Im folgenden Beispiel sehen Sie die Ausgabe für ein zuvor signiertes BYO-Zertifikat, das für die manuelle Rotation ausgelöst wurde:
Im signedCertStatus wird im Feld reason der Wert Rejected angezeigt, da das zuvor signierte Zertifikat nach der Rotation nicht mehr mit dem neuen CSR übereinstimmt.
Benachrichtigungen zur Zertifikatsignierung verwalten
Zertifikatsignierungsbenachrichtigungen für die Erstausstellung, Rotation und den Ablauf müssen von Ihrem IO mithilfe der in diesen Abschnitten des PKI-Runbooks dokumentierten Schritte zur Fehlerbehebung behandelt werden:
Informationen zum errorCode der untergeordneten CA: PLATAUTH2001 finden Sie unter PLATAUTH-R2001.
Informationen zum Fehlercode für BYO-Zertifikate: PLATAUTH2002 finden Sie unter PLATAUTH-R2002.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
