TLSにおけるクライアント認証とは
TLS の規格としては、サーバの認証は必須ですが、クライアントの認証はオプション扱いとなっています。サーバの設定によっては、クライアント証明書による認証を強制させることができます。
以下の図の左側はクライアント認証しない場合の TLS シーケンス、右側はクライアント認証をする場合の TLS シーケンスのイメージです。
相手の認証をするためには相手の証明書のルート証明書を事前に『信頼するルート証明書』としてインストールしている必要があります。
つまりクライアント証明書で相手を認証するには、サーバ側に「クライアント証明書のルート証明書」が必要になります。逆もまた然りです。
この仕組みについては下記ページの『デジタル証明書を信頼する条件』で図解してますので併せてご参照下さい。
なお、クライアント証明書とサーバ証明書の認証局は同一でも構いません。その場合はクライアント証明書のルート証明書とサーバ証明書のルート証明書が同一のものになります。
クライアント証明書を使う具体的なシーンと構成の例
『Web サーバをインターネット公開し、特別に許可を与えた顧客のみアクセス許可したい』という場合、ID/パスワードによる認証も可能ですが、その代わりにクライアント証明書による認証とすること、もしくは ID/パスワードおよびクライアント証明書の認証を併用することができます。
これにより、通常の ID パスワードによる認証よりもセキュリティ強度を高めることができます。
Web サーバ側には、クライアント証明書のルート証明書及び中間証明書をインストールしておき、さらにクライアント証明書の提示を求める設定とします。
クライアント証明書は、システム管理者等が構築した証明機関に発行を依頼することで、生成されます。クライアント証明書の発行依頼は、エンドユーザ自らが行うパターンもあれば、システム管理者が行うパターンもあります。
以下の記事では Windows Server 2016 でエンドユーザがクライアント証明書を発行依頼できるように構築する手順を示しています。
そして以下の記事ではシステム管理者がサーバ上で発行する手順を示しています。
この例のケースではインターネットを介していることから、エンドユーザに発行させる構成だと不正に発行されてしまったりする可能性が出てくるのでふさわしくありません。
システム管理者が発行依頼、ダウンロードし、顧客に安全な方法で渡す (USB 手渡しや、暗号化した上でメール送付等) のが適切です。
ただし、複製可能なものなので管理は顧客側に委ねられてしまうことに注意が必要です。
クライアント証明書のメリットとデメリット
クライアント証明書は、ユーザ認証において ID パスワードの代替手段となるものです。
一度インストールすれば ID/パスワードの入力をせずに済むのが最大のメリットです。
無線の認証で毎回 ID/パスワードを求められる PEAP よりも、一度設定してしまえばクライアント証明書の期限が切れるまで使い続けられる EAP-TLS のほうが使い勝手が良いでしょう。
デメリットは、ID/パスワードと違い、PC 上に電子ファイルとしてあつかうため、複製が簡単であるため管理が難しいことです。(秘密鍵のエクスポートを出来ないようにすることも可能なのでその場合はそのリスクを防げる)
そのため、クライアント証明書を発行する際には、流出してしまったときに速やかにそれを失効させる手段を用意すべきです。
https 通信のクライアント(ユーザ)認証パターン
パターン0 認証無し (Google 等)
クライアント認証無しで https 通信を行うパターンです。
サーバの認証およびサーバとの暗号化通信は行いますが、クライアントについては誰から接続に来ても問題視しません。
パターン1 https の TLSセッション確立後に http の仕組み(一般的なブラウザでのログイン)で ID/パスワード認証 (楽天など eコマースサイト)
TLS の仕組みとしてのクライアント認証は行いません。なのでクライアント証明書は不要です。
ですが物品購入などのお金が絡む処理についてはログイン後じゃないと処理できないようになっていますので、 http 通信プロトコルの枠組みで ID/パスワードを送ります。平文で送ると危険なので、TLS で http を暗号化して (つまり https にして) 送ります。
パターン2 TLSネゴシエーション中に TLS の仕組みでクライアント証明書認証 (三菱 UFJ 銀行の 法人取引用サイト Biz STATIONなど重要取引サイト)
大きな金額の取引だとクラッカー等に狙われやすいので、高セキュリティを実現するクライアント証明書による認証を強制させます。
IEEE802.1x のクライアント(ユーザ)認証パターン
パターン1 PEAP/EAP-TTLS
クライアントの認証は (クライアント証明書は使わず) ID パスワードを使います。
PEAP と EAP-TTLS は違いはほぼないですが、PEAP は Microsoft 独自規格、EAP-TTLS は IEEE 規格です。
ただし、さらにややこしい話で、Windows では PEAP は使えますが EAP-TTLS は使えないので PEAP のほうがよく使われています。
パターン2 EAP-TLS
クライアント証明書によるクライアント認証を行います。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント
現在、クライアント認証について勉強中なのですが、とてもわかり易い図で感謝致します。ただ、一番最初の図の右側の[クライアント認証あり]のサーバの所に「クライアントの秘密鍵」とありますが、これは「サーバの秘密鍵」の間違いですよね？それと、認証パターンのパターン１の図にクライアントから「クライアント証明書をどうぞ」とありますが、このパターン１はクライアント証明書は不要なパターンではないでしょうか？
タカヒロさん
コメントありがとうございます。そしてご指摘ありがとうございます。
仰る通り、ご指摘の2点、ともに図が誤っております。。
後ほどすぐに修正しますので、まずはご報告です。
図を修正しました。
これに懲りず、今後も当サイトを宜しくお願い致します。
コメント失礼します。
SSL-VPNでファイアウォールを使ってクライアント証明書認証をする際に、クライアント側に「サーバ証明書のルート証明書」がない場合でもVPN通信は成立するのでしょうか？
はい。クライアント側がそのリスクを受け入れれば成立します。
これはクライアント証明書を使うかどうかは関係なく、Webサイトに例えれば、クライアント側がサーバ証明書エラーの警告を無視するかどうか、と同じ話です。
nesuke様
ご回答ありがとうございます！
構築する予定があり、疑問に思ったので確認させていただきました・・・