[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-05。"],[],[],null,["# Rotate package validation certificate\n\nThis page describes how to rotate the root certificate authority used for\npackage validation in Google Distributed Cloud (GDC) air-gapped appliance\n\nGDC package validation uses a root certificate\nauthority (CA) to validate release key certificates. This makes it critical to\nrotate the root CA certificate periodically. You must rotate the root CA if you\nare instructed to do so through a release notice or the warning message that may\nbe displayed as you perform an upgrade.\n\nBefore you begin\n----------------\n\nTo rotate the package validation certificate, you must have the necessary\nidentity and access roles:\n\n- Ensure that you have write access to `package-validation-root-certs ConfigMap`.\n- Ask your Security Admin to grant you the Upgrade Debugger (`upgrade-debugger-cp`) role.\n\nVerify certificate rotation is required\n---------------------------------------\n\nVerify a package validation certificate rotation is required before\nperforming the operation:\n\n1. Set the `KUBECONFIG` environment variable:\n\n $ KUBECONFIG=\u003cvar translate=\"no\"\u003ePATH_TO_KUBECONFIG_FILE\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003ePATH_TO_KUBECONFIG_FILE\u003c/var\u003e with the path to the\n [`kubeconfig` file that you obtained](/distributed-cloud/hosted/docs/latest/appliance/resources/gdcloud-auth) by\n running `gdcloud auth login` in the root admin cluster.\n2. Determine if an upgrade is required by comparing the current trust anchor to the\n latest trust anchor. The `ConfigMap` data at `harbor-system/package-validation-root-certs`\n is compared against the local trust anchor:\n\n $ CURRENT_TRUST_ANCHOR=$(kubectl --kubeconfig=$KUBECONFIG get cm package-validation-root-certs -n harbor-system -o jsonpath='{.data.ca\\.crt}')\n\n $ LATEST_TRUST_ANCHOR=$(cat /root/release/staging_root_ca_certificate.crt)\n\n $ diff \u003c( echo \"$CURRENT_TRUST_ANCHOR\" ) \u003c( echo \"$LATEST_TRUST_ANCHOR\" ) && echo trust anchors are same || echo trust anchors are different, upgrade required!\n\nPerform certificate rotation and upgrade on the appliance\n---------------------------------------------------------\n\nPerform the following steps to rotate the `ConfigMap` object located at\n`harbor-system/package-validation-root-certs` in the root admin cluster. The\nInfrastructure Operator needs write access to the `ConfigMap`.\n\n1. Create and assign values to the following variables:\n\n USERNAME=\u003cvar translate=\"no\"\u003eUSER_NAME\u003c/var\u003e #IO\n TARGET_FOLDER=/tmp/${USERNAME}\n OUTPUT=\"${TARGET_FOLDER}/package-validation-root-certs.yaml\"\n LATEST_TRUST_ANCHOR_CA_FILE=/root/release/staging_root_ca_certificate.crt\n CONFIGMAP_NAME=package-validation-root-certs\n NAMESPACE=harbor-system\n\n Replace \u003cvar translate=\"no\"\u003eUSER_NAME\u003c/var\u003e with the IO username.\n2. Create the target folder that will contain the output files from the certificate rotation process:\n\n mkdir -p \"${TARGET_FOLDER}\"\n\n3. Update and replace the value of `LATEST_TRUST_ANCHOR`:\n\n cat \u003c\u003cEOF \u003e \"${OUTPUT}\"\n apiVersion: v1\n kind: ConfigMap\n metadata:\n name: ${CONFIGMAP_NAME}\n namespace: ${NAMESPACE}\n data:\n ca.crt: |\n $(sed 's/^/ /' \"${LATEST_TRUST_ANCHOR_CA_FILE}\")\n EOF\n\n4. Apply the new configuration with `kubectl`:\n\n kubectl apply -f ${OUTPUT}\n\n5. Ensure that the newly applied ca.crt is present within the `ConfigMap`:\n\n kubectl describe configmap package-validation-root-certs -n harbor-system\n\nThis takes care of rotating a new certificate in the `package-validation-root-cert`."]]