原理から学ぶネットワーク・セキュリティ 第5回 電子証明書と認証局：ITproの問題点を挙げていきます.
一通り作成しました.
公開鍵暗号では，「秘密鍵」と「公開鍵」の2つの鍵をペアにして使います。この2つの鍵は，次の2つの性質を持っています。
性質1）秘密鍵から公開鍵は容易に生成できるが，その逆は非常に困難（図1）。
性質1は間違いです. 秘密鍵から公開鍵は容易に生成できる
ことは公開鍵暗号の必要条件ではありません. 公開鍵から容易に秘密鍵が生成できては公開鍵暗号として成り立たないので, この点は問題ありません.
性質2）秘密鍵で暗号化した情報は，そのペアである公開鍵でなければ復号化できない。また公開鍵で暗号化された情報は，そのペアである秘密鍵でなければ復号化できない（図2）。
性質2も, 公開鍵暗号の必要条件ではありません. RSAでは成り立ちます.
利用方法2）情報を認証するには，秘密鍵で暗号化して公開鍵で復号化する。暗号化された情報は公開鍵さえ入手すれば誰でも復号化できる。その情報を暗号化した人は，秘密鍵の持ち主に限られる（図5）。
以上の記述に間違いが含まれていることは前回(「原理から学ぶネットワーク・セキュリティ 第4回 ハッシュ関数」の問題点)で指摘済みです.
公開鍵暗号方式は，それ以前の「鍵は通信相手以外の誰にも漏らしてはならない」という常識を，「（公開鍵は）誰にでも配布してよく，認証にも利用できる」に覆してしまったのです。 特に利用方法2は，情報全体を暗号化するのではなく，その情報とともに情報のハッシュ値を公開鍵で暗号化（電子署名する）して送れば，受信側で両者を比較して情報内容の改ざんも検出できます（図6）。
同様の間違いが含まれています. 電子署名における誤解は以後指摘しないこととします.
この部分は問題ありません. PGPの場合にはSSLと違った信頼モデル「信頼の輪」があることを書いてもよいかもしれませんが, 書くと混乱を招いてしまうかもしれません.
この証明書の連鎖は最終的に，CA自身が発行する自己署名証明書で終わります。自己署名証明書（ルート証明書ともいう）は，CAが自分自身の秘密鍵で署名した公開鍵のことです。証明書の署名者を次々とさかのぼり，最終的に自己署名証明書までたどり着いたら，その連鎖にある証明書はすべて信頼できるものと見なされます。
自己署名証明書（ルート証明書ともいう）
という表現には違和感があります. 自己署名証明書とは, 発行者自身の電子署名が付されたPKIの証明書。
(はてなキーワードから引用)のことです. ルート証明書とは, デジタル証明書を発行する認証局が、その正当性を証明するために自ら署名して発行するデジタル証明書
(e-words.jpから引用)のことです. ルート証明書は, 通常自己署名証明書となります. 自己署名証明書は, 単に自分で作成した証明書に自分で署名すれば作成できますので, ルート証明書とはいえない自己署名証明書も存在します.
以後の自己署名証明書としている部分の一部は, ルート証明書と置き換えたほうがよいでしょう.
この自己署名証明書は，ネットワーク上の至る所で発見されます。信頼できるものもあれば，悪意から作成されたものもあるでしょう。どれが信用できるものでどれが信用できないかは，残念ですがユーザーが自分で判断しなければなりません。
ソフトウェア(OS, ブラウザなど)に組み込まれてもおらずインターネット以外の方法で正当性を確認できない自己署名証明書は信用しないと判断すればよいでしょう. ソフトウェアの信頼性は, 別に担保する必要がありますが.
ここは問題ありません.
一つは，通信内容の暗号化。もう一つは，今見ている画面が，本当に目的のサイトであることを保証するためです。
通信の暗号化
には, 共通鍵暗号による暗号化だけではなく, MACによるメッセージ改ざんに対する保護も含まれていることを付け加えておいたほうがよいでしょう.
では，どういう仕組みで電子証明書を使って，情報を暗号化するのでしょうか。画面が表示されるまでの手順を示したのが図11です。SSLというプロトコルが使われます。SSLの目的は画面情報そのものを暗号化するのではありません。一般には送りたいデータを暗号化するときは，高速処理ができる共有鍵暗号を使います。その共有鍵を安全に相手まで届けるのに公開鍵暗号を使います。SSLも例に漏れず，公開鍵は共有鍵を暗号化するために使います。
途中に飛躍がある文章ですが, それは置いておきます.
SSLでは, 鍵交換にRSAを利用できます. しかし, Diffie-Hellman鍵交換(鍵合意)アルゴリムも利用できます. ですから, 公開鍵は共有鍵を暗号化するために使います。
というのは常には成り立ちません.
また実際に交換(合意)されるのは鍵の種のようなもので, そこから共通鍵暗号の鍵(や初期化ベクトル)やMACの鍵が生成されます.
サーバー側はこれに対しServerHelloで応答します。Server Hello信号には，選択した暗号方式と，サーバー側の電子証明書が含まれています。電子証明書には，公開鍵と電子署名が含まれています。署名者の電子証明書が最初からブラウザにインストールされていれば，この公開鍵を使って，サーバーの公開鍵の正当性を検証します。このようにしてクライアントはサーバー側の公開鍵を安全に入手できました。
この部分では, SSLのHandshakeを単純化しすぎています. SSLのServerHelloメッセージには, サーバ側の電子証明書は含まれていません. 暗号化の方式などが含まれます. サーバの証明書を送信するのは, ServerHelloメッセージとServerHelloDoneメッセージの間に送られるServer Certificateメッセージです.