InfraAcademy Blog

公開CAの証明書から「クライアント認証」が消えていく。mTLSやサーバー間通信で、次の更新後に接続が失敗しないか確認する

公開日: 2026-10-19 更新日: 2026-10-19 著者: ryu | #セキュリティ #トレンド #TLS

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

公開CA（認証局）が発行するTLSのサーバー証明書から、クライアント認証の用途が外されていく流れが進んでいます。

きっかけは、Google Chromeのルートプログラムの方針です。Chromeが信頼する公開CAは、Webサーバー向けの証明書をサーバー認証専用にすることが求められるようになりました。

ふつうのWebサイトを運用しているだけなら、この変更で困ることはほとんどありません。ブラウザがサーバーを確かめる仕組みには、何の変化もないからです。

困るのは、公開CAの証明書をクライアント証明書としても使っている構成です。サーバー同士がお互いの証明書を確かめ合うmTLSなどがこれにあたります。

この記事では、何がいつ変わるのかと、自分の環境が影響を受けるかどうかの確かめ方、移行先の考え方を順番に見ていきます。

証明書の「用途」とは？¶

まずは、今回の話の中心になる「証明書の用途」から整理しておきましょう。

TLSの証明書には、その証明書を何に使ってよいかを示す欄があります。これが拡張キー使用法（Extended Key Usage、略してEKU）です。

EKU（拡張キー使用法）：証明書の拡張領域に入っている「この鍵を何の目的に使ってよいか」の宣言。TLSでは、サーバー認証（serverAuth）とクライアント認証（clientAuth）がよく使われる。

TLSで使われる代表的な用途は、次の2つです。

用途	OID	使われる場面
serverAuth（サーバー認証）	`1.3.6.1.5.5.7.3.1`	ブラウザやクライアントが、接続先のサーバーが本物か確かめる
clientAuth（クライアント認証）	`1.3.6.1.5.5.7.3.2`	サーバーが、接続してきたクライアントが誰か確かめる

これまで、公開CAが発行するサーバー証明書には、この2つが両方とも入っていることがよくありました。

サーバー証明書として買ったものなのに、クライアント証明書としても使えてしまう状態です。今回の変更は、この「両方入り」をやめて、サーバー認証だけにするというものです。

サーバー証明書そのものの仕組みに不安がある方は、先にサーバー証明書とは？を読んでおくと、このあとの話が追いやすいと思います。

なぜ用途を分けるのか¶

Chromeのルートプログラムが目指しているのは、Webのサーバー認証のためのPKI（証明書の発行と信頼の仕組み）を、ほかの用途から切り離すことです。

1つの証明書や中間CAを複数の用途で使い回していると、ある用途の都合で起きた変更や事故が、別の用途に波及します。サーバー認証以外の用途で問題が起きたときに、Webの信頼まで巻き込まれる心配がありました。

用途ごとにPKIを分けておけば、方針の変更や失効の判断を、それぞれの用途だけで決められるようになります。証明書の有効期間を短くしていく流れとも、根っこの考え方は同じです。

有効期間の短縮については、証明書の有効期間が短くなる話で詳しく取り上げています。

いつ、何が変わるのか？¶

ここで、主な日程を整理しておきます。

Chromeの方針と、各CAの対応は日付がそろっていません。しかも途中で延期が入っているので、古い記事の日付をそのまま信じないように注意してください。

時期	内容
2025年10月1日	DigiCertが、公開TLS証明書の既定をサーバー認証のみに変更（希望すれば両方入りも可能）
2026年2月11日	Let's Encryptの既定のプロファイルが、クライアント認証を含めない発行に変更
2026年6月15日	Chromeの方針で、新しい中間CAはサーバー認証専用であることが求められる
2026年7月8日	Let's Encryptのクライアント認証入りプロファイル（`tlsclient`）の提供終了予定日
2027年2月15日	IdenTrustが、発行する証明書からクライアント認証を外す予定日
2027年3月1日	DigiCertが、両方入りの選択肢をなくす予定日
2027年3月15日	Chromeの方針で、この日以降に発行される証明書はサーバー認証のみであることが求められる

Chromeのルートプログラムの方針（バージョン1.8）では、2027年3月15日以降に発行されるサーバー証明書は、EKUにサーバー認証だけを含めることになっています。当初は2026年6月が期限とされていましたが、証明書そのものについては2027年3月まで延びました。

DigiCertも、当初は2026年5月1日に予定していた変更を、Chromeの要件の更新に合わせて2027年3月1日に延期しています。

いっぽうLet's Encryptは、早めに動きました。2026年2月11日から既定の発行でクライアント認証を外し、移行用に用意していたtlsclientプロファイルも7月8日で終える予定と告知していました。

すでに持っている証明書はどうなる？¶

ここは誤解しやすいところですが、期限の日付は「発行」の期限であり、手元の証明書が突然使えなくなる日ではありません。

期限より前に発行された両方入りの証明書は、有効期限が来るまでそのまま使えます。DigiCertの告知でも、期限前に発行された証明書は有効期限まで影響を受けないと書かれています。

