公開2026.07.14更新2026.09.11 29 人が閲覧（直近 30 日）プロトコル

mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説

Q: mTLSはNginxだけで実現できますか？

受け側の検証はNginxだけで足ります。 ssl_verify_client をonにして信頼するCA証明書を指定し、中間CAを挟むなら ssl_verify_depth を引き上げれば、正規のクライアント以外は400で弾かれる構成です。ただし証明書の発行と入れ替えはNginxの外側の話で、クライアントへ配る証明書を誰がいつ作り直すかを決めていないと、期限切れの日に通信が止まります。数枚なら手作業、数十枚を超えるならcert-managerやPrivate CAへ寄せる線引きになります。

mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説

mTLS（相互TLS認証）とは、通信の暗号化に使われるTLSに、クライアント側の証明書検証を加えて、接続する両端が互いに相手の身元を確認する認証方式です。ふだんWebで使われるTLSはサーバー証明書だけを検証しますが、mTLSではクライアントも自分の証明書を提示し、サーバーがそれを検証します。つまり「サーバーは本物か」に加えて「つないできた相手は許可された正規のクライアントか」まで通信の土台で確かめる仕組みです。この記事では、mTLSが通常のTLSと何が違うのかという定義から、ハンドシェイクで双方の証明書を検証する流れ、認証局と証明書チェーンによる正当性の確認、サービスメッシュやAPIゲートウェイでの実装と証明書の発行・失効といった運用、そして内部のサービス間通信やゼロトラストで採用すべき場面と外部公開のWebで見送るべき場面、APIキーやOAuthとの使い分けまでを、システムを設計・発注する立場で判断に使える形に整理します。設定例はOpenSSLでのCA構築、Nginxのssl_verify_client、IstioのPeerAuthentication、AWSのALBまで、公式ドキュメントで確認した形で載せています。

まとめ｜mTLSの正体と相互TLS認証で押さえる実装の要点

mTLSは、TLSに標準で備わるクライアント認証の機能を有効にして、サーバーとクライアントの双方が証明書で相手を検証する構成です。片方向のTLSがサーバーだけを認証するのに対し、mTLSは「呼び出してきた相手も、事前に信頼した認証局が発行した証明書を持つ正規の相手か」をハンドシェイクの段階で確かめます。パスワードやAPIキーのように「知っている情報」ではなく、秘密鍵と証明書という「持っているもの」で相手を証明するため、盗まれた合言葉によるなりすましに強いのが本質的な違いです。

実装でまず押さえたいのは、mTLSが効くのは「通信相手を事前に限定できる」内部のサービス間通信やゼロトラスト構成であり、不特定多数がアクセスする外部公開のWebサイトには向かないという線引きです。もう一つの勘所が証明書の運用で、双方に証明書を配り、期限が切れる前に入れ替え（ローテーション）、漏れた鍵は失効させる仕組みまで用意して初めてmTLSは回ります。サービスメッシュのIstioやKubernetesのcert-manager、ワークロード証明書の標準であるSPIFFEといった道具で、この証明書配布を自動化できるかどうかが導入の成否を分ける分岐点です。以下で定義・仕組み・実装・採用判断を順に解説します。

費用の目安も先に置きます。AWSでプライベートCAを立てる場合、汎用モードはCA1本あたり月400USD、有効期間7日以内に限られる短期間証明書モードは月50USDで、証明書の発行料は汎用モードなら月1,000枚までが1枚0.75USD（いずれも2026年9月時点）。Nginxで受けるだけならソフトウェアの追加費用はかからず、ssl_verify_clientをonにして信頼するCA証明書を置く数行で足ります。規模が小さいうちは後者、Kubernetesで数十のサービスを回すなら前者と自動発行基盤を選ぶ、という線引きになります。

mTLSとは｜TLSに双方向の証明書検証を加えた相互認証の仕組み

最初にmTLSが何を指すのかを固めます。ここが曖昧だと、後半のサービスメッシュでのmTLS化や、ゼロトラストとの関係が捉えづらくなります。mTLSは新しい別のプロトコルではなく、TLSに元から用意されているクライアント認証を使う構成を指す点が出発点です。

mTLSと通常のTLSの違い：サーバーに加えクライアントも証明書で認証

