驗證憑證申請者控管網域後，即可使用 Public Certificate Authority 佈建及部署廣受信賴的 X.509 憑證。透過 Public CA，您可以直接以程式輔助方式要求公開信任的 TLS 憑證，這類憑證已位於主要瀏覽器、作業系統和應用程式使用的信任根存放區中。您可以使用這些 TLS 憑證驗證及加密網際網路流量。
Public CA 可讓您管理其他 CA 無法支援的大量應用情境。如果您是 Google Cloud 客戶，可以直接向 Public CA 要求網域的 TLS 憑證。
大多數憑證相關問題都是人為錯誤或疏忽所致，因此建議自動化憑證生命週期。Public CA 會使用自動化憑證管理環境 (ACME) 通訊協定，自動佈建、更新及撤銷憑證。自動化憑證管理可減少憑證過期造成的停機時間，並降低營運成本。
Public CA 會為多項服務提供 TLS 憑證，例如 App Engine、Cloud Shell、Google Kubernetes Engine 和 Cloud Load Balancing。 Google Cloud
哪些人適合使用 Public CA
您可以使用 Public CA 來達成以下目的：
- 如果您需要兼具高普及率、擴充性、安全性和可靠性的 TLS 供應商。
- 如果您希望基礎架構的大部分 (甚至所有) TLS 憑證，包括地端部署工作負載和跨雲端服務供應商設定，都來自單一雲端服務供應商。
- 如需控管及彈性管理 TLS 憑證，以便根據基礎架構需求進行自訂。
- 如要自動管理 TLS 憑證，但無法在 Google Cloud 服務 (例如 GKE 或 Cloud Load Balancing) 中使用代管憑證。
只有在業務需求不允許其他選項時，才建議使用公開信任的憑證。由於維護公開金鑰基礎架構 (PKI) 層級的成本高昂且複雜，許多企業即使私有層級更合理，仍會使用公開 PKI 層級。
現在有多種Google Cloud 產品，因此維護公開和私人階層變得簡單許多。建議您根據用途謹慎選擇合適的 PKI 類型。
如需非公開憑證規定， Google Cloud 提供兩種簡單易用的解決方案：
Anthos 服務網格：Cloud Service Mesh 包含完全自動化的 mTLS 憑證佈建功能，適用於使用 Cloud Service Mesh 憑證授權單位 (Cloud Service Mesh 憑證授權單位) 在 GKE Enterprise 中執行的工作負載。
憑證授權單位服務：憑證授權單位服務可讓您有效率地部署、管理及保護自訂私人憑證授權單位，不必費心管理基礎架構。
Public CA 的優點
Public CA 具有下列優點：
自動化：由於網際網路瀏覽器致力於全面加密流量，並縮短憑證效期，因此使用過期的 TLS 憑證可能會造成風險。憑證過期可能會導致網站發生錯誤，甚至造成服務中斷。Public CA 可讓您設定 HTTPS 伺服器，從我們的 ACME 端點自動取得及續訂必要的 TLS 憑證，避免憑證過期問題。
法規遵循：Public CA 會定期接受嚴格的獨立稽核，確保安全性、隱私權和法規遵循控管機制皆符合相關規範。透過這些年度稽核取得的 Webtrust 認證，可證明 Public CA 符合所有相關業界標準。
安全性：Public CA 的架構和作業均以最高安全標準設計，並定期進行獨立評估，確認基礎架構的安全性。Public CA 符合或超出《Google 安全性白皮書》中提及的所有控制項、作業實務和安全措施。
公開 CA 的安全防護重點也涵蓋多種功能，例如多角度網域驗證。公開 CA 的基礎架構遍布全球，因此，Public CA 需要在地理位置多元的觀點之間達成高度共識，以防範邊界閘道通訊協定 (BGP) 劫持和網域名稱伺服器 (DNS) 劫持攻擊。
可靠性：採用 Google 經驗證的技術基礎架構，讓 Public CA 成為高可用性且可擴充的服務。
普及性：Google Trust Services 瀏覽器普及率高，因此使用 Public CA 核發憑證的服務，可確保在各種裝置和作業系統上運作。
簡化混合設定的 TLS 解決方案：Public CA 可讓您建立自訂 TLS 憑證解決方案，在各種情境和用途中使用相同的 CA。如果工作負載是在地端部署或跨雲端服務供應商環境中執行，Public CA 就能有效提供服務。
規模：取得憑證的成本通常很高，而且難以佈建及維護。Public CA 提供大量憑證的存取權，讓您以先前認為不切實際的方式使用及管理憑證。
使用憑證管理員搭配 Public CA
如要使用 Certificate Manager 的 Public CA 功能，您必須熟悉下列概念：
ACME 用戶端。自動化憑證管理環境 (ACME) 用戶端是使用 ACME 通訊協定的憑證管理用戶端。如要搭配 Public CA 使用，ACME 用戶端必須支援外部帳戶繫結 (EAB)。
外部帳戶繫結 (EAB)。您必須使用外部帳戶繫結，將使用的每個 ACME 帳戶與 Certificate Manager Public CA 繫結至目標 Google Cloud 專案。如要這麼做，您必須使用與對應專案連結的密碼，註冊每個 ACME 帳戶。 Google Cloud 詳情請參閱綁定外部帳戶。
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 會檢查預期位置的符記是否與預期值相符。
完成這項程序後，網域名稱就會獲得授權。用戶端可以要求憑證內含該網域名稱。每個網域名稱只需要解決一項挑戰。