公開 CA

驗證憑證要求者是否控管網域後,您可以使用公開憑證授權單位 CA 來佈建及部署廣泛信任的 X.509 憑證。公開 CA 可讓您以程式輔助方式直接要求公開信任的 TLS 憑證,這些憑證已位於主要瀏覽器、作業系統和應用程式使用的信任存放區根目錄中。您可以使用這些 TLS 憑證來驗證及加密網際網路流量。

公開 CA 可讓您管理傳統 CA 無法支援的高大量用途。如果您是 Google Cloud 客戶,可以直接向公開 CA 索取網域的 TLS 憑證。

大多數憑證相關問題都是人為錯誤或疏失所致,因此建議您自動化憑證生命週期。公開 CA 會使用 自動化憑證管理環境 (ACME) 通訊協定,自動佈建、更新及撤銷憑證。自動化憑證管理可減少過期憑證可能造成的停機時間,並將營運成本降到最低。

公開 CA 會為多項 Google Cloud服務提供 TLS 憑證,例如 App EngineCloud ShellGoogle Kubernetes EngineCloud Load Balancing

適合使用公開 CA 的對象

您可以基於下列原因使用公開 CA:

  • 如果您需要具備高普及性、可擴充性、安全性和可靠性的 TLS 供應商。
  • 您想從單一雲端服務供應商取得大部分 (如果不是全部) 基礎架構的 TLS 憑證,包括地端工作負載和跨雲端供應商設定。
  • 如需控管 TLS 憑證管理作業,並根據基礎架構需求進行自訂,
  • 如果您想自動化 TLS 憑證管理作業,但無法在 Google Cloud 服務 (例如 GKECloud Load Balancing) 中使用代管憑證。

建議您只在業務需求不允許其他選項時,才使用公開信任的憑證。考量到維護公開關鍵基礎架構 (PKI) 階層的歷史成本和複雜性,許多企業會使用公開 PKI 階層,即使私人階層更合理也一樣。

有了多項Google Cloud 服務,維護公開和私人階層變得更加簡單。建議您根據用途,謹慎選擇正確的 PKI 類型。

針對非公開憑證規定, Google Cloud 提供兩種易於管理的解決方案:

Public CA 的優點

公開 CA 提供下列優點:

  • 自動化:由於網際網路瀏覽器的目標是完全加密流量,並縮短憑證的有效期限,因此使用已過期的 TLS 憑證會有風險。憑證到期可能會導致網站錯誤,並導致服務中斷。公開 CA 會讓您設定 HTTPS 伺服器,自動取得並更新 ACME 端點的必要 TLS 憑證,避免憑證過期的問題。

  • 法規遵循:公開 CA 會定期接受嚴格的獨立稽核,確保安全性、隱私權和法規遵循控管機制符合相關規範。這些年度稽核結果授予的 Webtrust 標章,證明 Public CA 符合所有相關業界標準。

  • 安全性:公共 CA 的架構和運作方式符合最高安全標準,並定期執行獨立評估,確認基礎結構安全無虞。公開 CA 必須符合或超越 Google 安全性白皮書中所述的所有控制項、作業做法和安全措施。

    公開 CA 的安全性重點涵蓋多重觀點網域驗證等功能。公開 CA 的基礎架構遍布全球。因此,公用 CA 需要在不同地理位置的角度上達成高度一致,以便防範邊界閘道協定 (BGP) 劫持網域名稱伺服器 (DNS) 劫持攻擊。

  • 可靠性:使用 Google 經過驗證的技術基礎架構,可讓 Public CA 成為高可用且可擴充的服務。

  • 普及性:Google Trust Services 的強大瀏覽器普及性有助於確保使用公用 CA 核發憑證的服務,可在盡可能廣泛的裝置和作業系統上運作。

  • 混合設定的簡化 TLS 解決方案:公開 CA 可讓您建立自訂 TLS 憑證解決方案,在各種情境和用途中使用相同的 CA。公用 CA 可有效支援在內部部署環境或跨雲供應商環境中執行工作負載的用途。

  • 擴充:取得憑證通常成本高昂,且難以佈建及維護。透過提供大量憑證的存取權,Public CA 讓您以先前認為不切實際的方式使用及管理憑證。

在憑證管理工具中使用公開 CA

如要使用憑證管理工具的公開 CA 功能,您必須熟悉下列概念:

  • ACME 用戶端。自動化憑證管理環境 (ACME) 用戶端是使用 ACME 通訊協定的憑證管理用戶端。ACME 用戶端必須支援外部帳戶繫結 (EAB),才能與公開 CA 搭配運作。

  • 外部帳戶繫結 (EAB)。您必須使用外部帳戶繫結功能,將使用 Certificate Manager 公開 CA 的每個 ACME 帳戶繫結至目標 Google Cloud 專案。為此,您必須使用與對應 Google Cloud 專案相關聯的秘密,註冊每個 ACME 帳戶。詳情請參閱「外部帳戶繫結」。

公開 CA 的挑戰

使用公開 CA 要求憑證時,憑證管理工具會要求您證明自己控制憑證中列出的網域。您可以透過解決驗證挑戰來證明網域控管權。您必須證明自己控制目標網域,公開 CA 才會授權網域名稱。

取得必要授權後,您可以要求只在特定時間內有效的憑證。在這個期限過後,您必須解決三種驗證類型之一,才能繼續要求憑證。

驗證類型

公開 CA 支援下列驗證類型:

  • HTTP 挑戰。這項挑戰涉及在 HTTP 伺服器 (通訊埠 80) 的知名位置建立檔案,供公開 CA 擷取及驗證。詳情請參閱「HTTP 驗證」。

  • TLS-Application Layer Protocol Negotiation (ALPN) 挑戰。要求伺服器在 443 埠的 TLS 協商期間提供特定憑證,以證明對網域的控管權。詳情請參閱「ACME TLS-ALPN 挑戰擴充功能」。

  • DNS 挑戰。需要在特定位置新增特定 DNS 記錄,證明您對網域有控制權。詳情請參閱「DNS 挑戰」。

如果您使用 HTTP 挑戰或 TLS-ALPN 挑戰來驗證網域名稱,用戶端只能要求將已驗證的網域名稱納入憑證。如果您使用 DNS 挑戰,用戶端也可以要求將該網域名稱的子網域納入憑證。

舉例來說,如果您使用 DNS 驗證機制驗證 *.myorg.example.com,則萬用字元憑證會自動涵蓋 subdomain1.myorg.example.comsubdomain2.myorg.example.com。不過,如果您使用 HTTP 或 TLS-ALPN 驗證挑戰來驗證 myorg.example.com,用戶端只能要求在憑證中加入 myorg.example.com,您無法使用非 DNS 驗證挑戰來驗證 *.myorg.example.com

挑戰解決方案邏輯

公開 CA 挑戰的邏輯如下:

  1. 公開 CA 會提供隨機權杖。
  2. 用戶端會在明確定義的位置提供權杖。位置取決於挑戰。
  3. 用戶端會向 Public CA 指出已準備好挑戰。
  4. 公開 CA 會檢查預期位置中的符記是否符合預期值。

完成這項程序後,系統就會授權網域名稱。用戶端可以要求含有該網域名稱的憑證。每個網域名稱只需解決一項挑戰。

後續步驟