通常のTLSでは、ブラウザなどのクライアントがサーバーの証明書を検証し、相手が本物のサーバーであることと通信路の暗号化を確保します。このとき認証されるのはサーバーの一方だけで、つないできたクライアントが誰かはTLSの層では確かめません。mTLSは、ここにクライアント側の証明書提示と検証を加えた構成です。サーバーは接続時にクライアントへ証明書を要求し、受け取った証明書を自分が信頼する認証局に照らして検証します。両端が互いに相手の身元を証明書で確認したうえで、ようやく暗号化通信に入るという流れです。mTLSはTLSを土台にした拡張であり、TLS自体のバージョンや暗号スイートの選び方はTLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説で整理しています。mTLSはその上に「クライアントも認証する」1枚を重ねたものだと捉えると位置づけがつかめます。

mTLSが解決する課題：ネットワーク内部の通信相手のなりすまし防止

社内ネットワークやクラウド内部の通信は、外部との境界さえ守れば中は安全だと長く前提されてきました。しかし境界を越えて侵入された場合や、内部のサービスが多数連携する構成では、「そのリクエストを送ってきたのが本当に正規のサービスか」を通信ごとに確かめたい要求が生まれます。IPアドレスやネットワークの位置だけで信頼すると、なりすましや踏み台にされたホストからの通信を見分けられません。mTLSは、通信の両端に固有の証明書を持たせ、正しい秘密鍵を持つ相手だけを通すことで、この「相手が誰か」をアプリケーションの手前で機械的に判定します。認証情報がリクエストの本文ではなく接続の確立時に検証されるため、途中でトークンを差し替えるといった攻撃も成立しにくくなります。

mTLSと片方向TLSの違いとゼロトラスト実装での位置づけ整理

片方向のTLSは「通信路の暗号化」と「サーバーの正当性確認」を担い、mTLSはそこに「クライアントの正当性確認」を足します。この差は、あらゆる通信を無条件に信頼しないという考え方と噛み合います。誰からの通信かを常に検証してから通す設計は、ネットワークの内外を問わず相手を確かめるゼロトラストの発想そのものです。mTLSは、その思想をサービス間通信やデバイス認証のレイヤで具体化する実装手段の一つに位置づきます。境界型の防御との違いやゼロトラストの原則はゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説で扱っており、mTLSはその原則を「通信相手を証明書で常時検証する」形で満たす部品だと整理できます。NIST SP 800-207が挙げる7原則のうちmTLSが直接受け持つのは「すべての通信を保護する」と「認証と認可を動的に行う」の2点で、7原則の全体像はゼロトラストネットワークの7つの要件｜NIST SP 800-207の7原則と最小特権にまとめました。

mTLSの仕組み｜ハンドシェイクと証明書チェーンで双方を検証する流れ

mTLSの動きは、TLSハンドシェイクにクライアント証明書のやり取りが加わる流れとして理解できます。ここを押さえると、どこで検証が起き、なぜ証明書と秘密鍵の管理が要になるのかが一本の筋で見えます。

TLSハンドシェイクにクライアント証明書の提示と検証が加わる流れ

通常のハンドシェイクで検証されるのはサーバー証明書だけです。この土台となるTLS 1.3のハンドシェイクと署名アルゴリズムの決まり方を押さえておくと、クライアント証明書がどこに挟まるかを掴みやすくなります。mTLSでは、サーバーがCertificateRequestをクライアントへ送り、証明書の提示を求めます。要求を受けたクライアントは自分の証明書を返し、あわせて自分がその証明書に対応する秘密鍵を確かに持っていることをCertificateVerifyの署名で示す点がmTLSの肝です。サーバーは受け取ったクライアント証明書を検証し、署名も確かめたうえで、双方が正当だと確認できて初めて暗号化通信を開始します。この「秘密鍵を持っていることの証明」があるため、証明書ファイルだけを盗んでも、対応する秘密鍵がなければ相手になりすませません。RFC 8446（TLS 1.3・2018年8月）ではCertificateRequestが4.3.2、クライアントのCertificateとCertificateVerifyが4.4.2と4.4.3に置かれ、仕様の本文には「This message is omitted if client authentication is not desired」と書かれています。mTLSは、この任意機能を必須として運用する構成にあたります。

証明書チェーンをたどり認証局を起点に通信相手を検証する仕組み

