為什麼GoDaddy移除ClientAuth EKU並轉入R1根層級進行DV TLS簽發？

由2026年6月15日起，已發行的供伺服器使用的SSL / TLS憑證將不再包含「用戶端驗證」（EKU：clientAuth）延伸金鑰。以下是您需要了解的重點：

• 這項變更是Chrome Root計劃政策更新的一部份：新憑證必須僅包含「伺服器驗證」EKU。
• Chrome不會信任在該日期之後發行的新的公開憑證（包含clientAuth）。
• 在2026年6月15日前透過clientAuth簽發的憑證不會受到這項變更的影響，並會在到期或被撤銷之前一直保持有效。
• 專用CA憑證（供內部使用）不受此變更影響，只適用於公開信任的憑證。

簡而言之：如果您的組織使用公開的TLS憑證進行用戶端驗證（透過clientAuth EKU），您需要在2026年6月15日前執行。如果是標準網站TLS使用方式（僅限伺服器驗證），則不需要進行這項變更。不過，我們會適時提醒您查看使用憑證，適當分開功能，並確保您符合不斷發展的信任模式。

GoDaddy實施這項變更的方式

我們目前的G2簽發/簽發中間體並未列出任何EKU，因此該等級不符合Chrome Root計劃的規範。結果，受影響的G2中繼必須在該日期前停止發布。

與其在G2鏈上建立新的發行中間市場，不如在2027年4月由Google過期/終止—而是將DV發行改為我們的新R1階層，以迎合未來的政策限制。

我們將要變更公開的DV簽發鏈，因此新的DV樹葉憑證會由GoDaddy TLS根CA – R1階層核發，使用的是GoDaddy TLS中繼CA DV – R1v1的簽發CA certs.godaddy.com。這表示，由伺服器提供的發行者鏈（葉+中繼）可能與某些系統過去查看的不同，且任何以特定的傳統中繼名稱或鏈訂單為前提的內部工具都必須進行更新才能接受新的R1鏈。

此外，從此層級發行的葉憑證不會包含ClientAuth EKU。任何依托可用於TLS客戶端驗證的DV葉憑證的工作流程，都必須轉移至適當的憑證設定檔/ PKI路徑。在推出期間，憑證可以在瀏覽器中運作，因為用戶端會使用我們儲存庫（certs.godaddy.com）中發布的R1→G2交叉簽署信任路徑進行驗證。

憑證如何在R1轉換期間保持瀏覽器運作狀態（R1→G2交叉簽名）

當我們將公開的DV TLS簽發轉移到R1階層時，R1根在瀏覽器及作業系統信任儲存中的廣泛信任/分配程序仍在進行中。為確保新簽發的R1憑證能立即在瀏覽器中運作，我們依靠交叉簽名信任路徑回到已信任的G2根目錄。

從實際的角度來說，葉狀憑證是根據R1 DV的核發CA簽發的，客戶使用已發布的R1→G2交叉憑證建立與GoDaddy第2級根– G2的鏈，以此進行驗證。存放庫中相關的項目為G2信任錨（gdroot-g2），交叉憑證（gd_tls_root-r1-cross-g2），R1 DV簽發中間層（gd_tls_issuing_dv-r1v1）以及原生階層根目錄（gd_tls_root-r1） ）certs.godaddy.com。這種交叉簽名方式可以讓瀏覽器在今天驗證鏈（以G2錨定），而R1信任則隨著時間傳播。

為什麼要進行此變更？

有幾個理由要退出同時支援serverAuth和ClientAuth的憑證（也稱作多用途憑證）：

• 將伺服器驗證和用戶端驗證分開，有助簡化憑證信任模式。
• 改進的安全性檢查標準：用途過多的憑證會增加風險（也就是說，以非預期的方式濫用clientAuth）。
• 為不同功能使用專屬的PKI階層，有助維護更清晰的信任邊界，並符合更廣泛的PKI（公開金鑰基礎架構）最佳實踐。

