サーバーは、秘密鍵と公開鍵で構成される鍵ペアを作成します。もちろん、サーバーが秘密鍵を提供することはありませんが、誰でも公開鍵のコピーを入手できます。公開鍵は、証明書コンテナ形式(X.509)に埋め込まれています。このコンテナは、ラップされたキーに関連するメタ情報で構成されます。たとえば、サーバーのIPアドレスまたはドメイン名、そのサーバーの所有者、電子メールの連絡先アドレス、キーが作成されたとき、キーが有効である期間、目的、および他の多くの可能な値。
コンテナ全体は、信頼できる認証局(= CA)によって署名されています。CAには、秘密鍵と公開鍵のペアもあります。あなたは彼らにあなたの証明書を与え、彼らはコンテナ内の情報が正しいことを確認し(例えば、連絡先情報が正しいか、その証明書は本当にそのサーバーに属しているか)、最後に彼らの秘密鍵で署名します。CAの公開鍵をユーザーシステムにインストールする必要があります。最もよく知られているCA証明書は、お気に入りのOSまたはブラウザのデフォルトのインストールにすでに含まれています。
ユーザーがサーバーに接続すると、サーバーは秘密鍵を使用してランダムデータに署名し、署名されたデータを証明書(=公開鍵+メタ情報)と一緒にパックして、すべてをクライアントに送信します。クライアントはその情報で何ができますか?
まず、送信されたばかりの証明書内の公開鍵を使用して、署名されたデータを検証できます。公開鍵が署名を正しく検証できるように、秘密鍵の所有者だけがデータに正しく署名できるため、このデータに署名した人は誰でも、この人が秘密鍵を所有していることがわかります。公開鍵を受け取りました。
しかし、ハッカーがパケットを傍受して、署名されたデータを別の証明書を使用して自分で署名したデータに置き換え、証明書を自分の証明書に置き換えるのを防ぐにはどうすればよいでしょうか。答えは単に何もありません。
そのため、署名されたデータが検証された後(または検証される前)に、クライアントは受信した証明書に有効なCA署名があることを確認します。すでにインストールされている公開CAキーを使用して、受信した公開キーが既知の信頼できるCAによって署名されていることを確認します。署名されていない証明書は、デフォルトでは信頼されていません。ユーザーは、ブラウザでその証明書を明示的に信頼する必要があります。
最後に、証明書自体の情報をチェックします。IPアドレスまたはドメイン名は、クライアントが現在通信しているサーバーのIPアドレスまたはドメイン名と本当に一致していますか?そうでなければ、何かが怪しいです!
人々は疑問に思うかもしれません:ハッカーが自分のキーペアを作成し、ドメイン名またはIPアドレスを証明書に入れて、CAによって署名されるのを防ぐのはなぜですか?簡単な答え:彼がそうする場合、CAは彼の証明書に署名しません。CA署名を取得するには、自分が実際にこのIPアドレスまたはドメイン名の所有者であることを証明する必要があります。ハッカーは所有者ではないため、それを証明できず、署名を取得できません。
しかし、ハッカーが自分のドメインを登録し、そのための証明書を作成し、それをCAによって署名させた場合はどうなるでしょうか。これは機能します。彼はCAに署名します。結局、それは彼のドメインです。ただし、彼はあなたの接続をハッキングするためにそれを使用することはできません。彼がこの証明書を使用すると、ブラウザは署名された公開鍵がドメインexample.net用であることをすぐに確認しますが、現在、同じドメインではなくexample.comと通信しているため、何かが再び間違っています。