GoDaddyがClientAuth EKUを削除し、DV TLS発行のためにR1ルート階層に移行するのはなぜですか？

注：お客様またはお客様のお客様に「信頼できないルート」または証明書チェーンのエラーが発生した場合は、弊社の問題解決手順を参照してください。

2026年6月15日より、サーバーで使用するために発行された公に信頼されているSSL / TLS証明書に「クライアント認証」（EKU：clientAuth）拡張キーの使用法を含めることができなくなります。理解すべき重要なポイントは次のとおりです。

この変更はChromeルートプログラムのポリシー更新の一部です。新しい証明書には「サーバー認証」EKUのみを含める必要があります。
その日付以降に発行され、clientAuthを含む新しい公開証明書は、Chromeでは信頼されません。
2026年6月15日より前にclientAuthで発行された証明書は、この変更の影響を受けず、期限切れになるか失効するまで有効です。
プライベートCA証明書（内部使用）は、この変更による影響はありません。この変更は、公開で信頼されている証明書にのみ適用されます。

つまり、組織がクライアント認証に（clientAuth EKUを介した）公開TLS証明書を使用している場合は、 2026年6月15日までに行動する必要があります。標準のWebサイトTLS使用法（サーバー認証のみ）の場合、この変更による対処は必要ありません。ただし、使用証明書を確認し、機能を適切に分離し、進化する信頼モデルに対応していることを確認する必要があります。

GoDaddyがこの変更を実装する方法

現在のG2署名/発行中間体にはEKUが記載されていないため、この階層はChromeルートプログラムの要件に準拠していません。その結果、影響を受けるG2中間体からの発行は、その日までに停止されなければなりません。

G2チェーンで新しい発行中間体を作成するのではなく、2027年4月にGoogleで期限切れ/終了する予定です。今後、ポリシーの制約を満たすため、DV発行を新しいR1階層に移動します。

公開DV発行チェーンを変更し、GoDaddy TLSルートCA – R1階層からGoDaddy TLS中間CA DV – CA certs.godaddy.comを発行するR1v1を使用して、新しいDVリーフ証明書を発行します。つまり、サーバー（リーフ+中間）によって提示される発行者チェーンは、一部のシステムでこれまでに見られたものとは異なる場合があります。また、特定のレガシー中間名またはチェーン順序を想定する内部ツールは、新しいR1チェーンを受け入れるように更新する必要があります。

さらに、この階層から発行されたリーフ証明書には、ClientAuth EKUは含まれません。 TLSクライアント認証に使用できるDVリーフ証明書に依存していたワークフローは、適切な証明書プロファイル/ PKIパスに移行する必要があります。クライアントは弊社のリポジトリで公開されている必要なR1→G2相互署名信頼パス（certs.godaddy.com）を使用して検証するため、ロールアウト中も証明書はブラウザで引き続き使用できます。

R1移行（R1→G2クロスサイン）中に証明書がブラウザ動作を維持する方法

パブリックDV TLS発行をR1階層に移行する際、R1ルートは引き続き、ブラウザおよびOSのトラストストアで広く信頼/配布される過程にあります。新しく発行されたR1証明書がブラウザですぐに機能するようにするために、すでに信頼されているG2ルートへのクロス署名された信頼パスを使用します。

実際には、リーフ証明書はR1 DV発行CAの下で発行されますが、クライアントは、公開されたR1→G2相互証明書を使用してGoDaddy Class 2 Root – 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の信頼は時間の経過とともに伝播します。
r1-g2クロスサインパス

なぜこの変更が行われるのですか？

serverAuthとclientAuthの両方をサポートする証明書（多目的証明書とも呼ばれる）から移行する理由はいくつかあります。

サーバー認証とクライアント認証を分離すると、証明書の信頼モデルを簡素化できます。
セキュリティ衛生の向上：目的が多すぎる証明書はリスクを増大させます（意図しない方法でのclientAuthの誤用）。
専用のPKI階層を個別の機能に使用すると、より明確な信頼境界を維持し、より広範なPKI（公開キー基盤）のベストプラクティスに合わせることができます。

この変更の利点は何ですか？

