はじめに
2026年6月以降、Google Chrome においてサーバー認証とクライアント認証の証明書を明確に分離することを求める「デュアルユース（Dual-use）」禁止ポリシーが導入されます。
※ ポリシーのタイムラインについては、直近でも見直しが入っているようです
( ﾟдﾟ)ﾎﾟｶｰﾝ
- 「え、サーバー証明書とクライアント証明書って同じもの使えてたの？」
- 「サーバー証明書って公開する前提なのに、それをクライアント認証に使って意味あるの？」
なにも分からな過ぎてパニックに陥ったので、
本記事では、TLS / mTLS の基本をさらっと確認しながら、Chrome でデュアルユース証明書を禁止した意図を読み解きます。
※ 署名アルゴリズムや暗号スイート、鍵交換などの詳細には踏み込みません
何が変わるのか
今回の変更により、従来のように「サーバー認証とクライアント認証の両方に利用できる証明書（デュアルユース証明書）」は利用できなくなります。
特に影響が大きいのは、mTLS を利用しているシステムです。
従来は、パブリックCA から発行された証明書をクライアント認証にも流用する構成が存在していましたが、ポリシーが導入されるまでに以下の点を確認する必要があります。
- クライアント証明書の Extended Key Usage (EKU) に
clientAuthのみが含まれているか - サーバー証明書と同じパブリックルートに依存していないか
👉 これは、証明書の設定の問題というよりも、「どの信頼をどの用途に使うか」という設計の見直しが求められているといえます。
デュアルユース証明書が必要とされていた背景の１つには、1台の機器が「サーバ」と「クライアント」の両方として振る舞う構成があります。
例えば Cisco Expressway は、外部からの接続に対してはサーバとして動作しつつ、内部の別システムへ接続する際にはクライアントとして振る舞います。
このような構成では、1つの証明書で両方の役割を担う必要があり、serverAuth と clientAuth の両方を持つ証明書（デュアルユース）が利用されてきました。
参考：パブリックCA証明書でのクライアント認証EKUのサンセットに対するExpresswayの準備
早見表
| ケース | 影響の有無 | 理由 / 対応 |
|---|---|---|
| サーバー証明書 (serverAuthのみ) と、プライベートCA発行のクライアント証明書 (clientAuthのみ) を別々に利用 | 影響なし | 既に用途と信頼の基盤が分離されているため。 |
| パブリックCA発行の1つの証明書にserverAuth と clientAuth の両方が設定されている | 影響あり | 2026年6月以降、Chromeではクライアント認証として機能しなくなる。サーバー認証用とクライアント認証用で証明書を分離する必要がある。 |
| パブリックCA発行のサーバー証明書とは別に、同じパブリックCAから発行されたクライアント証明書を利用 | 要確認 | 技術的には clientAuth のみでも動作する可能性はあるが、長期的にはプライベートCAや社内PKIへの移行を検討するのが吉。 |
TLS / mTLS を概要だけおさらい
TLSではサーバーのみが証明書を提示するのに対し、
mTLSではクライアントも証明書を提示し、相互に認証を行います。
重要なのは、いずれの場合も「証明書の提示」だけではなく、認証の過程でチャレンジコードを送り、それを秘密鍵で署名 → 証明書に含まれる公開鍵で検証 という流れがあることです。
つまり、認証において重要なのは「証明書そのもの」ではなく、「その証明書に対応する秘密鍵を持っていること」を証明できるかどうかです。
したがって、証明書を持っているだけでは認証を突破することはできません。
よって、「サーバー証明書って公開前提なのに、それをクライアント認証に使って意味あるの？」に対する答えは、
証明書が公開されていること自体は問題ではない (=意味は”ある”) といえます。
（ただし、後述しますが、設計的にきれいかは別問題）
なお、TLS ハンドシェイクの実際のやり取りについては、以下の記事がとても分かりやすくて参考になります。
証明書で見るべきポイント
では実際に、クライアント証明書の内容を確認してみます。
ここでは OpenSSL を使って、証明書の見るべきポイントを確認します。
気にする項目は大きく、ユーザー識別情報（Common Name, CN）、発行元（issuer）、用途（Extended Key Usage, EKU）です。
これらを見ることで、「誰に発行された証明書か」と「どの信頼に属しているか」を確認できます。
手元にあったクライアント証明書の観察（一部マスクしてます）
まず、.pfx ファイルの中身を確認します。
openssl pkcs12 -in client.pfx -info -nodes
もしパスワードを求められたら入力。証明書の情報が表示されます。
Bag Attributes
friendlyName: example client certificate
subject=C = JP, UID = 123, CN = user01@example.com, OU = dept001, O = example.com, ST = Tokyo
issuer=O = example.com, C = JP, OU = dept001, CN = example.com CA, ST = Tokyo
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
この例では、CN にユーザーを識別する情報（メール形式）が含まれており、クライアント証明書であることが分かります。
また、発行元（issuer）はパブリックCAではなく、サービス固有の プライベートCA であると分かります。
続いて、証明書の用途（EKU）を確認します
openssl pkcs12 -in client.pfx -nodes -clcerts | openssl x509 -text -noout | grep -A 3 "Extended Key Usage"
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
この証明書は TLS Web Client Authentication のみを持ち、サーバー認証用途は含まれていないことが分かります。
もしデュアルユースの場合は、TLS Web Server Authentication という表示も含まれます。
以上から、この証明書は
- クライアント認証専用であり、デュアルユース証明書ではない
- サーバー証明書と同じパブリックルートから発行されたものではない
と確認できました。
なぜこのような制約が入ったのか考察
The Chrome Root Store is solely relied upon for TLS server authentication in Chrome; it is not used for any other PKI use case.
Chrome は、Root Store を「TLS サーバー認証のためだけ」に利用することを前提としています。
「公開Webの信頼」と「クライアント認証の信頼」は別物として扱うべきであり、同じ証明書や PKI を使い回すべきではない、ということです。
でもなぜ今になって、長年利用されてきたデュアルユース証明書を禁止するのでしょう。
このような方針転換の背景には、ゼロトラストの考え方の普及や、「インターネット全体の信頼」と「組織内の認証」を明確に分離する流れがあると考えられます。
「秘密鍵で本人確認しているなら、同じ証明書を使ってもそんなに問題ないような？」
Chrome が気にしているのは、セキュリティ的な脆弱性ではなく「信頼の境界」にあるように見えます。
つまり、「どの信頼が、どの用途に使われているのか」を明確に分離したい、というのが意図するところだと思っています。
サーバー証明書は、「そのドメインの正当な所有者であること」を証明します。
一方、クライアント証明書は、「認証対象として許可された範囲に属していること」を前提に使われます。
このとき重要なのが、「その証明書を誰に発行しているのか」という点です。
クライアント認証では、どの主体を認証対象にするかを決め、その範囲を管理する必要がありますが、パブリックCAはインターネット全体に対する信頼を扱う仕組みであり、認証対象を限定することを目的としていません。
そのため、パブリックCAの証明書をクライアント認証に使うと、その CA の信頼する広い範囲が、そのまますべて認証対象に入り込んでしまう可能性があります。
結果として、本来は分けるべき信頼の境界が曖昧になってしまう。
Chrome が嫌っているのはこの点ではないかと考えています。
おわりに
ここまで見て来て、Chrome が禁止しようとしているのは、セキュリティに直結する危険な仕組みではなく、「本来分離されるべき信頼を混在させる設計」だと感じました。
実務的な観点では、証明書の内容を確認し、「用途」と「信頼の基盤」が分離されているかを見直すことが重要になります。
また、システム開発ではお馴染みな「単一責任の原則」は証明書の設計においても例外ではなく、証明書もまた「”1つの責務＝1つの信頼”」に閉じるべきものなんだなぁと感じました。
参考にさせていただいた文献：