Public Key Infrastructure (PKI) に関する今後の必須変更について

注意:

Chromeルートプログラムポリシーv1.8 の変更は 、2027年3月15日以降に施行されます（当初の2026年6月15日から変更）。 

影響を受ける組織と影響を受けない組織

影響を受ける組織

Chromeルートプログラムポリシーv1.8 の変更は、Chrome でデフォルトで信頼されている公開 CA によって発行された クライアント認証 (または「デュアルユース」) 証明書 を使用している組織に直接影響します。これらの CA は、Web サイトの SSL 証明書とクライアント ID 証明書の両方を発行する単一のルートを維持することができなくなります。

 組織が 公開信頼証明書を使用した mTLS に依存している場合 (クライアント証明書が Web サーバ証明書と同じ Public Root CA をチェーンのルートとしている場合)、かつその Public Root CA が Chrome Trusted Root List に含まれている場合、この変更の影響を受けます。この期限以降、これらの CA から 「デュアルユース」証明書 (mTLS 証明書と呼ばれることもあります) を購入することはできなくなります。

影響を受けない組織

• Private / Enterprise CA: 従業員が社内サイトへアクセスするためのクライアント証明書を発行する 内部 CA (ローカルで信頼される CA) を運用している場合、この変更の影響はありません。

• クライアント認証: Chrome がクライアント証明書のサポートを廃止するわけではありません。ブラウザは引き続きサーバへ証明書を渡して評価を行いますが、公開 Web サイトの信頼に使用されるルートと同じルートから発行された証明書は許可されなくなります。

変更内容: Chrome による専用 PKI 階層の必須化

今回の主な変更は、TLS サーバ認証専用の PKI 階層 (Dedicated TLS Server Authentication PKI Hierarchies) を必須とする点です。Chrome は、Web サイトの識別 (Server Auth)、クライアント / ユーザーの識別 (Client Auth) の用途で使用される証明書を厳格に分離する方針を導入します。

1. 「デュアルユース」の禁止

これまで、1つの Root CA が複数用途の証明書を発行するサブ CA を持つことが可能でした。新しいポリシーでは、Chrome Root Store に含まれる Root CA は TLS サーバ認証のみを目的として使用する必要があります。

• Subordinate CA: Chrome に信頼されたルートにチェーンする中間 CA は、Client Auth やその他の拡張キー用途を許可できません。
  許可されるのは server TLS (`id-kp-serverAuth`) のみ です。

• Subscriber (Leaf) 証明書: 単一の証明書をServer Authentication と Client Authentication の両方に使用することはできません。証明書には Extended Key Usage (EKU) `id-kp-serverAuth` のみを含める必要があります。

2. 2027年3月15日の期限 (既存 CA)

Chrome Root Store に含まれる CA について:

• 2027年3月15日以前: Subordinate CA は `id-kp-serverAuth` と `id-kp-clientAuth` の両方を許可できます。

• 2027年3月15日以降: すべての Subordinate CA および Subscriber 証明書は `id-kp-serverAuth` のみを許可する必要があります。

• 影響: この期限後に PKI 階層がポリシーに違反した場合、Chrome は SCTNotAfter 制約 を適用します。その結果、違反検出から 90日以降に発行された新しい証明書は信頼されなくなります。

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

この変更の主な目的は、用途に特化した PKI を構築することです。

• スコープの制限: TLS サーバ認証のみ を目的としています。Google は、このストアが以下の用途では使用されないことを明示しています。

  • TLS クライアント認証

  • セキュアメールコード

  • 署名

• リスクの低減: Web サイト用 PKI を他用途の PKI から分離することで、クライアント認証やメールなどのセキュリティ問題が 公開 Web の信頼性に影響することを防ぎます。

• ポリシーの統一: Chrome Root Store に含まれるすべての PKI 階層を単一の原則に統一し、複数用途のルート証明書を段階的に廃止 することが可能になります。

影響を受ける組織が取るべき対応

Salesforce エコシステムで 独自の証明書を使用しているお客様 は、次の対応を検討してください。

1. mTLS 使用状況の確認: クライアント証明書またはサーバ証明書がChrome Root Store に含まれる Public CA から発行されているか を確認してください。

2. 信頼アンカーの分離: 以下の構成を使用する必要があります。

   1. サーバ識別 (Web サイト URL) : Public CA

   2. クライアント識別 : 別の CA (Private CA または Chrome に信頼されていない Public Root)

3. 証明書再発行の準備: Public CA から発行されたデュアルユース証明書は、2027年3月以降は同じ形式で更新できません。

4. CA への確認: Public CA に連絡し、用途ごとに分離された証明書を使用する新しいルート階層から証明書を再発行してください。この文書に従い、CA は Salesforce によって信頼されている必要があり、かつクライアント証明書には Client Authentication EKU が含まれている必要があります。なお、この文書は outbound 呼び出しについて説明していますが、cacerts.jsp のリストは inbound mTLS にも使用されます。

    

短期的な対応策