TLSとその前身であるSSLは、ネットワーク上での通信セキュリティ（ある場合には機密性と完全性、他の場合には非否認性）を提供する暗号プロトコルです。
片方向TLS、または通常のTLSでは、クライアントが接続しようとすると信頼できる認証局がX.509サーバ証明書を作成します。 公開鍵基盤（PKI）は、信頼性の管理と証明書の配布に責任を負います。 認証局 (CA) は PKI において非常に重要な役割を果たします。 X.509 証明書は、サーバーに関するいくつかの情報と、CA によってデジタル署名されたサーバーの公開鍵にほかなりません。
サーバーは、どんなクライアントからの接続でも許可するように設定したり (一方向 TLS のように)、接続しようとするクライアントに認証を求めるように設定したりすることができます。 つまり、クライアントが認証するためには、クライアント証明書が必要なのです。 双方向TLS認証、別名クライアント証明書認証付きTLSでは、認証プロセスを強固にするために、サーバー証明書に加えてクライアント証明書も関与します。 サーバー証明書と同様に、クライアント証明書には、クライアントの身元に関する基本情報、その公開鍵、およびこの情報が本物であることを証明するCAのデジタル署名が含まれます。 クライアント証明書は、サーバーが信頼するCAによって署名されるべきで、接続前に両方のX.509証明書が存在すべきことは明らかです！
TLSが十分に安全なのは、それを認証と併用する場合です。 Gmail の Web インターフェイスを使用する場合、パスワードに加えて、ブラウザーの https 機能を介した一方向 TLS を使用します。 パスワードを使用しない場合、正規のサーバーに接続されたことは本人しか確認できませんが、Gmailサーバーは本人確認ができないため、安全な接続とは言えません。 もし Gmail が双方向の TLS を提供していれば、パスワードを入力しなくても簡単に接続でき、その接続は安全であると考えられます。 たとえば、ある組織がサーバーへの TLS 接続を、その組織の正当なパートナーまたは顧客からのものだけに制限したい場合です。 クライアントのIPホワイトリスト化は、IPが詐称される可能性があるため、セキュリティ上良い方法とは言えません。
2way TLSハンドシェイクのプロセスを単純化すると、
- A client sends a request to access to protected information on the server.
2.Server presents its X.509
3. クライアントは、CAの公開鍵によるサーバの公開鍵のデジタル署名を検証することにより、サーバの証明書を確認する。
4. 最後のステップが成功した場合、クライアントはサーバに証明書を送信する。 サーバーは手順3と同じ方法でクライアントの証明書を検証する。
6. 成功すると、サーバーはクライアントに保護された情報へのアクセスを与える。
双方向TLSを扱うためにApache Webサーバーを設定する必要がある場合は、この文書を参照すること。 http://www.robinhowlett.com/blog/2016/01/05/everything-you-ever-wanted-to-know-about-ssl-but-were-afraid-to-ask/