【図解】クライアント証明書の仕組み~シーケンス、クライアント認証、メリット 〜

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

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

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

相手の認証をするためには相手の証明書のルート証明書を事前に『信頼するルート証明書』としてインストールしている必要があります。つまりクライアント証明書で相手を認証するには、サーバ側に「クライアント証明書のルート証明書」が必要になります。逆もまた然りです。

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

https://milestone-of-se.nesuke.com/sv-advanced/digicert/digital-certification-summary/

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

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

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

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

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

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

https://milestone-of-se.nesuke.com/sv-advanced/digicert/client-certificate-issue-flow/

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

https://milestone-of-se.nesuke.com/sv-advanced/digicert/client-certificat-issue-on-server/

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

システム管理者が発行依頼、ダウンロードし、顧客に安全な方法で渡す(USB手渡しや、暗号化した上でメール送付等)のが適切です。ただし、複製可能なものなので管理は顧客側に委ねられてしまうことに注意が必要です。

クライアント証明書のメリットとデメリット

クライアント証明書は、ユーザ認証においてIDパスワードの代替手段となるものです。

一度インストールすればIDパスワードの入力をせずに済むのが最大のメリットです。無線の認証で毎回IDパスワードを求められるPEAPよりも、一度設定してしまえばクライアント証明書の期限が切れるまで使い続けられるEAP-TLSのほうが使い勝手が良いでしょう。

デメリットは、IDパスワードと違い、PC上に電子ファイルとしてあつかうため、複製が簡単であるため管理が難しいことです。

そのため、クライアント証明書を発行する際には、流出してしまったときに速やかにそれを失効させる手段を用意すべきです。

https://milestone-of-se.nesuke.com/sv-advanced/digicert/certificate-revocation/

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/インフラエンジニアの地位とスキル向上のために

関連記事

IT 技術の進化はとどまることを知りません。矢継ぎ早に新たな技術が出てきたり、数年前の技術が時代遅れになったりと、IT エンジニアは勉強し続ける運命のようです。 それをどう思うかはあなた次第。 ビジネスの基本は『付加価値を与える[…]

IMG
関連記事

nesuke の考える NW エンジニアの2つの道 ネットワークエンジニアには 2 つの道があります。 1 つはネットワーク構築一筋で、L4 までをひたすらきっちりと構築していく道。 もう 1 つはネットワークを軸として深堀し[…]

IMG