這項變更有什麼好處？

• 降低多用途憑證的風險：透過將公用憑證限制為僅限serverAuth，可以減少攻擊面，並可以更清楚地了解信任邊界。
• 更好的合&治理：機構將在伺服器驗證和客戶端驗證之間有更清楚的分開，這可以支持更好的審計和憑證生命週期管理。
• 改進的操作透明度：將clientAuth功能分成適當的憑證或基礎架構後，就可以更輕鬆地管理角色，撤銷，續約並確保正確的憑證用於正確的目的。
• 面向未來的就緒狀態：這項變更會符合不斷發展的PKI /瀏覽器信任模式，並有助企業定位新的安全性模式和自動化。

誰不受影響？

大多數只使用憑證進行伺服器驗證的網站（即典型的TLS / HTTPS）不會受到影響。如果您只使用憑證為使用者保護網站，則不需要進行此變更。

誰受影響？

此變更會影響使用公開受信任的伺服器憑證進行用戶端驗證（又稱雙向TLS / mTLS）或依賴clientAuth EKU的伺服器對伺服器驗證的機構。例如，部分金融服務，SaaS服務或多租戶API可能會受此變更影響。

您需要做的事

• 如果您託管的公司並非GoDaddy ：，在更新下一個憑證時，請確保已安裝下載終結點或客戶介面提供的完整套件。
• 如果您在依賴ClientAuth（mTLS）的情況下使用憑證：請確定您已將這些工作流程移轉，以使用自行簽署的憑證或隱私權CA解決方案。

團隊也應該確認，沒有內部功能或文件都假設DV葉子憑證包含ClientAuth EKU，因為R1簽發的葉子憑證不會包含該憑證。

這是否表示所有在2026年6月15日之後簽發的憑證都無效？

不可以。在2026年6月15日之前發行的憑證，包含了clientAuth，在現有的信任模式下依然有效（直到過期）。變更只影響在該日期或之後簽發的新公開憑證。

如果我的憑證只使用典型的網站HTTPS（伺服器驗證），我需要做什麼？

如果您的主機位於GoDaddy以外，則您仍然需要確保已正確使用此組合。

在這種情況下，「客戶驗證」到底是什麼？

客戶端驗證是指客戶端（使用者，裝置或其他伺服器）使用憑證來驗證伺服器。它通常用在mTLS（相互TLS）或伺服器對伺服器API驗證，伺服器需要驗證連線用戶端提供的憑證。

我可以繼續使用clientAuth憑證嗎？

是＆mdash;但為了公共信任，您需要使用專為用戶端驗證簽發的憑證（也就是專屬的clientAuth EKU），或使用專用CA的內部系統。如果Chrome瀏覽器在2026年6月15日後簽發，則clientclientEKU的公開伺服器憑證將不再受Chrome信任。

請問其他瀏覽器會強制執行此變更，還是強制執行Chrome？

這項政策源自Chrome Root計劃，但是公共PKI生態系統的變更常會影響其他瀏覽器和信託商店。明智的做法是假設適用範圍更廣，或至少未來的遵從性在各個平台上都十分重要。

這是否適用於內部/私人CA憑證？

否＆mdash;變更內容僅影響公共信任的SSL / TLS憑證（那些受公共根商店信任的憑證）。內部客戶驗證專用的CA架構不會直接受影響。

我們何時需要準備好進行變更？

目標時間表是2026年5月27日。在此日期前，負責任的團隊應該已完成準備驗證工作（簽發設定，bundle /下載正確性，部署鏈安裝說明，監控以及EKU依存關係檢查），以便在不中斷服務的情況下進行首次推出。

更多資訊

• 設定並安裝 SSL 憑證
• 如果您或您的客戶看到「不受信任的根目錄」或憑證鏈結錯誤，請參閱我們的步驟以解決此問題。