ブラウザベンダーは明確な線引きをしています： 2026年6月15日以降、パブリックTLSサーバ証明書にはクライアント認証（ClientAuth） EKUを含めることが禁止されます。この変更は技術的なもののように思えるかもしれませんが、特に証明書ベースの認証に依存する金融サービス業界など、多くの分野に重大な影響を及ぼすでしょう。

証明書要件が厳格化される中、組織はパブリックとプライベートトラストの使い分けを見直すことが不可欠です。この変化は、金融サービスにおけるPKIのアップデートに向けた業界全体の取り組みと一致しており、最近設立されたX9 PKI業界フォーラムへの参加もその一環です。

EKUの見直し：何が変わり、なぜ重要なのか

鍵拡張使用法（EKU）は、X.509証明書内のフィールドで、証明書がどのように使用されるかを指定します。歴史的に、一部のパブリックTLSサーバ証明書（HTTPSウェブサイトを保護する証明書）は、サーバ認証とクライアント認証のEKUを両方含んでいました。後者（OID 1.3.6.1.5.5.7.3.2）は、相互 TLS（mTLS）認証で使用されるクライアント証明書向けに設計されており、サーバ向けではありません。

その両用は、以前のCA/Bフォーラムのベースライン要件では厳格に禁止されていませんでしたが、適切なセキュリティ対策として不適切とされていました。サーバ証明書にClientAuthを含めることは、サーバ証明書をクライアント認証のシナリオで誤用する可能性を含む曖昧さと潜在的なセキュリティリスクを引き起こし、最小権限の原則に違反する行為でした。

現在、主要なブラウザが対応を開始しています。Google Chromeは、ClientAuth EKUを含むサーバ証明書を拒否するポリシーの実施を発表し、Mozillaも同様の措置を講じる見込みです。これは、Googleがセキュリティリスクと見なす「マルチパーパスルート」（サーバ認証とクライアント認証の両方をサポートする証明書チェーン）を排除する広範な取り組みの一環です。

変更が実施された後も引き続きこれを含み続けるパブリック証明書発行認証局（CA）は、ブラウザによってその証明書が信頼されなくなるリスクに直面します。これは、それらに依存する組織にとって、潜在的に深刻な事態となる可能性があります。

今後、TLS証明書に与える影響とは

クライアント認証のEKUは、ご使用のケースでは必要なかった可能性があり、その場合、ClientAuth EKUを含まない証明書を再発行するだけで済むかもしれません。2026年に強制適用が開始されると、サーバ証明書にClientAuth EKUが含まれていることは警告サインとなり、次の証明書とみなされることによってブラウザによって拒否される可能性があります。

• 有効期限が切れた証明書または古い証明書
• 内部PKIの誤設定
• 準拠していないCAが発行する証明書

したがって、主要なプラットフォームを含む新しい証明書にClientAuth EKUが設定されている場合、一度立ち返る必要があります。これは単なる見落としなのか、それとも緊急の対応が必要な過去の慣行なのか？

金融サービス：PKIのアップデートが重要な理由

金融業界は長年、複数のPKIインフラストラクチャを運用してきました。ブラウザの信頼性を確保するためのパブリックCAと、mTLS、スマートカード、デバイス認証など、厳格に限定された組織内用途向けの内部（またはプライベート）PKIです。

しかし、この断片化は複雑さを生み出し、場合によってはリスクを伴います。例えば、互換性のない役割間で証明書を再利用するケースなどが挙げられます。これらの内部利用ケースにパブリック証明書が使用されていた場合、別のソースからの証明書に置き換える必要があります。

X9 PKI 業界フォーラム（X9 認定基準委員会が最近設立した）は、金融機関、認証局（CA）、サービスプロバイダーが実践的なPKIガイドラインと相互運用性に関する協力を促進するベンダーニュートラルのフォーラムを構築しています。

単一の標準を推進するのではなく、フォーラムは金融業界におけるスケーラブルで相互運用可能なPKIアーキテクチャに関するオープンな議論と技術的な整合性を支援しています。

ClientAuth EKUの無効化は新しい化学反応を生み出す

ブラウザによるEKUの仕様変更の適用は、実質的に強制的な措置です。これにより、金融機関は認証の取り扱い、証明書ライフサイクル管理、およびパブリックトラストインフラとプライベートトラストインフラ間の役割分担について見直しを迫られています。

実際には、これは次の意味を持ちます。

• 「スイスアーミーナイフ」のような複数の役割を果たす証明書の利用をやめる。
• プライベートCAの設立または強化により、クライアント認証機能（ClientAuth）対応の証明書を発行可能とし、内部のmTLS、S/MIME、およびアイデンティティ認証利用ケースに対応しつつ、パブリックトラストに影響を与えないようにする。

その結果、進化する業界とブラウザのポリシー標準に適合した、より強固で維持管理しやすいPKIアーキテクチャが生まれます。

金融PKIの今後の道筋

クライアント認証（ClientAuth）をパブリックTLS証明書から削除することは、単なるコンプライアンスの更新ではありません。これは転換点です。デジタルトラストがより精密になり、より目的指向型となり、より厳格に管理されるようになっていることを示しています。金融機関にとって、これは組織全体でのPKIの展開方法を見直すことを意味します。

これは、次のような機会をもたらします。

• 相互運用可能でポリシーに準拠した証明書を活用し、デジタルトラストの基盤を強化します。

• プライベートPKIをアップデートし、mTLS、コードサイニング、大規模なアイデンティティ認証管理など、アジャイルなユースケースに対応します。

• パブリックとプライベートトラストを使い分けるゾーンを分離し、リスクを軽減し管理の効率を向上させます。

X9 PKI 業界フォーラムのような協働的な取り組みは、金融機関がこの変化に対応するため、共通の指針、技術的な整合性、そして将来に備えたフレームワークを提供しています。

金融機関がX9 PKI標準の採用を検討している場合でも、企業がmTLS環境の見直しを行っている場合でも、この変化は重要な教訓です。証明書管理はもはやオプションではありません。それは、安全で信頼できるデジタルトラストの基盤です。現在行動を起こす組織、つまり、証明書使用状況の監査、プライベートPKIのモダン化、専用設計の信頼モデルの導入を行う組織は、自社の金融エコシステム全体でデジタルトラストがどのように機能するかを定義し制御する上で、より強固な立場に立つことができます。

デジタルトラストに関する最新の動向

PKI、証明書管理、デジタルトラストなどのトピックについて詳細をご希望ですか？記事を見逃さないようにデジサートのブログを参照してください。