--- title: mTLS と双方向認証 url: https://doc.liz6.com/ja/networking/05-tls-and-pki/04-mtls-and-mutual-authentication locale: ja area: networking tags: - networking - tls-and-pki date: 2026-06-30 modified: 2026-07-16 description: サーバーが「自分自身」を証明するには TLS 証明書を使用し、クライアントが「自分自身」を証明するには mTLS を使用します。双方が証明書を表示し、検証し合います。ゼロトラストアーキテクチャにおいて、mTLS はサービス間通信のアイデンティティの基盤ですが、証明書の配布とローテーションの運用コストが主な障壁となっています。 --- # mTLS と双方向認証 > サーバーが「自分自身」を証明するには TLS 証明書を使用し、クライアントが「自分自身」を証明するには mTLS を使用します。双方が証明書を表示し、検証し合います。ゼロトラストアーキテクチャにおいて、mTLS はサービス間通信のアイデンティティの基盤ですが、証明書の配布とローテーションの運用コストが主な障壁となっています。 ## 概要 標準的な TLS はサーバーのアイデンティティのみを検証します。mTLS（mutual TLS）はクライアント証明書の検証を追加します。サーバーはハンドシェイク中に `CertificateRequest` を送信し、クライアントは証明書を提示する必要があります。これにより、IP やネットワーク位置に依存せずに双方向でアイデンティティを証明する「ゼロトラスト」ネットワークの基盤が実現します。SPIFFE はサービスアイデンティティを標準化し、Istio/Linkerd は mTLS を使用して service mesh 内の各 pod 間の通信を自動的に暗号化します。独自 CA の構築は mTLS の必須条件です。証明書の発行と失効を完全に制御する必要があります。 ## TLS vs mTLS: ハンドシェイクの違い TLS vs mTLS: 単方向の信頼から双方向の相互検証へ TLS サーバーが証明書を提供 クライアントがサーバーを検証 → 単方向の信頼 mTLS サーバー証明書 + CertificateRequest クライアントも証明書を提供する必要あり → 双方向の相互検証 TLS 1.3 mTLS 簡略化ハンドシェイク Client → Server: ClientHello + key_share Server → Client: ServerHello + key_share + {EncryptedExtensions + CertificateRequest + ...} Client → Server: {Certificate + CertificateVerify + Finished} ↑ 標準的な TLS 1.3 に加え、Certificate + CertificateVerify（クライアント提供）が追加される CertificateRequest に含まれる内容: certificate_authorities（空=任意の CA） signature_algorithms · certificate_extensions（例: SPIFFE OID） ## プライベート CA の管理 mTLS をデプロイする最初のステップ: プライベート CA を構築する ```bash # 1. ルート CA の作成（オフライン、ハードウェアセキュリティモジュールまたはエアギャップ環境のマシン）: openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ca.key openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \ -subj "/CN=Private CA" -extensions v3_ca # 2. サーバー/クライアント証明書の発行: openssl genpkey -algorithm EC -out server.key openssl req -new -key server.key -out server.csr \ -subj "/CN=metrics-agent-001" openssl x509 -req -days 90 -in server.csr -CA ca.crt -CAkey ca.key \ -out server.crt -set_serial 0x01 # 3. 失効（侵害された証明書がある場合）: openssl ca -revoke server.crt -keyfile ca.key -cert ca.crt ``` ## SPIFFE mTLS の証明書 CN/SAN に SPIFFE ID を含めるための標準化されたサービスアイデンティティフレームワーク: ``` SPIFFE ID: spiffe://trust-domain/path trust-domain: 組織/クラスターの識別子 path: サービス/インスタンスの識別子 例: spiffe://liz6.com/metrics-agent/li-cn-node-2 X.509 証明書内: SAN URI: spiffe://liz6.com/metrics-agent/li-cn-node-2 → URI SAN によって検証可能（CN のみではない） SVID (SPIFFE Verifiable Identity Document): = X.509 証明書（短期間: デフォルト 1 時間）+ 秘密鍵 → SPIRE agent によって自動的にローテーションされる ``` ## Service Mesh (Istio/Linkerd) Service Mesh における mTLS: アプリケーションコードは意識しない control plane (istiod / linkerd-identity) 短期証明書の発行 · 自動ローテーション Pod A sidecar proxy Envoy / linkerd-proxy mTLS sidecar proxy Envoy / linkerd-proxy Pod B アプリケーションコードは mTLS の存在を知る必要がない 各 sidecar は control plane から短期証明書を取得し、自動ローテーション、自動 mTLS を実行する ## 比較 | | mTLS | API Key | JWT (OAuth2) | |---|---|---|---| | トランスポート層 | L4 (TLS ハンドシェイク段階) | L7 (HTTP ヘッダー) | L7 (HTTP ヘッダー) | | アイデンティティの紐付け | 証明書 (CN/SAN + 有効期限) | key 文字列 | claims (sub, exp, aud) | | ローテーション | CA による再発行 | 新規 key の生成 | 短命 TTL + refresh | | 失効 | CRL / OCSP | 失効 DB による失効 | 短命 TTL（自然失効） | | ミドルウェアのオーバーヘッド | 低い (TLS そのもの) | 中程度 (key の検証) | 中程度 (JWT の検証) | | ゼロトラスト互換性 | ✓ (SPIFFE) | ✗ | △ (トークン署名に PKI が必要) | ## 参考 - **RFC**: 8446, 8705 - **SPIFFE**: spiffe.io, github.com/spiffe/spire - **Istio**: istio.io/latest/docs/concepts/security/#mutual-tls-authentication *Keywords: mTLS, client certificate, SPIFFE, SPIRE, service mesh, private CA, certificate revocation, SVID*