見えるセキュリティ

TLSの相互認証（mTLS）

MUTUAL TLS

この概念とは？

TLSの相互認証（mTLS）は、ClientとServerが、証明書と署名でお互いを確かめる方法です。Serverだけを証明書で確認する場合に加えて、Serverも接続してきたClientを確認します。

証明書は相手へ送りますが、秘密鍵は送りません。証明書に対応する秘密鍵を使って署名し、その鍵を使えることを相手に示します。今回はTLS 1.3の例で、この流れを見てみましょう。

THEME
crypto
KIND
protocol
REVIEW
self-reviewed ·

ClientとServerが、互いの証明書と署名を確認する流れ

双方の証明書と、信頼する発行元などの設定は準備済みとします。この例ではServerがClientの証明書認証を必須にしています。

接続の準備 → データ通信時間は上から下へ ↓
Client接続する側
Server接続先
  1. ClientHello
    通信方式の候補・今回の鍵共有用の公開値
    ClientからServerへ

    Client証明書はまだ送らない。双方の証明書・署名鍵・信頼設定は準備済み。

STEP 1 まで表示しています。続きは「次へ」で追加します。

  • Clientから送る
  • Serverから送る
  • 端点内の処理には通信矢印を付けない

縦の間隔・動く速さは実際の処理時間ではありません。STEPは学習上の区切りで、パケット数や往復数とは別です。

STEP 01 / 7

Clientが接続を始める

STEP 1 / 7: Clientが接続を始める

現在のSTEP 1STEP 2STEP 3STEP 4STEP 5STEP 6STEP 7

Clientは、安全な通信を始めるための挨拶を送ります。通信に使う方式の候補と、今回の鍵共有に使う公開情報を伝えます。

このSTEPで押さえること

署名用秘密鍵と、今回の鍵共有の一時秘密値は別の値です。秘密は端点内に保ち、相手には公開情報を送ります。

技術的な詳細を見る

TCP接続後の、新しいTLS 1.3フルハンドシェイクを扱います。今回はECDHEで接続ごとの共有秘密を準備し、双方の証明書で認証します。証明書の署名用秘密鍵と、ECDHEの一時秘密値は別の値です。ClientHelloには通信方式の候補とkey_shareの公開値を含めます。Client証明書はまだ送りません。 双方の証明書・対応する署名用秘密鍵・信頼設定は事前に準備済みです。ClientとServerが同じCAや公開Web向けCAを使うことは必須ではありません。証明書の発行・配布・更新やCAの階層は図では省略します。 mTLSの考え方はTLS 1.2にもありますが、この図はTLS 1.3の例です。TLS 1.2の手順、PSK再開、0-RTT、HRR、接続後認証、QUIC、証明書圧縮は扱いません。ClientとServerはここで描くTLS接続の端点とし、プロキシによるTLS終端や認証情報の転送も省略します。

パネルの開閉ではSTEPは変わりません。

この概念の要点

  • 要点

    ServerもClientを確かめる

    mTLSでは、ClientがServerを確認するだけでなく、ServerもClientの証明書と署名を確認します。自分を示す側と相手を確認する側を、双方が担当します。

  • 要点

    証明書と署名には別の役割がある

    証明書は公開鍵と識別情報を伝えます。その公開鍵に対応する秘密鍵を使えることは、接続時の署名で示します。証明書のコピーを持っているだけでは、この署名を作れることにはなりません。

  • 注意

    信頼の設定と鍵の管理が必要

    どの発行元を信頼するかを設定し、証明書の有効期間や用途などを確認します。Client側にも証明書の配布・更新や秘密鍵の保護が必要です。証明書を交換するだけで安全になるわけではありません。

  • 要点

    認証と認可は別

    認証は相手を確かめること、認可は何を許すかを決めることです。mTLSで確認できたClientにも、許可された情報や操作の範囲があります。

理解確認

mTLSでClientの証明書と署名を確認できた後の説明として、正しいものはどれでしょう？

参考資料

RELATED CONCEPTS

関連Concept