使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
常见问题解答
什么是 Certificate Authority Service?
Certificate Authority Service 是一项可用性高、可扩缩的 Google Cloud 服务,可帮助客户简化、自动执行和自定义私有证书授权机构 (CA) 的部署、管理和安全维护,同时掌控其私钥。
证书颁发机构服务的常见用例有哪些?
以下是 CA 服务的一些常见用例。
- 工作负载身份:利用 API 为应用获取证书,或在应用、容器、系统和其他资源中使用证书。
- 企业场景:使用证书来实现 VPN、Chrome Enterprise 进阶版、签署文档、Wi-Fi 访问、电子邮件、智能卡等功能。
- 集中式证书颁发和管理:将 GKE Enterprise Service Mesh 配置为使用 CA Service。
- IoT 和移动设备身份:颁发 TLS 证书作为端点的身份。
- CI/CD 渠道、二进制授权、Istio 和 Kubernetes。
CA Service 支持哪些合规性标准?
如需了解详情,请参阅安全和合规性。
我们可以在哪些位置创建 CA 服务资源?
您可以在多个位置之一创建 CA 服务资源。如需查看位置的完整列表,请参阅位置。
CA Service 是否支持单个根下的全球 PKI?
可以,前提是根 CA 位于单个区域。不过,您可以在不同区域中创建多个颁发 CA,并将它们链接到同一根 CA。
CA 是否支持标签?
可以,您可以在创建和更新操作期间将标签与 CA 池和 CA 相关联。
如需了解如何更新 CA 池中的标签,请参阅更新 CA 池中的标签。
如需了解如何更新 CA 上的标签,请参阅更新 CA 上的标签。
可以使用 Cloud Monitoring 跟踪证书创建和 CA 到期时间吗?是否可以为它们生成 Pub/Sub 事件?
可以,您可以监控所有这些事件。CA 服务不原生支持 Pub/Sub,但您可以使用 Cloud Monitoring 进行配置。如需了解详情,请参阅将 Cloud Monitoring 与 CA 服务搭配使用。
未启用的 CA 会保留多长时间?
从属 CA 在创建时处于 AWAITING_USER_ACTIVATION
状态,并会在激活后设为 STAGED
状态。如果从属 CA 在创建 30 天后仍处于 AWAITING_USER_ACTIVATION
状态,则会被删除。
如需了解 CA 在其生命周期中的各种状态,请参阅证书授权机构状态。
CA Service 支持哪些证书颁发访问控制功能?
CA Service 支持在 CA 池上设置 IAM 政策,以控制谁可以颁发证书。CA 管理员可以将颁发政策附加到 CA 池。此颁发政策定义了对 CA 池中的 CA 可以颁发的证书类型的限制。这些限制包括对域名、扩展程序和证书有效期等方面施加限制。
如需详细了解如何在 CA 池中配置颁发政策,请参阅使用颁发政策。
如需了解如何配置必要的 IAM 政策以创建和管理 CA 服务资源,请参阅配置 IAM 政策。
CA Service 是否支持多区域 Cloud KMS 密钥?
不支持,CA Service 不支持多区域 Cloud KMS 密钥。
CA Service 是否会限制我的请求?CA 服务的目标 QPS 是多少?
是的,CA 服务存在节流机制。如需了解详情,请参阅配额和限制。
CA 服务是否支持 VPC Service Controls?
是,CA 服务支持 VPC Service Controls。如需了解详情,请参阅支持的产品和限制 > Certificate Authority Service 和安全和合规性。
PEM 编码的公钥应如何与 REST API 搭配使用?
PEM 编码的公钥只有在经过 Base64 编码后才能与 REST API 搭配使用。
CA Service 宣布正式版 (GA) 后,还能使用预览版阶段的 API 吗?
可以,在 CA 服务宣布正式版 API 后,预览版 API 仍可在短时间内使用。此时间段仅供客户顺利过渡到使用最新 API,时间较短且支持有限。我们建议客户在 GA API 推出后尽快改用。
CA Service 宣布正式版 (GA) 后,如何访问在预览期间创建的资源?
您无法使用 Google Cloud 控制台查看或管理在预览期间创建的资源。如需管理在预览期间创建的资源,请使用预览版 API 或预览版 gcloud
命令。您可以通过 https://privateca.googleapis.com/v1beta1/
端点访问预览版 API。您可以通过 gcloud privateca beta
访问预览版 gcloud
命令。如需详细了解 gcloud privateca beta
命令,请参阅 gcloud privateca Beta 版。
是否可以使用与其链中的另一个 CA 相同的正文和密钥创建从属 CA?
不可以,从属 CA 不能与根 CA 或其链中的任何其他 CA 具有相同的正文和密钥。RFC 4158 建议在路径中不重复使用正文名称和公钥对。
客户管理的 Cloud KMS 密钥与 CMEK 是否相同?
不可以,CA 服务支持的客户管理的 Cloud KMS 密钥与使用 Cloud KMS 管理的客户管理的加密密钥 (CMEK) 不同。在 CA Service 中,您可以为企业级别的 CA 创建自己的客户管理的 Cloud KMS 密钥(也称为 BYO 密钥)。这些密钥用作 CA 的签名密钥,而 CMEK 等加密密钥则用于在受支持的 Google Cloud 服务中加密静态数据。CA Service 不支持 CMEK。
资源被删除后,可以重复使用资源名称吗?
不可以,在原始资源被删除后,CA 池、CA 和证书模板等资源名称无法在新资源中重复使用。例如,如果您创建了一个名为 projects/Charlie/locations/Location-1/caPools/my-pool
的 CA 池,然后删除了该 CA 池,则无法在项目 Charlie
和位置 Location-1
中再创建一个名为 my-pool
的 CA 池。
后续步骤
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-12。
[[["易于理解","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-08-12。"],[[["\u003cp\u003eCertificate Authority Service (CA Service) is a scalable Google Cloud service for managing private certificate authorities, including their deployment, management, and security, while maintaining control of private keys.\u003c/p\u003e\n"],["\u003cp\u003eCommon use cases for CA Service include securing workload identities, enterprise scenarios like VPN and document signing, centralized certificate management, and providing identity for IoT and mobile devices.\u003c/p\u003e\n"],["\u003cp\u003eCA Service supports IAM policies to control certificate issuance, allowing administrators to define restrictions on domain names, extensions, and validity periods.\u003c/p\u003e\n"],["\u003cp\u003eWhile CA Service does not directly support Pub/Sub, you can monitor events like certificate creation and CA expiration using Cloud Monitoring and configure Pub/Sub events through it.\u003c/p\u003e\n"],["\u003cp\u003eCA Service has some limitations such as not supporting multi-region Cloud KMS keys, and resource names cannot be reused after deletion; additionally, preview APIs will have limited support after general availability.\u003c/p\u003e\n"]]],[],null,["# Frequently asked questions\n==========================\n\nWhat is Certificate Authority Service?\n--------------------------------------\n\nCertificate Authority Service is a highly available, scalable Google Cloud service that enables customers to simplify, automate, and customize the deployment, management, and security of private certificate authorities (CAs) while staying in control of their private keys.\n\nWhat are the common use cases for Certificate Authority Service?\n----------------------------------------------------------------\n\nGiven below are some common use cases for CA Service.\n\n- **Workload identities**: Leverage APIs to get certificates for applications or use certificates in applications, containers, systems, and other resources.\n- **Enterprise scenarios**: Use certificates for VPN, Chrome Enterprise Premium, signing documents, WiFi access, email, smartcard, and more.\n- **Centralized certificate issuance and management**: Configure GKE Enterprise Service Mesh to use CA Service.\n- **IoT and mobile device identity**: Issue TLS certificates as identity for endpoints.\n- CI/CD channel, Binary Authorization, Istio, and Kubernetes.\n\nWhich compliance standards does CA Service support?\n---------------------------------------------------\n\nFor information, see [Security and Compliance](/certificate-authority-service/docs/certificate-authority-compliance).\n\nWhich locations can we create CA Service resources in?\n------------------------------------------------------\n\nCA Service resources can be created in one of many locations. For the complete list of locations, see [Locations](/certificate-authority-service/docs/locations).\n\nDoes CA Service support a global PKI under a single root?\n---------------------------------------------------------\n\nYes, provided the root CA lives in a single region. However, you can create multiple issuing CAs in different regions that chain up to the same root.\n\nAre labels supported for CAs?\n-----------------------------\n\nYes, you can associate labels to CA pools and CAs during create and update operations.\n\nFor information on updating labels on a CA pool, see [Updating labels on a CA pool](/certificate-authority-service/docs/operations-ca-pool#update-labels).\n\nFor information on updating labels on a CA, see [Updating labels on a CA](/certificate-authority-service/docs/updating-certificate-authorities#update-labels).\n\nIs it possible to use Cloud Monitoring to track certificate creation and CA expiration? Is it possible to generate Pub/Sub events for them?\n-------------------------------------------------------------------------------------------------------------------------------------------\n\nYes, you can monitor all of these events. CA Service does not natively support [Pub/Sub](/pubsub/docs) but you can configure it using [Cloud Monitoring](/monitoring/docs). For more information, see [Using Cloud Monitoring with CA Service](/certificate-authority-service/docs/monitoring).\n\nHow long are unactivated CAs retained?\n--------------------------------------\n\nSubordinate CAs are created in the `AWAITING_USER_ACTIVATION` state, and they are set to the `STAGED` state after activation. If a subordinate CA is still in the `AWAITING_USER_ACTIVATION` state 30 days after it has been created, it is deleted.\n\nFor information about the various states a CA is in through its lifecycle, see [Certificate authority states](/certificate-authority-service/docs/certificate-authority-states).\n\nWhat access controls does CA Service support for certificate issuance?\n----------------------------------------------------------------------\n\nCA Service supports setting IAM policies on a CA pool to control who can issue certificates. A CA admin can attach an issuance policy to a CA pool. This issuance policy defines restrictions on the type of certificates that the CAs in a CA pool can issue. These restrictions include placing limits on domain name, extensions, and certificate validity period, among other things.\n\nFor more information on how to configure an issuance policy on a CA pool, see [Using an issuance policy](/certificate-authority-service/docs/use-issuance-policy).\n\nFor information on how to configure the necessary IAM policies for creating and managing CA Service resources, see [Configuring IAM policies](/certificate-authority-service/docs/configuring-iam).\n\nDoes CA Service support multi-region Cloud KMS keys?\n----------------------------------------------------\n\nNo, CA Service does not support multi-region Cloud KMS keys.\n\nWill CA Service ever throttle my requests? What is the target QPS for CA Service?\n---------------------------------------------------------------------------------\n\nYes, there exists a throttling mechanism for CA Service. For more information, see [Quotas and limits](../quotas).\n\nDoes CA Service support VPC Service Controls?\n---------------------------------------------\n\nYes, CA Service supports VPC Service Controls. For more information, see [Supported products and limitations \\\u003e Certificate Authority Service](/vpc-service-controls/docs/supported-products#table_cas) and [Security and Compliance](/certificate-authority-service/docs/certificate-authority-compliance).\n\nHow are PEM encoded public keys supposed to be used with REST APIs?\n-------------------------------------------------------------------\n\nPEM encoded public keys can only be used with REST APIs after they have been Base64 encoded.\n\nCan preview stage APIs still be used after CA Service announces general availability (GA)?\n------------------------------------------------------------------------------------------\n\nYes, preview APIs can still be used for a short period after CA Service announces GA. This period is only intended for customers to smoothly transition to using the latest APIs and will be short-lived with limited support. We recommend that customers migrate to using the GA APIs as soon as they are available.\n\nHow can resources created during the preview period be accessed after CA Service announces general availability (GA)?\n---------------------------------------------------------------------------------------------------------------------\n\nYou cannot view or manage resources created during the preview period using the Google Cloud console.\nTo manage resources created during preview, use the preview APIs or the preview `gcloud` commands.\nThe preview APIs are accessible through the `https://privateca.googleapis.com/v1beta1/` endpoint.\nThe preview `gcloud` commands are accessible through `gcloud privateca beta`. For more information about `gcloud privateca beta` commands, see [gcloud privateca beta](/sdk/gcloud/reference/beta/privateca).\n\nCan a subordinate CA be created with the same subject and key as another CA in its chain?\n-----------------------------------------------------------------------------------------\n\nNo, a subordinate CA cannot have the same subject and key as the root CA, or any other CA in its chain. [RFC 4158](https://datatracker.ietf.org/doc/html/rfc4158#section-2.2) recommends that subject names and public key pairs are not repeated in paths.\n\nAre customer-managed Cloud KMS keys the same as CMEK?\n-----------------------------------------------------\n\nNo, the [customer-managed Cloud KMS\nkeys](/certificate-authority-service/docs/managed-resources#customer-managed)\nsupported in CA Service aren't the same as [customer-managed encryption keys\n(CMEK)](/kms/docs/cmek#cmek) that are managed using Cloud KMS. In CA Service,\nyou can create your own customer-managed Cloud KMS keys (also known as BYO-key), for CAs in the Enterprise tier. These keys are used as the CA's signing key\nunlike encryption keys like CMEK that are used to encrypt data at rest within\nsupported Google Cloud services. CA Service doesn't support CMEK.\n\nCan resource names be reused after the resource is deleted?\n-----------------------------------------------------------\n\nNo, resource names such as the names of CA pools, CAs, and certificate templates can't be reused in a new resource after the original resource\nis deleted. For example, if you create a CA pool called `projects/Charlie/locations/Location-1/caPools/my-pool`, and then delete the CA\npool, you can't create another CA pool called `my-pool` in the project `Charlie` and location `Location-1`.\n\nWhat's next\n-----------\n\n- Learn about the [known limitations](/certificate-authority-service/docs/known-limitations).\n- Read the [release notes](/certificate-authority-service/docs/release-notes).\n- Learn how you can [get support](/certificate-authority-service/docs/getting-support)."]]