您可以使用 Public Certificate Authority 来预配和部署广受信任的 X.509 证书，前提是您已验证证书请求者控制着相关网域。借助 Public CA，您可以直接以程序化方式请求已位于主要浏览器、操作系统和应用所使用的信任存储区信任根中的公开受信任的 TLS 证书。您可以使用这些 TLS 证书来验证互联网流量并对其进行加密。
借助 Public CA，您可以管理其他 CA 无法支持的大批量使用场景。如果您是 Google Cloud 客户，可以 直接通过 Public CA 为您的网域请求 TLS 证书。
大多数与证书相关的问题都是人为错误或疏忽造成的，因此我们建议您自动执行证书生命周期。Public CA 使用 自动证书管理环境 (ACME) 协议来自动预配、续订和撤消 证书。自动证书管理可以减少证书过期可能造成的停机时间，并最大限度地降低运营费用。
Public CA 为多种 Google Cloud 服务预配 TLS 证书，例如 App Engine、Cloud Shell、 Google Kubernetes Engine 和 Cloud Load Balancing。
Public CA 的适用对象
您可以使用 Public CA，原因如下：
- 如果您正在寻找具有高普及率、可伸缩性、安全性和可靠性的 TLS 提供商。
- 如果您希望从单个云提供商处获取基础架构（包括本地工作负载和跨云提供商设置）的大部分（如果不是全部）TLS 证书。
- 如果您需要控制 TLS 证书管理并灵活地对其进行自定义，以满足您的基础架构要求。
- 如果您想要自动执行 TLS 证书管理，但无法在 托管式证书中 Google Cloud 使用服务，例如 GKE 或 Cloud Load Balancing。
我们建议您仅在业务要求不允许其他选项时才使用公开受信任的证书。鉴于维护公钥基础架构 (PKI) 层次结构的成本和复杂性，许多企业即使私有层次结构更有意义，也会使用公共 PKI 层次结构。
借助多种产品，维护公共和私有层次结构变得更加简单。Google Cloud 我们建议您仔细选择适合您的使用场景的 PKI 类型。
对于非公共证书要求， Google Cloud 提供了两种易于管理的 解决方案：
Anthos Service Mesh：Cloud Service Mesh 包含针对在 GKE Enterprise 中运行的工作负载的全自动 mTLS 证书预配，该预配使用 Cloud Service Mesh 证书授权机构（Cloud Service Mesh 证书授权机构）。
Certificate Authority Service: Certificate Authority Service：借助 Certificate Authority Service，您可以高效地部署、 管理和保护自定义私有 CA，而无需管理 基础架构。
Public CA 的优势
Public CA 具有以下优势：
自动化：由于互联网浏览器旨在实现完全加密的流量并 缩短证书有效期，因此存在使用 过期 TLS 证书的风险。证书过期可能会导致网站错误，并可能导致服务中断。Public CA 可让您将 HTTPS 服务器设置为自动从我们的 ACME 端点获取和续订必要的 TLS 证书，从而避免证书过期问题。
合规性：Public CA 会定期接受安全性、隐私保护和合规性控制方面的严格独立 审核。通过这些年度审核获得的 Webtrust 徽章 表明 Public CA 符合所有相关的 行业标准。
安全性：Public CA 的架构和运营均按照最高安全标准设计，并定期进行独立评估，以确认底层基础架构的安全性。Public CA 符合或超出 Google 安全性白皮书中提及的所有控制措施、运营实践和安全措施。
Public CA 对安全性的关注还扩展到了多视角网域验证等功能。Public CA 的基础架构在全球范围内分布。因此，Public CA 需要在地理位置不同的视角之间达成高度一致，这可以防范边界网关协议 (BGP) 劫持和域名服务器 (DNS) 劫持攻击。
可靠性：Public CA 使用 Google 经过验证的技术基础架构，因此是一项高可用性且可伸缩的服务。
普及性：Google Trust Services 具有强大的浏览器普及性，有助于确保使用 Public CA 颁发的 证书的服务可以在尽可能多的设备和操作系统上运行。
针对混合设置的简化 TLS 解决方案：借助 Public CA，您可以构建自定义 TLS 证书解决方案，该解决方案针对各种场景和使用场景使用相同的证书授权机构 (CA)。Public CA 可有效服务于工作负载在本地或跨云提供商环境中运行的使用场景。
规模：证书的获取成本通常很高，并且难以 预配和维护。Public CA 提供对大量证书的访问权限，让您能够以以前被认为不切实际的方式使用和管理证书。
将 Public CA 与 Certificate Manager 搭配使用
如需使用 Certificate Manager 的 Public CA 功能，您必须熟悉以下概念：
ACME 客户端 。自动证书管理环境 (ACME) 客户端是使用 ACME 协议的证书 管理客户端。 您的 ACME 客户端必须支持外部账号绑定 (EAB)，才能与 Public CA 搭配使用。
外部账号绑定 (EAB) 。您必须使用外部账号绑定将您使用的每个 ACME 账号与 Certificate Manager Public CA 绑定到目标 Google Cloud 项目。为此，您必须使用与相应 Google Cloud 项目关联的密钥注册每个 ACME 账号。如需了解详情，请参阅外部账号 绑定。
Public CA 验证挑战
当您使用 Public CA 请求证书时，Certificate Manager 会要求您证明您对该证书中列出的网域的控制权。您可以通过解决验证挑战来证明网域控制权。 在您证明对目标网域的控制权后，Public CA 会授权相应域名。
获得所需的授权后，您可以请求仅在特定时长内有效的证书。在此时长之后，您必须通过解决三种验证挑战类型之一来重新验证域名，才能继续请求证书。
验证挑战类型
Public CA 支持以下类型的验证挑战：
HTTP 验证挑战 。此验证挑战涉及在 HTTP 服务器（端口 80）上的已知位置创建一个文件，供 Public CA 检索和验证。如需了解详情，请参阅 HTTP 验证挑战。
TLS-应用层协议协商 (ALPN) 验证挑战 。要求服务器在端口 443 上的 TLS 协商期间提供特定证书，以证明对网域的控制权。如需了解详情，请参阅 ACME TLS-ALPN 验证挑战扩展。
DNS 验证挑战 。要求在定义的位置添加特定 DNS 记录，以证明对网域的控制权。 如需了解详情，请参阅 DNS 验证挑战。
如果您使用 HTTP 验证挑战或 TLS-ALPN 验证挑战来验证域名，客户端只能请求将经过验证的域名包含在证书中。如果您使用 DNS 验证挑战，客户端还可以请求将该域名的子网域包含在证书中。
例如，如果您使用 DNS 验证挑战验证 *.myorg.example.com，则 subdomain1.myorg.example.com 和
subdomain2.myorg.example.com 会自动包含在通配符证书中。但是，如果您使用 HTTP 或
TLS-ALPN 验证挑战验证 myorg.example.com，客户端只能请求将 myorg.example.com 包含在
证书中，并且您无法使用非 DNS 验证挑战验证 *.myorg.example.com。
验证挑战解决逻辑
Public CA 验证挑战逻辑如下：
- Public CA 提供随机令牌。
- 客户端在明确定义的位置提供令牌。该位置取决于验证挑战。
- 客户端向 Public CA 表明它已准备好验证挑战。
- Public CA 检查预期位置中的令牌是否与预期值匹配。
此过程完成后，域名即获得授权。客户端可以请求包含该域名的证书。您只需为每个域名解决一个验证挑战。