本記事を読むとSSL通信の大枠が捉えられるとおもいます。
SSL通信とは？TLSとの違いは？キートラストとキーストアって
っという疑問に答える記事になっていますので、読んでいただいくと
実際にSSL通信を実装するとか、nginxで機能させるとかの実務が楽になるとおもいます。
ですので読者の対象はまだ、SSL通信をご理解されている方向きです
セキュリティっていうのは
AさんとBさんがやりとり(通信)している状態を考えます。
想像してほしいのは、道端でばったりあって会話している訳ではなく
離れた場所での会話（やりとり）です。
つまりは、ネット上での会話です。もしくは、電話での会話を想定するのもいいでしょう。
AさんとBさんは、内緒話もしたいので、以下のようなことを自然におもいます
・他の人に盗み聞きされたくない
・AさんはBさんがBさん本人であることを保証して欲しい
・(逆に)BさんはAさんがAさん本人であることを保証して欲しい
・音声が途中で改ざんされていだろうか？
みたいなこと（セキュリティー）を心配している。
まぁ、ほとんどの人は心配しないのだけど、オンライン上では様々な重要なやりとり
が交わされている。（買い物、契約、個人メール、プライベートチャット、などなど）
されて、
ここまでで
セキュリティというもののイメージはついたかと思います。
さて
実際のネットの世界では、これらがどのように担保されているのだろうか？
（ここでネットの世界といった時、ほとんどhttp通信なので、という前提）
それは
Httpsである。
httpプロトコルとは、説明しなくてもいいと思うが
httpプロトコルを使った通信で、ブラウザが会話するのはこのプロトコル（通信方法）だ。
普通のhttp通信はセキュリティーはない。です。
そこでhttpsですが、内部の技術はSSL/TLSという通信方法が実装されています。
TLS(Transport Layer Secure)ということでOSI7層を思い出しましょう。
物理・リンク・ネットワーク(IP)・トランスポート・セッション・プレゼン・アプリ
でしたね。
このトランスポートレベル、つまりはTCPレベルで安全に（暗号とか認証とかしてますよ）
という通信方法である。
SSLとTLSの違いについては、両者とも同じく、上で説明したようなセキュアな通信方法のことで
SSLはバージョン3までいって、そのあとTLSに名前が変更されたのだけど、TLSのほうは名前が浸透せず
いまだにSSLって呼ばれているだけです。w
この記事では
真とされていないけど、今の状態を正しく認識するためにTSLと積極的に読んでいきます。
TLS証明書とはなんでしょうか？
これはBさんがBさんであるという本人確認みたいな証明書です。
戸籍謄本とか、免許証みたいなものですね。
これは自分で発行するわけにはいきません。そんなものは偽装できてしまいますから、これがいわゆるオレオレ証明証です
はい、このTLS証明証は通信する相手を証明するためにサーバー側が用意します。
あとは、クライアント側とサーバー側で暗号化、復号化とかクライアントで証明書が正しいかどうか、とか色々チェックする
ながれがあります。
さて、
このTLSの実装ですが、だれが、どこでするのでしょうか？
もしあなたがREST APIの開発者だったら あなたのAPIにTLSを実装するにはどうすればよいのでしょうか？
方法は二つあります。
１。自分でTLSを実装する
２。手前にロードバランサーかプロキシーをたててapache/ngixとかでTLSをサポートする。
一つ目ですが、javaとかでの実装例は紹介されています。また、脆弱性をこなさないように注意した実装が少ないことも注意喚起しています。http://www.dracula.mydns.jp/blog/?p=316
二つ目は、こっちのほうが主流なのではないでしょうか？もしすべてのアプリケーションでTLSを実装しないといけない。つまりはnginx（薄いロードバランサ）とアプリケーションの間のローカル通信にいてもてhttpsを担保するような高いレベルのセキュリティを求めるのはどんなシステムでしょうか。まぁTLSの通信コストが下がっているなら、全部TLSのほうがあとあと困らないという考えだったらり、あるいは、実装コストとリスクを鑑みてローカルでの通信はhttpで良くとする考えに二分されるのではないでしょうか。
実装の流れTLSの処理の流れは
KeyStoreをインスタンス化する
KeyManagerのアルゴリズムを選ぶ、インスタンス化する
TrustManagerをインスタンス化する
SSLContextをインスタンス化する。この時、KeyManagerとTrustManagerを渡している
これで終わり。
これはどんなcertificateも通してしまうダメ（脆弱性のある）な！実装例です。
https://futurestud.io/tutorials/retrofit-2-how-to-trust-unsafe-ssl-certificates-self-signed-expired
こいう
実装例が出回ると、脆弱性を配布していと、至るところでエンジニアが実装をコピペしてセキュリティーホールを
作っていく。ということ懸念して記事もあるので、自分でRFCちゃんと読んでちゃんと勉強して知った上で実装してね
キーストアとは
JAVAにはJSSEというセキュリティーのライブラリというかコンポーネントがありまして
JSSEではTLS通信をkeystoreとtruststoreという二つのファイルをつかって行うようです
KeyStore(キーストア）とは自らのサーバーの証明書を保存する場所（ファイル）です
トラストストア(TrustStore）とはそのサーバー自らが信頼するCA( Certificate Authority認証局)の証明書を保存する場所（ファイル)です
で
この証明書っていうのはチェーン構造になっているってこと！
自分の証明書つくるですやん！
これはだれかがCA認めてくれた、っていう証がないとだめなの！
つまり俺 <---CA1 <-- CA0 <--- Root認証局 みたいな
で、
相手の認証の時も、お前はだれだ？誰が親認証局？その親っておれのTrustStoreに登録されている？
みたいに認証するわけです。
ながれも合わせて説明するとTLS通信はこんな感じです
要は
AさんとBさん（サーバ役としましょ）が
TLS通信するにあたって
A -------内緒話しよーぜ(tls)--------> B
A <------いいぜ。俺はこういう物だ！と証明書を送りつける(keystore)-------- B
A ちょっとまってねー。信頼データベース(TrustStore)に照合するわね
A ------いいわよー。こんどは私のこういうものですーっと証明書を送りつける(keystore)--------> B
ふむふむ、君は私のTrustStoreに照合して、うん。OKだ。B
A <---- とここまでに共通鍵も交換しているので、それで安全に通信できる、って仕組み ----> B
以上です。
参考参照;
本、投稿記事を読んだあとに、こういうハンズオンな記事を読むと理解が深まると思う。http://a4dosanddos.hatenablog.com/entry/2015/03/29/125111
図とかもあってこれがわかりややすい。キーストア、トラストストアの説明もあり https://codezine.jp/article/detail/105
キーストア、トラストストアの説明 from oracle https://docs.oracle.com/cd/E19416-01/820-5959/ggffo/index.html