提示された証明書が信頼できるかは、その証明書に署名した認証局（CA）をたどって判断します。相手の証明書には、それを発行した中間認証局の証明書が連なり、最終的に自分があらかじめ信頼登録したルート認証局へと連なる構造です。この連なりが証明書チェーンで、チェーンをたどってルートまで到達し、途中の署名がすべて正しければ相手を信頼します。mTLSでは、サーバーとクライアントがそれぞれ相手の証明書チェーンを検証するため、両者が「同じ認証局体系を信頼している」状態を作ることが前提になります。組織内でmTLSを使う場合は、自前の認証局（プライベートCA）を立て、そこから各サービスやクライアントへ証明書を発行する構成が一般的です。加えて、いったん発行した証明書が漏れた場合に無効化するため、失効リスト（CRL）や失効を問い合わせるOCSPで、証明書が取り消されていないかを都度確かめる運用も設計に含めます。証明書とCRLの形式を規定するのがRFC 5280、オンラインで失効状態を問い合わせるOCSPを規定するのがRFC 6960です。CRLは配布間隔のぶん反映が遅れ、OCSPは応答先が落ちると検証そのものが止まります。内部通信では証明書の有効期間を数時間から数日に縮め、失効の仕組みへの依存を下げる設計を採ります。

mTLSの相互認証を支える公開鍵暗号と秘密鍵・電子署名の役割

mTLSの相互認証は、公開鍵暗号の仕組みの上に成り立ちます。証明書には公開鍵が含まれ、それに対応する秘密鍵はその持ち主だけが握る前提です。ハンドシェイクで相手に送る署名は、この秘密鍵で作られ、受け取った側は証明書内の公開鍵で検証します。秘密鍵を持つ本人しか作れない署名を確かめることで、証明書の名義と実際の通信相手が一致するかを保証する流れです。ここで使われる鍵ペアや電子署名の考え方は公開鍵暗号方式と共通鍵暗号方式の違いとは？仕組み・アルゴリズム・使い分けを解説で基礎から整理しています。mTLSを扱ううえでは、秘密鍵をサーバーやクライアントの外へ出さず安全に保管することが最重要で、鍵が漏れれば相手になりすまされるため、鍵の保管場所とアクセス権の設計が実装の土台になります。鍵をファイルで置くか鍵管理サービスに預けるかの判断軸はSSH接続の公開鍵認証と安全な運用設定と同じで、鍵ファイルの権限と入れ替えの担当を先に決めておくのが実務です。

mTLSの実装｜サービスメッシュとAPIゲートウェイでの証明書配布と運用

仕組みを、動くシステムに落とします。ここでは、どこでmTLSを終端させ、証明書をどう配り、どう入れ替えるかという実装の勘所に絞って確認します。アプリのコードを大きく変えずにmTLSを効かせる構成が実務では主流です。

サービスメッシュ（Istio/Envoy）でサービス間通信をmTLS化

マイクロサービスの間をmTLSで守る場合、各サービスのコードに認証処理を書き込むのではなく、サービスメッシュに任せる構成が広く採られます。IstioなどのサービスメッシュはEnvoyプロキシを各サービスの脇（サイドカー）に置き、サービス同士の通信をこのプロキシ間のmTLSへ肩代わりさせる構成です。証明書の発行・配布・入れ替えはメッシュの基盤側が受け持つため、アプリケーション開発者は暗号や証明書の細部を意識せずにサービス間通信を相互認証できます。Istioではワークロード間の相互TLSを既定に近い形で有効化でき、通信の暗号化と相手の検証をまとめて満たせます。自分でコードに実装するのに比べ、証明書の自動更新まで基盤側で回せる点が、サービスメッシュにmTLSを寄せる実務上の理由です。メッシュ自体の構成やサイドカー・アンビエント方式の選び分けはIstioのサービスメッシュの仕組みと導入判断で整理しています。

APIゲートウェイやロードバランサでのクライアント証明書の検証

外部の限られたパートナーやデバイスからのAPI呼び出しを守る場合は、APIゲートウェイやロードバランサでクライアント証明書を検証する構成が向きます。呼び出し側にあらかじめ発行したクライアント証明書を持たせ、ゲートウェイが接続時にその証明書を検証して、正規の相手だけを内部へ通す流れです。クラウドのロードバランサにもmTLSでクライアント証明書を検証する機能が用意されており、証明書の検証を入口に寄せることで、背後の各サービスは検証済みの通信だけを受け取れます。この構成では「誰に証明書を配ったか」の管理が要になり、取引先やデバイスが増減するたびに証明書の発行と失効を回す運用は避けられません。呼び出し元を事前に把握できるBtoBのAPI連携やIoT機器の認証で効果を発揮します。入口をどこに置くかの整理はAPIゲートウェイの役割とリバースプロキシ・サービスメッシュとの違いにまとめました。

