ネスぺ試験時の学習まとめ。
AliceがBobにメッセージを送るとする
Alice → Bob
1.
アリスはCSR（Certificate Signing Request）を作成し、CA（Certificate Authority）に送信する。
2.
CAはCSRを受け取り、その中に含まれるアリスの情報を確認し、アリスの公開鍵（Public Key）を含む証明書を発行するための審査を行う。
3.
CAはCAの秘密鍵（Private Key）を使用して、「アリスの情報とアリスの公開鍵」のハッシュ値を暗号化し、電子署名（Degital Signature）を作成する。
データからハッシュ値を生成し、それを秘密鍵で暗号化したものを電子署名という。
また、秘密鍵は署名鍵、公開鍵は検証鍵とも呼ばれる。
電子署名は秘密鍵によって暗号化され、公開鍵でしか復号することができないため、リアル世界における「署名」と同じ役割を果たす。
リアル世界での署名は、筆跡は改ざんできないことを前提としているので、署名した本人にしか作成することができない。
ネットワーク世界における電子署名では、秘密鍵は暗号化を行う者しか保持していないことが前提とされているため、リアル世界同様に、秘密鍵の所有者しか暗号化できない。
4.
3で作成した電子署名とアリスの情報、アリスの公開鍵を含む証明書がまとめてCAからアリスに返却される。
5.
アリスはCAから受け取った電子証明書を自分の端末にインストールする。
6.
アリスはボブに送りたいメッセージをハッシュ化し、さらにアリスの秘密鍵を使用して、電子署名を作成する。
7.
アリスはメッセージ、6で作成した電子署名、5で受け取った電子証明書をボブに送信する。
一方、Bob
8.
ボブは受信したメッセージをハッシュ化し、同封の電子証明書に含まれたアリスの公開鍵を使用して電子署名を復号（ハッシュ値が取得される）。
２つのハッシュ値が一致するかを比較する。
9.
電子証明書に含まれた「アリスの情報とアリスの公開鍵」をハッシュ化する。
また、同じく電子証明書に含まれたCAの電子署名を、CAの公開鍵を使用して復号する（ハッシュ値が取得される）。
２つのハッシュ値が一致するかを比較する。
10.
8と9の比較が一致すれば、ボブは受信したメッセージが確かにアリスが送信したものであることを検証できたことになる。
電子証明書は、公開鍵を証明するための情報セットと考える。
CAの検証が必要な場合
上の例では、BobはCAを「信頼のおけるCAである」と考えていることを前提としている。
ここで、CAにはルートCA（Root CA）と呼ばれる、政府機関のCAである、認知度が高いなどの理由で第三者を介さずに自身の正当性を主張することができるCAと、ルートCAに正当性を証明してもらうことで自身の正当性が主張できる中間CA（Intermediate CA）が存在する。
CAをルートCAを見なすかどうかは、開発者が判断する。
また、中間CAが別の中間CAによって正当性を証明されていることもあるが、上位証明者を辿っていけば必ずルートCAにたどり着く。（というより、最後にたどり着いた証明者がルート証明者）
上の例で、もし仮に、Bobが中間CAを信頼していない場合、ルートCAを介した中間CAの検証が行われることもある。
1.
Bobは、ルートCAの電子証明書に含まれた電子署名を、同じくルートCAの電子証明書に含まれているルートCAの公開鍵で復号する（ハッシュ値が取得される）。
ルートCAの電子証明書は、通常、リストとしてOSやWebブラウザにインストールされている。
またユーザが知らないうちに、定期的な更新もされている。
ブラウザは有効期限の切れた証明書リストも保持している。これをCRL（Certificate Revocation List）と呼ぶ。
2.
Aliceから受信した「中間CAの電子証明書に含まれていた中間CAの公開鍵と、ルートCAの電子証明書に含まれていた情報」からハッシュ値を生成する。
3.
1と2で取得した２つのハッシュ値が一致するかを比較する。一致すれば、中間CAはルートCAによって信頼できることが証明されたことになる。