Stay organized with collections
Save and categorize content based on your preferences.
This page provides instructions to manually trigger certificate reissuance for your
Google Distributed Cloud (GDC) air-gapped appliance web endpoints.
Before you begin
To get the permissions you need to access certificates in a namespace, ask your
Organization IAM Admin to grant you the Web TLS Certificate
Admin (web-tls-cert-admin) role.
Consider the following account requirements when performing certificate reissuance:
Use an Infrastructure Operator (IO) account to access the certificate in the
system namespace. Ask your IO to perform this task.
Use a Platform Administrator account to access certificates in other namespaces.
Reissue a certificate
You can manually reissue a certificate with an annotation update. If the default
certificate issuer changes, GDC air-gapped appliance won't automatically reissue
certificates signed by the previous default certificate issuer unless the
certificate is about to expire.
To manually trigger the reissuance of a certificate, use the kubectl CLI to
perform the following steps:
Set the manual-reissuance annotation to requested for target
Certificate. The following example updates the default-wildcard-cert
certificate in the istio-system namespace which uses the current default
certificate issuer:
You might see an in-progress annotation value as a transitioning state
while the certificate is being reissued. Wait for the manual-reissuance
annotation value to show finished:
Verify the certificate issuer; it must either match the issuer mentioned in
the certificate specification or, if not specified, the issuer must match the
current default issuer:
When you trigger and complete a manual bring-your-own certificate (BYO cert)
rotation, you must sign the newly generated Certificate Signing Request (CSR) for
a previously signed BYO cert. For more information, see
Sign the BYO certificate.
During rotation, GDC air-gapped appliance creates a new private and public key
pair. This makes the signed certificate uploaded earlier incompatible with the
new CSR. If the certificate specification hasn't changed since the initial upload,
the previously uploaded certificate remains in use until it expires. If the
specification changes, one of the following events occur:
GDC air-gapped appliance uses an existing matching certificate.
A fallback Certificate Authority (CA) issues a new certificate.
BYO cert manual rotation example
In the following example, you see a previously signed BYO cert triggered
for manual rotation:
The byoCertStatus shows the certificate type value is Ready,
The reason value is Issued with an earlier lastTransitionTime value than
the previous value:
Certificate signing alerts for initial issuance, rotation, and expiration must be
addressed by your IO using the troubleshooting steps documented in these sections
of the PKI runbook:
For subCA errorCode: PLATAUTH2001, see PLATAUTH-R2001.
For BYO cert errorCode: PLATAUTH2002, see PLATAUTH-R2002.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Manually reissue PKI web certificates\n\nThis page provides instructions to manually trigger certificate reissuance for your\nGoogle Distributed Cloud (GDC) air-gapped appliance 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, GDC air-gapped appliance 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/appliance/platform/pa-user/pki/transition-pki-modes#sign-byo-cert).\n\nDuring rotation, GDC air-gapped appliance 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- GDC air-gapped appliance 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\nManage 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."]]