証明書のライフサイクル：発行・配布・ローテーションと失効管理

mTLSの運用の中心は、証明書のライフサイクル管理です。証明書には有効期限があり、期限が切れると通信が止まるため、切れる前に新しい証明書へ入れ替えるローテーションを止めずに回す必要があります。手作業で数枚を扱う規模なら人手でも回せますが、サービスやデバイスが数十・数百に増えると、発行・配布・更新・失効を人が追うのは現実的ではありません。鍵が漏れた、あるいは端末を廃棄したといった場合には、その証明書を失効させ、以後の接続を拒む処理も要ります。証明書の有効期間を短く保ち、頻繁に自動で入れ替える設計にすると、万一漏れても被害の窓が狭まる点が利点です。ここを設計せずにmTLSを入れると、期限切れによる突然の通信断や、失効し損ねた証明書の悪用といった事故につながります。

mTLS自動化の勘所：cert-managerやSPIFFEで証明書配布を省力化

証明書のライフサイクルを人手で回さないために、自動化の道具が整ってきました。Kubernetes環境では、cert-managerが証明書の発行と自動更新を担い、指定した認証局から証明書を取得して期限前に入れ替えます。cert-managerのCertificateリソースはspec.durationの既定が90日、更新を始めるrenewBeforeは既定で有効期間の3分の2を過ぎた時点（90日なら60日目）です。既定のusagesにはserver authまでしか入らないため、mTLSのクライアント側へ配る証明書ではclient authを明示します。

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: payment-client
  namespace: payment
spec:
  secretName: payment-client-tls
  duration: 720h          # 30日
  renewBefore: 240h       # 期限10日前から更新
  commonName: payment-batch
  usages:
    - client auth
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer

ワークロードに与える証明書の標準としてはSPIFFEがあり、その実装であるSPIREが、各サービスへX.509形式の身元証明書（SVID）を自動発行・更新する仕組みです。SPIFFE IDはspiffe://信頼ドメイン/ワークロード識別子というURI形式を取り、公式ドキュメントではspiffe://acme.com/billing/paymentsという例が示されています。仕様の中身と導入判断はSPIFFEとは？ワークロードIDの標準仕様とSPIREの実装・導入判断を解説で詳しく扱いました。これらを使うと、どのサービスがどの証明書を持つかを宣言的に管理し、短命な証明書を頻繁に配り替える運用を機械に任せられます。自前でスクリプトを組んで証明書を配る方式は小規模なら成り立ちますが、規模が増えるほど自動発行・自動更新の基盤に寄せるほうが、期限切れや配布漏れの事故を減らせる点で有利です。mTLSの導入可否は、この証明書基盤を運用できる体制があるかどうかで大きく左右されます。プライベートCAをAWSで立てる場合の費用と、公開向けのACMとの境界はAWS Certificate Managerの有効期間198日化と料金・採用判断で扱っています。

OpenSSLでプライベートCAとクライアント証明書を発行する検証手順

導入を判断する前に、手元でmTLSを1往復させておくと話が早くなります。ここではOpenSSLでプライベートCAを立て、クライアント証明書を発行し、Nginxで受けてcurlで疎通を確かめるまでを順に置きます。以下のコマンドはOpenSSL 3.5.7で実行し、いずれも戻り値0で完了することを確認した形です。

自己署名のルートCAを作りクライアント証明書に署名するコマンド

プライベートCAは、鍵を1本作って自己署名の証明書を発行するだけで立ち上がります。クライアント証明書の側では、extendedKeyUsageにclientAuthを入れておかないと、サーバー側の検証で用途違いとして扱われる点に注意が必要です。SPIFFE形式のURIをSANに入れておくと、後でSPIREやサービスメッシュへ移すときに識別子を作り直す手間が減ります。

# ルートCAの鍵と自己署名証明書（有効期間3650日）
openssl genrsa -out ca.key 4096
openssl req -x509 -new -key ca.key -sha256 -days 3650 -subj "/CN=Internal Root CA/O=example" -out ca.crt

# クライアントの鍵とCSR（clientAuthとSPIFFE形式のSANを付ける）
openssl genrsa -out client.key 2048
openssl req -new -key client.key -subj "/CN=payment-batch/O=example" -addext "extendedKeyUsage=clientAuth" -addext "subjectAltName=URI:spiffe://example.internal/payment-batch" -out client.csr

