デジタル証明書

【図解】クライアント証明書(https,eap-tls)の仕組み ~シーケンス,クライアント認証,メリット~

TLSにおけるクライアント認証とは

TLS の規格としては、サーバの認証は必須ですが、クライアントの認証はオプション扱いとなっています。サーバの設定によっては、クライアント証明書による認証を強制させることができます。

以下の図の左側はクライアント認証しない場合の TLS シーケンス、右側はクライアント認証をする場合の TLS シーケンスのイメージです。

相手の認証をするためには相手の証明書のルート証明書を事前に『信頼するルート証明書』としてインストールしている必要があります

つまりクライアント証明書で相手を認証するには、サーバ側に「クライアント証明書のルート証明書」が必要になります。逆もまた然りです。

この仕組みについては下記ページの『デジタル証明書を信頼する条件』で図解してますので併せてご参照下さい。

【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜
前提知識 デジタル証明書 (電子証明書) の理解のためにはまず RSA 公開鍵...

なお、クライアント証明書とサーバ証明書の認証局は同一でも構いません。その場合はクライアント証明書のルート証明書とサーバ証明書のルート証明書が同一のものになります。

クライアント証明書を使う具体的なシーンと構成の例

Web サーバをインターネット公開し、特別に許可を与えた顧客のみアクセス許可したい』という場合、ID/パスワードによる認証も可能ですが、その代わりにクライアント証明書による認証とすること、もしくは ID/パスワードおよびクライアント証明書の認証を併用することができます。

これにより、通常の ID パスワードによる認証よりもセキュリティ強度を高めることができます

Web サーバ側には、クライアント証明書のルート証明書及び中間証明書をインストールしておき、さらにクライアント証明書の提示を求める設定とします。

クライアント証明書は、システム管理者等が構築した証明機関に発行を依頼することで、生成されます。クライアント証明書の発行依頼は、エンドユーザ自らが行うパターンもあれば、システム管理者が行うパターンもあります。

以下の記事では Windows Server 2016 でエンドユーザがクライアント証明書を発行依頼できるように構築する手順を示しています。

2階層CAの構築(Windows2016) ④-1 無料クライアント証明書の発行手順(クライアントがWEBブラウザで要求)
エンタープライズ中間CAサーバ上で、クライアント証明書の雛形を作成します。 ク...

そして以下の記事ではシステム管理者がサーバ上で発行する手順を示しています。

2階層CAの構築(Windows2016) ④-2 無料クライアント証明書の発行手順(サーバ上で発行)
2階層CAの構築(Windows2016) ④-2 前回はクライアントが証明書...

この例のケースではインターネットを介していることから、エンドユーザに発行させる構成だと不正に発行されてしまったりする可能性が出てくるのでふさわしくありません。

システム管理者が発行依頼、ダウンロードし、顧客に安全な方法で渡す (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

クライアント証明書によるクライアント認証を行います。

コメント

  1. タカヒロ より:

    現在、クライアント認証について勉強中なのですが、とてもわかり易い図で感謝致します。ただ、一番最初の図の右側の[クライアント認証あり]のサーバの所に「クライアントの秘密鍵」とありますが、これは「サーバの秘密鍵」の間違いですよね?それと、認証パターンのパターン1の図にクライアントから「クライアント証明書をどうぞ」とありますが、このパターン1はクライアント証明書は不要なパターンではないでしょうか?

    • nesuke より:

      タカヒロさん

      コメントありがとうございます。そしてご指摘ありがとうございます。

      仰る通り、ご指摘の2点、ともに図が誤っております。。
      後ほどすぐに修正しますので、まずはご報告です。

タイトルとURLをコピーしました