注：元の回答を急いで書きましたが、それ以来、これはかなり人気のある質問/回答になりました。そのため、少し拡大して、より正確にしました。
TLS機能
「SSL」はこのプロトコルを指すために最も頻繁に使用される名前ですが、SSLは特に90年代半ばにNetscapeによって設計された独自のプロトコルを指します。「TLS」は、SSLに基づくIETF標準なので、TLSを使用します。最近では、Web上の安全な接続のほとんどすべてがSSLではなくTLSを実際に使用している可能性があります。
TLSにはいくつかの機能があります。
- アプリケーション層のデータを暗号化します。（あなたの場合、アプリケーション層プロトコルはHTTPです。）
- サーバーをクライアントに対して認証します。
- サーバーに対してクライアントを認証します。
＃1と＃2は非常に一般的です。＃3はあまり一般的ではありません。＃2に注目しているようですので、その部分について説明します。
認証
サーバーは、証明書を使用してクライアントに対して自身を認証します。証明書は、ウェブサイトに関する情報を含むデータのブロブ[1]です：
- ドメイン名
- 公開鍵
- それを所有する会社
- 発行されたとき
- 期限切れのとき
- 誰が発行したか
- 等。
証明書に含まれる公開鍵を使用して、対応する秘密鍵でのみ復号化できるメッセージを暗号化することにより、機密性（上記1）を達成できます。この鍵ペアをKP1と呼び、後で混乱しないようにします。証明書のドメイン名が、アクセスしているサイトと一致していることも確認できます（上記の2）。
しかし、攻撃者がサーバーとの間で送受信されるパケットを変更できる場合、およびその攻撃者が提示された証明書を変更し、独自の公開鍵を挿入したり、その他の重要な詳細を変更した場合はどうなるでしょうか。これが発生した場合、攻撃者は安全に暗号化されていると思われるメッセージを傍受して変更する可能性があります。
この攻撃を防ぐために、証明書は他の誰かの秘密鍵によって暗号で署名され、対応する公開鍵を持っている人なら誰でも署名を検証できるようになっています。このキーペアをKP2と呼び、これらがサーバーが使用しているキーと同じでないことを明確にします。
認証局
では、KP2を作成したのは誰ですか？誰が証明書に署名しましたか？
少し単純化しすぎると、認証局はKP2を作成し、秘密鍵を使用して他の組織の証明書に署名するサービスを販売します。たとえば、証明書を作成し、Verisignのような会社に支払い、秘密鍵で署名します。[3] Verisign以外の誰もこの秘密鍵にアクセスできないため、この署名を偽造することはできません。
そして、その署名を検証するために、KP2の公開鍵を個人的に取得するにはどうすればよいですか？
証明書で公開キーを保持できることは既に確認しました。また、コンピュータサイエンティストは再帰が大好きです。KP2公開キーを証明書に入れ、そのように配布してみませんか？これは最初は少しおかしな話に聞こえますが、実際にはそれが正確に機能しています。Verisignの例を続けると、Verisignは、彼らが誰であるか、どの種類の署名が許可されているか（その他の証明書）、およびそれらの公開鍵に関する情報を含む証明書を生成します。
これで、Verisign証明書のコピーがあれば、それを使用して、アクセスしたいWebサイトのサーバー証明書の署名を検証できます。簡単でしょ？
まあ、それほど速くありません。どこかからVerisign証明書を取得する必要がありました。誰かがVerisign証明書を偽装し、自分の公開鍵をそこに置くとどうなりますか？その後、サーバーの証明書の署名を偽造することができます。これで、開始したところに戻ります。中間者攻撃です。
証明書チェーン
再帰的に考え続けると、もちろん、3番目の証明書と3番目の鍵ペア（KP3）を導入し、それを使用してVerisign証明書に署名することができます。これを証明書チェーンと呼びます。チェーン内の各証明書は、次の証明書を検証するために使用されます。うまくいけば、この再帰的なアプローチは、ずっとカメ/証明書であることがすでにわかります。どこで止まるの？
無限の数の証明書を作成することはできないため、証明書チェーンは明らかに停止する必要があります どこかでする必要があり、それは自己署名されたチェーンに証明書を含めることによって行われます。
頭が爆発して脳の物質を拾っている間、少しの間休止します。自己署名？！
はい。証明書チェーンの最後（別名「ルート」）には、独自の鍵ペアを使用して署名する証明書があります。これにより、無限再帰の問題は解消されますが、認証の問題は修正されません。私が政治、理論物理学を3専攻し、尻蹴りを適用し、下部で自分の名前に署名することを示す偽のプリンストン卒業証書を作成できるのと同じように、誰でもその上に何かを記載した自己署名証明書を作成できます。
この問題に対する[ややエキサイティングな]解決策は、明示的に信頼する自己署名証明書のセットを選択することです。たとえば、「私は信頼しますこのVerisign自己署名証明書しています。」。
この明示的な信頼が整ったので、証明書チェーン全体を検証できます。チェーン内に証明書がいくつあっても、各署名をルートまで検証できます。ルートに到達したら、そのルート証明書が私が明示的に信頼しているものであるかどうかを確認できます。もしそうなら、私はチェーン全体を信頼することができます。
授与された信頼
TLSでの認証は、付与された信頼のシステムを使用します。自動車整備士を雇いたいのなら、私が見つけたランダムな整備士を信用できないかもしれません。しかし、おそらく私の友人は特定のメカニズムを保証しています。私は友達を信頼しているので、そのメカニズムを信頼できます。
コンピュータを購入するか、ブラウザをダウンロードすると、数百のルート証明書が付属しており、明示的に信頼しています。[4] これらの証明書を所有および運用する企業は、証明書に署名することにより、その信頼を他の組織に与えることができます。
これは完璧なシステムにはほど遠い。CAが誤って証明書を発行する場合があります。そのような場合、証明書を取り消す必要がある場合があります。発行された証明書は常に暗号的に正しいため、失効は注意が必要です。以前に有効だった証明書のうち、取り消されたものを見つけるには、帯域外プロトコルが必要です。実際には、これらのプロトコルの一部はあまり安全ではなく、多くのブラウザはいずれにしてもそれらをチェックしません。
CA全体が侵害される場合があります。たとえば、Verisignに侵入してルート署名鍵を盗んだ場合、任意のなりすましが可能です。世界に証明書を。これはVerisignの顧客に影響するだけではないことに注意してください。私の証明書がThawte（Verisignの競合相手）によって署名されている場合でも、それは問題ではありません。私の証明書は依然として、Verisignからの侵害された署名鍵を使用して偽造することができます。
これは理論的なものではありません。それは野生で起こりました。DigiNotarは有名にハッキングされ、その後破産しました。コモドもハッキングされましたが、どういうわけか彼らは今日に至るまでビジネスを続けています。
CAが直接侵害されていない場合でも、このシステムには他の脅威があります。たとえば、政府は法的強制を使用して、偽造された証明書への署名をCAに強制します。雇用主は、従業員のコンピュータに独自のCA証明書をインストールできます。これらのさまざまなケースで、「安全」であると予想されるトラフィックは、実際には、その証明書を管理する組織に完全に表示/変更可能です。
Convergence、TACK、DANEなど、いくつかの代替が提案されています。
文末脚注
[1] TLS証明書データはX.509標準に従ってフォーマットされます。X.509はASN.1（ "Abstract Syntax Notation＃1"）に基づいています。つまり、これはバイナリデータ形式ではありません。したがって、X.509はバイナリ形式にエンコードする必要があります。DERとPEMは、私が知っている2つの最も一般的なエンコーディングです。
[2]実際には、プロトコルは実際には対称暗号に切り替わりますが、それは質問には関係のない詳細です。
[3]おそらく、CAは実際に、証明書に署名する前に本人を確認します。彼らがそれをしなかった場合は、google.comの証明書を作成して、CAに署名するよう依頼するだけで済みます。その証明書があれば、google.comへの「安全な」接続を途中で仲介することができます。したがって、検証手順はCAの運用において非常に重要な要素です。残念ながら、この検証プロセスが世界中の何百ものCAでどれほど厳密であるかはあまり明確ではありません。
[4] Mozillaの信頼できるCAのリストをご覧ください。