# CSRの拡張をコピーして有効期間90日で署名（-copy_extensions はOpenSSL 3.0以降）
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -copy_extensions copyall -days 90 -sha256 -out client.crt

# 用途とSANの確認
openssl x509 -in client.crt -noout -ext extendedKeyUsage,subjectAltName
openssl verify -CAfile ca.crt -purpose sslclient client.crt

最後の2行でTLS Web Client AuthenticationとURI:spiffe://example.internal/payment-batchが並び、client.crt: OKが返れば、クライアント用途として通る証明書ができています。用途の行が空で返るときは-copy_extensionsの指定漏れで、CSRに付けた拡張が署名時に捨てられています。

Nginxのssl_verify_clientで受けてcurlで疎通を確かめる手順

受け側は、Nginxなら数行の追記で足ります。ngx_http_ssl_moduleの公式ドキュメントによるとssl_verify_clientの既定はoffで、onにすると検証結果が$ssl_client_verifyに入り、値はSUCCESS・FAILED:理由・NONEのいずれかです。見落としやすいのがssl_verify_depthで、既定が1のため中間CAを挟む構成ではチェーンをたどり切れずに失敗します。

server {
    listen 443 ssl;
    server_name api.example.internal;

    ssl_certificate     /etc/nginx/tls/server.crt;
    ssl_certificate_key /etc/nginx/tls/server.key;

    # クライアント証明書を必須にする（既定は off）
    ssl_verify_client      on;
    ssl_client_certificate /etc/nginx/tls/ca.crt;
    ssl_verify_depth       2;
    ssl_crl                /etc/nginx/tls/revoked.crl;

    location / {
        proxy_set_header X-Client-DN     $ssl_client_s_dn;
        proxy_set_header X-Client-Verify $ssl_client_verify;
        proxy_pass http://127.0.0.1:8080;
    }
}

疎通の確認は、curlに鍵と証明書を渡すだけで済みます。証明書を付けずに同じURLへ投げると400 No required SSL certificate was sentが返るため、必須になっているかどうかは応答だけで切り分けられます。

# 正常系（クライアント証明書あり）
curl --cert client.crt --key client.key --cacert ca.crt https://api.example.internal/health

# 異常系（証明書なし）: 400 No required SSL certificate was sent
curl --cacert ca.crt https://api.example.internal/health

アプリ側へは$ssl_client_s_dnで渡るRFC 2253形式のSubject DNを見て認可を判定します。この値をそのままログへ書くと証明書の名義が生で残るため、識別子だけを取り出して記録する形に寄せるのが安全です。

IstioとALBでmTLSを有効化する設定と証明書運用の月額費用の目安

手元で1往復できたら、次は基盤側でmTLSを必須にする設定と、その運用にかかる金額を見ます。KubernetesならIstioのPeerAuthentication、AWSの入口ならALBのmutual TLSが受け皿になり、どちらも証明書の発行元をどこに置くかで月額が変わります。

PeerAuthenticationのSTRICT指定とPERMISSIVEからの移行

IstioではPeerAuthenticationでmTLSの要求レベルを決めます。指定できるモードはUNSET・DISABLE・PERMISSIVE・STRICTの4つで、UNSETのまま親の設定が無いときはPERMISSIVEとして扱われる仕様です。入れただけでは平文も通るため、mTLSを必須にしたいなら名前空間の単位でSTRICTを明示します。移行の順序は、まずPERMISSIVEで平文とmTLSの両方を受けながらサイドカーを全サービスへ入れ、平文の接続が消えたことを確認してからSTRICTへ切り替える形です。順序を逆にすると、サイドカー未導入のサービスからの通信が一斉に落ちます。

# 名前空間 payment の全ワークロードでmTLSを必須にする
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payment
spec:
  mtls:
    mode: STRICT
---
# 例外: 移行中のバッチだけ 8080 番を平文で残す
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: legacy-batch
  namespace: payment
spec:
  selector:
    matchLabels:
      app: legacy-batch
  mtls:
    mode: STRICT
  portLevelMtls:
    8080:
      mode: DISABLE