多目的証明書によるリスクの軽減：公開証明書をserverAuthのみに制限することで、攻撃対象が減り、信頼境界が明確になります。
コンプライアンス&ガバナンス：組織は、サーバー認証とクライアント認証を明確に分離し、より良い監査と証明書ライフサイクル管理をサポートします。
運用の明確性の向上： clientAuth機能を適切な証明書またはインフラストラクチャに分離すると、役割、失効、更新の管理が容易になり、適切な証明書が適切な目的に使用されるようになります。
将来の準備：この変更は、進化するPKI /ブラウザ信頼モデルに合わせて調整され、新しいセキュリティモデルと自動化のために組織を位置付けるのに役立ちます。

誰が影響を受けませんか？

証明書をサーバー認証のみに使用するほとんどのWebサイト（つまり、一般的なTLS / HTTPS）は影響を受けません。証明書を使用してユーザーのWebサイトを保護するだけの場合は、この変更による対処は不要です。

影響を受けるのは誰ですか？

この変更は、クライアント認証（相互TLS / mTLSとも呼ばれる）またはclientAuth EKUに依存するサーバー間認証に公的に信頼されているサーバー証明書を使用する組織に影響します。たとえば、一部の金融サービス、SaaSサービス、またはマルチテナントAPIは、この変更の影響を受ける可能性があります。

必要な作業

GoDaddy以外でホストされている場合：次の証明書を更新するときに、ダウンロードエンドポイントまたは顧客インターフェースによって提供される完全なバンドルがインストールされていることを確認します。
ClientAuth（mTLS）に依存するユースケースで証明書を使用している場合：自己署名証明書またはプライベートCAソリューションを使用するようにワークフローを移行してください。

また、R1で発行されたリーフ証明書にはClientAuth EKUが含まれていないため、内部機能やドキュメントではDVリーフ証明書にClientAuth EKUが含まれていないと想定していることも確認する必要があります。

これは、2026年6月15日以降に発行されたすべての証明書が無効であることを意味しますか？

いいえ。2026年6月15日より前に発行され、clientAuthを含む証明書は、既存の信頼モデルでは（有効期限が切れるまで）有効です。この変更は、その日付以降に発行された新しい公開証明書にのみ影響します。

証明書を通常のWebサイトHTTPS（サーバー認証）にのみ使用する場合、何かする必要はありますか？

ホスティングがGoDaddyの外部にある場合でも、バンドルが正しく使用されていることを確認する必要があります。

この文脈における「クライアント認証」とは正確には何ですか？

クライアント認証とは、クライアントを認証するためにクライアント（ユーザー、デバイス、または別のサーバー）が証明書を使用することです。これは、mTLS（相互TLS）またはサーバー間API認証で一般的に使用され、接続するクライアントによって提示された証明書をサーバーが検証する必要があります。

clientAuth証明書を使用することはできますか？

はい。ただし、パブリックトラストの場合は、クライアント認証専用に発行された証明書（専用のclientAuth EKU）を使用するか、内部システムにプライベートCAを使用する必要があります。 2026年6月15日以降に発行された場合、clientAuth EKUを含む公開サーバー証明書は、Chromeで信頼されなくなります。

他のブラウザでもこの変更が適用されますか、それともChromeだけですか？

このポリシーはChromeルートプログラムに基づいていますが、パブリックPKIエコシステムの変更は、他のブラウザやトラストストアに影響を与えることがよくあります。より広い適用範囲を想定することは賢明です。少なくとも将来のコンプライアンスはプラットフォーム間で重要になると考えてください。

これは内部/プライベートCA証明書に適用されますか？

いいえ。変更は、公的に信頼されているSSL / TLS証明書（パブリックルートストアによって信頼されているもの）にのみ影響します。内部クライアント認証に使用されるプライベートCAインフラストラクチャは直接影響を受けません。

この変更にいつ対応する必要がありますか？

目標のタイムラインは2026年5月27日です。その日までに、担当チームは準備検証（発行設定、バンドル/ダウンロードの正確さ、展開チェーンのインストールガイダンス、モニタリング、EKU依存関係の確認）を完了しているため、サービスを中断することなく展開を進めることができます。

SSL証明書 Help