使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Certificate Authority Service 概览
Certificate Authority Service (CA Service) 是一项可扩缩性极高的Google Cloud 服务，可帮助您简化和自动执行私有证书授权机构 (CA) 的部署、管理和安全维护。私有证书授权机构颁发数字证书，其中包括实体身份、颁发者身份和加密签名。私钥证书是通过网络对用户、计算机或服务进行身份验证的最常用方法之一。私钥证书通常用于 DevOps 环境，用于保护容器、微服务、虚拟机和服务账号。
使用 CA Service，您可以执行以下操作：
- 创建自定义根 CA 和从属 CA。
- 定义 CA 的主题、密钥算法和位置。
- 选择从属 CA 的区域，该区域可以与其根 CA 的区域无关。
- 针对常见的证书颁发场景创建可重复使用且可参数化的模板。
- 您可以自行提供根 CA，并配置其他 CA 以链接到在本地或 Google Cloud之外的任何其他位置运行的现有根 CA。
- 使用 Cloud HSM 存储您的私有 CA 密钥，Cloud HSM 已通过 FIPS 140-2 3 级认证，可在美洲、欧洲和亚太的多个区域使用。
- 借助 Cloud Audit Logs，可获取日志，清楚地了解谁在何时、何地执行过哪些操作。
- 使用 Identity and Access Management (IAM) 定义精细的访问权限控制机制，使用 VPC Service Controls 定义虚拟安全边界。
- 管理大量证书。CA 服务支持每个 CA 每秒最多颁发 25 个证书（DevOps 层级），这意味着每个 CA 可以颁发数百万个证书。您可以在一个颁发端点（称为 CA 池）后面创建多个 CA，并将传入的证书请求分配给所有 CA。借助此功能，您最多每秒可有效颁发 100 个证书。
- 您可以使用 API、Google Cloud CLI、 Google Cloud 控制台或 Terraform 等对您而言最方便的方式管理和集成私有 CA，并自动进行部署。
证书用例
您可以使用私有 CA 为以下用例颁发证书：
- 软件供应链完整性和代码身份：代码签名、工件身份验证和应用身份证书。
- 用户身份：客户端身份验证证书，用于作为零信任网络、VPN、文档签名、电子邮件、智能卡等的用户身份。
- IoT 和移动设备身份：用作设备身份和身份验证的客户端身份验证证书，例如无线访问。
- 服务内身份：微服务使用的 mTLS 证书。
- 持续集成和持续交付 (CI/CD) 渠道：在整个 CI/CD 构建过程中使用的代码签名证书，用于提高代码完整性和安全性。
- Kubernetes 和 Istio：用于保护 Kubernetes 和 Istio 组件之间连接的证书。
为何选择私有 PKI
在典型的 Web 公钥基础架构 (PKI) 中，全球数百万客户信任一组独立的证书授权机构 (CA)，以便在证书中声明身份（例如域名）。作为其职责的一部分，CA 承诺仅在独立验证证书中的身份后才颁发证书。例如，CA 通常需要先验证请求为域名 example.com 颁发证书的用户是否实际控制该域名，然后才能向其颁发证书。由于这些 CA 可以为数百万客户颁发证书，而这些客户可能与其之间没有现有的直接关系，因此它们只能声明可公开验证的身份。这些 CA 仅限于在 Web PKI 中始终如一地应用的特定明确验证流程。
与 Web PKI 不同，私有 PKI 通常涉及更小的 CA 层次结构，该层次结构由组织直接管理。私有 PKI 仅向本质上信任组织具有适当控制措施的客户端（例如，归该组织所有的机器）发送证书。由于 CA 管理员通常有自己的方法来验证要为其颁发证书的身份（例如，向自己的员工颁发证书），因此他们不受与 Web PKI 相同的要求的限制。这种灵活性是私有 PKI 相较于 Web PKI 的主要优势之一。私有 PKI 支持新的用例，例如使用短域名保护内部网站（无需对这些名称拥有唯一所有权），或将备选身份格式（例如 SPIFFE ID）编码到证书中。
此外，Web PKI 要求所有 CA 将其签发的每张证书记录到公共证书透明度日志中，但对于向其内部服务签发证书的组织，可能不需要这样做。借助私有 PKI，组织可以将其内部基础架构拓扑（例如网络服务或应用的名称）对世界其他地方保持私密。
后续步骤
如未另行说明，那么本页面中的内容已根据知识共享署名 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 and securing private certificate authorities (CAs), which are used for authenticating users, machines, or services over networks.\u003c/p\u003e\n"],["\u003cp\u003eCA Service allows the creation of custom root and subordinate CAs, and includes features such as customizable templates, bring-your-own root CA, secure key storage with Cloud HSM, audit logging, and granular access controls.\u003c/p\u003e\n"],["\u003cp\u003eCA Service supports high-volume certificate issuance, up to 25 certificates per second per CA, with the ability to create multiple CAs behind one CA pool to issue up to 100 certificates per second.\u003c/p\u003e\n"],["\u003cp\u003ePrivate CAs are advantageous over Web PKI because they allow organizations greater flexibility in validating identities and enable use cases like securing internal sites with short domain names and encoding alternative identity formats.\u003c/p\u003e\n"],["\u003cp\u003ePrivate CAs also offer enhanced privacy, as they do not require public logging of issued certificates, thus allowing organizations to keep their internal network structure confidential.\u003c/p\u003e\n"]]],[],null,["# Certificate Authority Service overview\n======================================\n\nCertificate Authority Service (CA Service) is a highly scalable\nGoogle Cloud service that lets you simplify and automate the\ndeployment, management, and security of private certificate authorities (CA).\nPrivate CAs issue digital certificates that include entity identity, issuer identity,\nand cryptographic signatures. Private certificates are one of the most common\nways to authenticate users, machines, or services over networks. Private\ncertificates are often used in DevOps environments to protect\ncontainers, microservices, virtual machines, and service accounts.\n\nUsing CA Service, you can do the following:\n\n- Create custom root and subordinate CAs.\n- Define the subject, key algorithm, and location of the CA.\n- Select a subordinate CA's region independent of its root CA's region.\n- Create reusable and parameterized templates for common certificate issuance scenarios.\n- Bring your own root CA and configure other CAs to chain up to the existing root CA running on-premises or anywhere else outside Google Cloud.\n- Store your private CA keys using [Cloud HSM](/kms/docs/hsm), which is FIPS 140-2 Level 3 validated and available in several regions across the Americas, Europe, and Asia Pacific.\n- Obtain logs and gain visibility into who did what, when, and where with [Cloud Audit Logs](/audit-logs).\n- Define granular access controls with [Identity and Access Management (IAM)](/iam) and virtual security perimeters with [VPC Service Controls](/vpc-service-controls?hl=en).\n- Manage high volumes of certificates knowing that CA Service supports issuing up to 25 certificates per second per CA (DevOps tier), which means that each CA can issue millions of certificates. You can create multiple CAs behind one issuance endpoint called a CA pool and distribute the incoming certificate requests across all the CAs. Using this feature, you can effectively issue up to 100 certificates per second.\n- Manage, automate, and integrate private CAs in whichever way is most convenient for you: using APIs, the Google Cloud CLI, the Google Cloud console, or [Terraform](https://www.terraform.io/).\n\nCertificate use cases\n---------------------\n\nYou can use your private CAs to issue certificates for the following use cases:\n\n- **Software supply chain integrity and code identity**: Code signing, artifact authentication, and application identity certificates.\n- **User identity**: Client authentication certificates used as user identity for zero trust networking, VPN, document signing, email, smartcard, and more.\n- **IoT and mobile device identity**: Client authentication certificates used as device identity and authentication, for example, wireless access.\n- **Intraservice identity**: mTLS certificates used by microservices.\n- **Continuous integration and continuous delivery (CI/CD) channels**: Code signing certificates used throughout the CI/CD build to improve code integrity and security.\n- **Kubernetes and Istio**: Certificates to secure connections between the Kubernetes and Istio components.\n\nWhy choose a private PKI\n------------------------\n\nIn a typical Web Public Key Infrastructure (PKI), millions of clients across the\nworld trust a set of independent certificate authorities (CAs) to assert identities\n(such as domain names) in certificates. As part of their responsibilities, CAs commit\nto only issuing certificates when they have independently validated the identity\nin that certificate. For example, a CA typically needs to verify that\nsomebody requesting a certificate for the domain name `example.com` actually\ncontrols the said domain before they issue a certificate to them. Since those CAs\ncan issue certificates for millions of customers where they might not have an\nexisting direct relationship, they are limited to asserting identities that are\npublicly verifiable. Those CAs are limited to certain well-defined verification\nprocesses that are consistently applied across the Web PKI.\n\nUnlike Web PKI, a private PKI often involves a smaller CA hierarchy, which is\ndirectly managed by an organization. A private PKI sends certificates only to clients\nthat inherently trust the organization to have the appropriate controls (for\nexample, machines owned by that organization). Since the CA admins often have\ntheir own ways of validating identities for which they issue certificates (for\nexample, issuing certificates to their own employees), they aren't limited by\nthe same requirements as for Web PKI. This flexibility is one of the main advantages\nof private PKI over Web PKI. A private PKI enables new use cases such as securing\ninternal websites with short domain names without requiring unique ownership of\nthose names, or encoding alternative identities formats (such\nas [SPIFFE IDs](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)) into\na certificate.\n\nIn addition, the Web PKI requires all CAs to log every certificate they've\nissued to public [Certificate Transparency](https://certificate.transparency.dev/howctworks/)\nlogs, which may not be required for organizations issuing certificates to their\ninternal services. Private PKI allows organizations to keep their internal\ninfrastructure topology, such as the names of their network services or\napplications, private from the rest of the world.\n\nWhat's next\n-----------\n\n- Understand [CA Service pricing](/certificate-authority-service/pricing).\n- Learn about [security and compliance](/certificate-authority-service/docs/certificate-authority-compliance).\n- Review CA Service [locations](/certificate-authority-service/docs/locations).\n- Get started with the [CA Service](/certificate-authority-service/docs/create-certificate)."]]