証明書の発行と入れ替えはメッシュの制御基盤が持つため、この2枚のマニフェストの外に証明書ファイルは出てきません。ポート単位で例外を開けるportLevelMtlsは移行期の逃げ道になりますが、開けたまま忘れると平文の穴が残るので、期限を決めて閉じる前提で使います。

ALBのmutual TLS verifyとPrivate CAの月額費用の実額

AWSの入口で受けるなら、Application Load Balancerのmutual TLSに2つのモードがあります。passthroughはクライアント証明書のチェーンをそのままX-Amzn-Mtls-Clientcertヘッダで背後へ渡し、検証はアプリ側の責任です。verifyはALBがX.509v3の検証まで済ませ、X-Amzn-Mtls-Clientcert-Serial-NumberやX-Amzn-Mtls-Clientcert-Subjectといったヘッダで結果を渡します。どちらのモードでもセッション再開は使えないため、短い接続を大量に張る呼び出し元では毎回フルハンドシェイクが走る前提で見積もります。信頼するCAはトラストストアへPEMのバンドル単位で入れ替える形で、証明書を1枚だけ追加する操作は用意されていません。

費用は、社内向けの証明書をどこで発行するかで決まります。AWS Private CAの公式料金は2026年9月時点で次の通りです。

CAのモード	CA 1本の月額	証明書1枚の発行料
汎用モード	400USD	0.75USD（月1000枚まで）
汎用モード（1001枚以上）	400USD	0.35USD（10000枚まで）
短期間証明書モード	50USD	0.058USD（階層なし）

短期間証明書モードは有効期間7日以内の証明書だけを発行するCAで、失効の仕組みを持たずに運用できる代わりに、階層の末端に置く制約と、ACMからこのCAで署名した証明書を発行できない制約が付きます。Kubernetesのように基盤が自動で入れ替える構成なら月50USDで足り、人手で年1回入れ替える運用が混じるなら汎用モードの400USDが必要です。CA1本ぶんの固定費が毎月乗るため、証明書が数枚のうちは自前のOpenSSLベースのCAで回すほうが安く、鍵の保管と失効の責任を自前で持てるかどうかが分かれ目になります。数十枚を超えて発行元が複数になったら、管理サービス側へ寄せるという判断です。こうした証明書基盤の設計や、mTLSを前提にしたクラウド構成の組み立てを外に出して進めたい場合は、インフラ構築（AWS・Google Cloud・Azure）の受託で、認証設計を含めた構成づくりを支援しています。

mTLSを採用する場面と見送る場面｜TLSやAPIキーとの使い分け

mTLSは強力ですが、どこにでも入れる方式ではありません。ここで採用すべき条件と見送るべき条件を切り分け、他の認証方式との使い分けを条件付きで言い切ります。過剰に入れると証明書の運用負荷だけが残ります。

mTLSを採用すべき場面：内部サービス間通信とゼロトラスト構成

mTLSが第一候補になるのは、通信する相手を事前に限定できる場面です。マイクロサービス同士の内部通信、社内システムとバックエンドの連携、決められたパートナー企業とのBtoB API、管理下にあるIoTデバイスからの通信などが典型例です。これらは「つないでくる相手をこちらが事前に把握し、証明書を配れる」という共通点があります。IoT機器を相手にする場合はブローカ側で証明書認証を掛ける構成が近く、ポートやトピック単位の権限設計まで含めた形はMQTTのTLS 8883番と証明書認証・トピックACLの設計で扱っています。ネットワークの内側だからと無条件に信頼せず、通信ごとに相手を検証したいゼロトラストの構成では、サービス間の相互認証を担う中核の部品です。金融など、通信相手を厳格に限定する要件が強い領域でも採用が進んでいます。相手を限定でき、かつ証明書を配って回せる体制があるなら、mTLSは通信の土台に強い認証を敷ける有力な選択肢です。

mTLSを見送る場面：不特定多数の外部公開Webと証明書運用負荷

逆に、mTLSを見送るべき典型が、不特定多数の一般利用者がアクセスする外部公開のWebサイトやサービスです。全利用者にクライアント証明書を事前に配ることは現実的でなく、ログインのたびに証明書を求めれば利用者が離れます。こうした場面では、サーバー認証だけの通常のTLSで通信路を守り、利用者の本人確認はパスワードや多要素認証といったアプリケーション層の仕組みに任せるのが適切です。相手を事前に限定できない通信にmTLSを持ち込むと、証明書の配布と管理の負荷だけが膨らみます。よくある失敗は、証明書のローテーションを設計せずに導入し期限切れでサービスが止まること、失効の仕組みを用意せず漏れた証明書を放置すること、そして小規模なのに自動化基盤ごと抱え込んで運用しきれなくなることです。相手を限定できるか、証明書を回す体制があるかを、導入前に必ず問い直します。

