mTLSにおける「お互いの検証」って何をしているの？
インターネットでのやり取りを安全にするために、TLS（Transport Layer Security）を使うことは一般的ですよね。通常のTLSでは、クライアントがサーバーの証明書を確認し、「このサーバーは本物か？」をチェックします。でも、mTLS（Mutual TLS）では、それに加えてサーバーもクライアントをチェックするのが特徴です。
つまり、お互いに「あなたは本当に信頼できる相手？」と確認し合う仕組みがmTLSです。では、その「確認」とは具体的に何を見ているのでしょうか？
1. サーバー側がクライアントを検証するポイント
まず、サーバー側がクライアントを信頼できるかをチェックする方法を見ていきましょう。
(1) 証明書の有効期限をチェック
クライアントが提示する証明書が、現在も有効かどうかを確認します。
証明書の「有効期限」が過ぎていないか
証明書の発行日が未来になっていないか（例えば、まだ使えない証明書を提示していないか）
これは、身分証明書の「有効期限」を見るのと同じですね。期限切れのパスポートでは飛行機に乗れないのと同じように、有効期限の切れた証明書は受け付けられません。
(2) 証明書の信頼性を確認
クライアント証明書が、信頼できる認証局（CA）によって発行されているかを確認します。
事前に登録した信頼できるCAが発行した証明書かどうか
証明書チェーン（ルートCA → 中間CA → クライアント証明書）が正しくつながっているか
例えば、「このクレジットカードは本当に銀行が発行したもの？」を確認するのと似ています。知らない団体が発行したカードなら、怪しいですよね。
(3) 証明書の内容が正しいか
証明書に含まれる情報が、想定しているクライアントのものと一致するかをチェックします。
証明書の署名が改ざんされていないか
証明書に含まれる**CN（Common Name）やSAN（Subject Alternative Name）**が、許可されたクライアントの識別情報と一致するか
これは、マイナンバーカードの本人確認と同じようなイメージです。
例えば、銀行で新しい口座を作るとき、マイナンバーカードを提示しますよね。でも、単にカードを見せるだけではなく、以下のようなチェックが入ります。
写真の人物と本人が一致しているか？ → （CNやSANの一致）
証明書に記載された名前が、システム側で認識しているクライアントの情報と合っているかを確認します。
たとえば、マイナンバーカードの名前が「田中太郎」なのに、申込者が「鈴木一郎」だったら明らかにおかしいですよね。
カードが改ざんされていないか？ → （証明書の署名検証）
本物のマイナンバーカードであるかをICチップの情報を使って確認します。
証明書も同じで、公開鍵を使って改ざんされていないかを検証します。
公式な機関が発行したものか？ → （証明書チェーンの検証）
マイナンバーカードは政府が発行しているから信用できますが、もし「〇〇町内会が作ったマイナンバーカード」を出されたら、それは怪しいですよね。
証明書も、信頼されたCAが発行しているかを確認することで、不正な証明書を防ぎます。
こうして、マイナンバーカードの本人確認と同じように、証明書の内容が正当なものかをチェックするのです。
(4) 証明書が失効していないかチェック
もし、過去に不正があったクライアントの証明書を使われたら大変です。そのため、証明書が失効されていないかを確認します。
**CRL（証明書失効リスト）**に載っていないか
**OCSP（Online Certificate Status Protocol）**で最新の失効情報をチェック
これは、ブラックリスト入りしたクレジットカードが使えないのと同じ仕組みです。
2. クライアント側がサーバーを検証するポイント
今度は逆に、クライアントがサーバーを信頼できるかを確認する流れを見てみましょう。
(1) 証明書の有効期限をチェック
サーバーの証明書が期限切れになっていないか
証明書の発行日が未来になっていないか
(2) 証明書の信頼性を確認
サーバー証明書が、クライアントが信頼する認証局（CA）によって発行されているか
証明書チェーンが正しく構築されているか
(3) 証明書の内容が正しいか
証明書が改ざんされていないか
証明書に含まれる**CN（Common Name）やSAN（Subject Alternative Name）**が、接続しようとしているサーバーのドメインと一致するか
例えば、api.example.comにアクセスしようとしているのに、証明書のCNが fake.example.com だったら、それは怪しいですよね。偽のサイトに誘導されるのを防ぐためのチェックです。
(4) 証明書が失効していないかチェック
CRL（証明書失効リスト）やOCSPを使って、サーバーの証明書が失効していないか確認
3. 検証が完了するとTLSセッション確立
クライアントとサーバーがお互いの証明書を問題なく検証できたら、TLSセッションが確立され、安全な通信が始まります。
まとめ：mTLSの検証ポイントを整理
mTLSでは、「クライアントがサーバーをチェックする」だけでなく、「サーバーもクライアントをチェックする」ことで、より強固なセキュリティを確立します。
🔍 mTLSのチェックポイント
証明書の有効期限 → 期限切れや未来日ではないか？
証明書の信頼性 → 信頼されたCAが発行したものか？
証明書の正当性 → 改ざんされていないか？
CN/SANの一致 → 期待する相手のものか？
証明書の失効チェック → CRLやOCSPで失効していないか？
このようにmTLSを使うことで、不正なクライアントやサーバーとの通信を防ぎ、安全なネットワークを実現できます。