[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間: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`."]]