mTLSとAPIキー・OAuth・IPsecの認証方式の使い分け

認証方式は、守りたい対象と相手の性質で選び分けます。APIキーは実装が手軽な一方、キーが漏れれば誰でも使えるため、公開範囲の狭い内部連携や重要度の低いAPIに向く方式です。キーの発行・保管・失効をどう回すかはAPIキー管理の発行・保管・失効とローテーションの実装で整理しており、mTLSへ移すかキーの運用を締めるかの比較材料になります。OAuthは利用者に代わってアプリがリソースへアクセスする委任の枠組みで、mTLSが担う「通信相手そのものの認証」とは目的が異なり、両者は重ねて使えます。ネットワーク層で拠点間をまるごと暗号化・認証するなら、別レイヤの手段であるIPsecとは？仕組み・AH/ESP/IKEとVPNでの使い方、SSL/TLSとの違いと選び方を解説が候補になり、mTLSがアプリケーションに近い通信単位で相手を検証するのに対し、IPsecは通信経路そのものを保護する手段です。要件が「特定のサービス・デバイス同士を強く相互認証したい」なら、mTLSがはまります。

mTLS（相互TLS認証）の仕組みと導入・運用に関するよくある質問

検索されることの多い疑問に、仕組みと運用の両面から簡潔に答えます。

mTLSとは何ですか？

mTLS（相互TLS認証）とは、通信の暗号化に使うTLSに、クライアント側の証明書検証を加えて、接続する両端が互いに相手の身元を証明書で確認する認証方式です。通常のTLSがサーバー証明書だけを検証するのに対し、mTLSではクライアントも証明書を提示し、サーバーがそれを検証します。両者が正規の相手だと確認できて初めて通信を開始するため、なりすましに強い構成になります。

mTLSと通常のTLSは何が違いますか？

認証する方向が違います。通常のTLSはサーバーの一方だけを認証し、クライアントが誰かはTLSの層では確かめません。mTLSはそこにクライアント証明書の検証を足し、双方が相手を認証します。暗号化の仕組み自体は共通で、mTLSはTLSに元から備わるクライアント認証の機能を必須として使う構成です。相手を事前に限定できる内部通信で効果を発揮します。

mTLSにクライアント証明書は必須ですか？

必須です。mTLSはクライアント側の証明書と、それに対応する秘密鍵をクライアントが持つことを前提にします。サーバーは接続時にクライアント証明書を要求し、証明書の正当性と、相手が秘密鍵を持っている証明（署名）を検証する仕組みです。したがって、通信するクライアントの数だけ証明書を発行・配布し、期限前に入れ替える運用が付いて回ります。

mTLSはNginxだけで実現できますか？

受け側の検証はNginxだけで足ります。ssl_verify_clientをonにして信頼するCA証明書を指定し、中間CAを挟むならssl_verify_depthを引き上げれば、正規のクライアント以外は400で弾かれる構成です。ただし証明書の発行と入れ替えはNginxの外側の話で、クライアントへ配る証明書を誰がいつ作り直すかを決めていないと、期限切れの日に通信が止まります。数枚なら手作業、数十枚を超えるならcert-managerやPrivate CAへ寄せる線引きになります。

mTLSはどんなシステムに向いていますか？

通信相手を事前に限定できるシステムに向きます。マイクロサービス同士の内部通信、社内システムの連携、決められた取引先とのBtoB API、管理下のIoTデバイス認証などが典型です。いずれもこちらが相手に証明書を配れる点が共通します。逆に、不特定多数の一般利用者が使う外部公開のWebサイトには向かず、通常のTLSと多要素認証などを組み合わせるほうが実際的です。

mTLSの導入で最も手間がかかるのはどこですか？

証明書のライフサイクル管理です。両端に証明書を配り、期限が切れる前にローテーションで入れ替え、漏れた鍵は失効させる一連の運用を止めずに回す必要があります。サービスやデバイスが増えるほど手作業では追えなくなるため、Kubernetes環境ならcert-manager、ワークロード証明書ならSPIFFEとSPIREといった自動化基盤に寄せて、発行と更新を機械に任せる設計が現実的です。