問題が表に出るのは、次に証明書を更新したタイミングです。更新後の証明書にはクライアント認証が入っていないので、それまで動いていた接続が、更新を境に失敗するようになります。

Let's Encryptの証明書は有効期間が90日なので、影響があればすでに表に出ているはずです。DigiCertなど年単位の証明書を使っている場合は、2027年の更新で初めて気づく、ということが起こりえます。

影響を受けるのはどんな構成？¶

では、具体的にどんな構成が困るのかを見ていきましょう。

まず、影響を受けないものから押さえておきます。ブラウザでアクセスするふつうのWebサイトや、APIサーバーをHTTPSで公開しているだけの構成は、サーバー認証しか使っていません。

DigiCertの告知でも、HTTPSのWebサイトを守るためだけに証明書を使っているなら、対応は不要と案内されています。

影響を受けるのは、公開CAの証明書を「接続する側」の身分証明に使っている構成です。

構成	何が起きるか
サーバー同士のmTLS（相互TLS認証）	接続する側のサーバーが、自分のサーバー証明書をクライアント証明書として提示していると、受ける側の検証で落ちる
XMPPなどのサーバー間連携	サーバー間の接続で、相手のサーバー証明書をクライアントとして検証する実装がある
データベースのクラスタ間通信	ノード同士が同じ証明書でお互いを認証していると、更新後にクラスタに参加できなくなる
外部サービスへの証明書認証	取引先のAPIなどに、公開CAの証明書でクライアント認証している場合に失敗する

特に気をつけたいのは、1枚の証明書をサーバー用とクライアント用の両方に使い回しているケースです。

Let's Encryptのコミュニティフォーラムでも、Galera（MySQL・MariaDB系のクラスタ）のノード間通信が証明書の更新後に動かなくなったという相談が出ていました。

受ける側の検証で何が起きているのか¶

mTLSでは、接続を受ける側のサーバーが、相手のクライアント証明書を検証します。

このときOpenSSLなどのライブラリは、証明書の署名や有効期限に加えて、その証明書がクライアント認証に使ってよいものかどうかも確認します。EKUにクライアント認証が入っていなければ、用途が違うとして検証に失敗します。

OpenSSLの場合、ログには次のようなエラーが出ることが多いです。

verify error:num=26:unsupported certificate purpose

証明書の有効期限も署名も問題ないのに、更新した直後からこのエラーが出るようになったら、EKUを真っ先に疑ってください。

自分の環境を確かめる方法¶

ここからは、実際に確認する手順を見ていきます。

確認したいことは、大きく2つです。1つは、使っている証明書に何の用途が入っているか。もう1つは、その証明書をクライアントとして使っている場所があるかです。

証明書のEKUを確認する¶

手元に証明書のファイルがあれば、openssl x509でEKUを表示できます。

# 証明書ファイルのEKUを表示する（OpenSSL 1.1.1以降）
openssl x509 -in /etc/ssl/certs/server.crt -noout -ext extendedKeyUsage

両方入りの証明書なら、次のように2つの用途が表示されます。

X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

サーバー認証だけの証明書では、TLS Web Server Authenticationの1つだけが表示されます。

稼働中のサーバーの証明書を確認したいときは、openssl s_clientで取得してそのまま渡せます。

# 稼働中のサーバーが返す証明書のEKUを確認する
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext extendedKeyUsage

OpenSSLのバージョンによる違いが気になる方は、OpenSSL 3.0のサポート終了の記事もあわせて確認しておくとよいでしょう。

クライアントとして使っている場所を探す¶

EKUを見るだけでは、影響があるかどうかは分かりません。その証明書を「接続する側」で使っているかどうかが本題です。

探すときは、設定ファイルからクライアント証明書を指定している項目を拾っていくのが早いです。

# 設定ファイルからクライアント証明書を指定していそうな行を探す
grep -rnE "ssl_certificate|client_cert|tls_cert|ssl-cert|proxy_ssl_certificate" /etc 2>/dev/null

たとえばNginxなら、上流のサーバーに証明書を提示するproxy_ssl_certificateがクライアント側の設定です。サーバーとして使うssl_certificateと同じファイルを指定していたら、影響を受ける候補になります。

受ける側の設定もあわせて見ておきましょう。Nginxのssl_verify_client onのように、相手にクライアント証明書を求めている設定があり、その検証に公開CAを信頼しているなら、相手の証明書の更新で接続が切れるおそれがあります。

移行先はどう考える？¶

影響がある構成が見つかったら、クライアント認証の仕組みを公開CAから切り離すことになります。

基本の考え方は、クライアント認証には自分たちで管理するプライベートCAを使うことです。Apacheソフトウェア財団の解説でも、クライアント認証はプライベートCAや企業内のCAへ移すことが推奨されています。

移行先	向いているケース
クラウドのマネージドなプライベートCA	クラウド上のサーバー同士の通信。運用の手間を減らしたい
社内のCA（Active Directory証明書サービスなど）	社内ネットワークの機器や端末の認証。既存の仕組みがある
OSSのCA（step-caなど）	小さな構成で、まずは自分たちで試したい