RapidSSL 安心の低価格サーバ証明書

• SSL通信をしようとする時、まず始めにクライアント（ブラウザ）がサーバへSSL接続の要求をします。
• するとWebサーバは認証局から発行された自分のサーバ証明書をクライアントに送ります。
• それを受取ったクライアントは、そのサーバ証明書に署名し発行した認証局のルート証明書について、自分が保持しているルート証明書群の中から探し出します。
• そしてルート証明書に含まれている認証局の公開鍵を使用して、サーバ証明書の署名を確認します。
• この時点でルート証明書を持っていなかったり署名が偽物だったりすると、クライアントは警告を発します。
• 更に有効期限やそのサーバ証明書が本当に今接続しているサーバのものであるか等を確認し、ひとつでも不備があれば同様に警告を表示します。
• クライアントはこのプロセスを完了して初めてWebサーバの信頼性を認め、その後の通信を暗号化する為に使用する共通鍵（正確には共通鍵を作成するための基礎データ）を作成します。
• この共通鍵はサーバ証明書に含まれる公開鍵で暗号化されサーバに送られます。
• 暗号化された共通鍵を受取ったサーバは、自分の秘密鍵で複合化してクライアントが作成した共通鍵を取り出します。
• そして、これより後の通信はこの共通鍵を使用してお互いに暗号・復号化し安全な通信を可能にします。

さて、何故このように面倒なプロセスを経て暗号化を行っているのでしょうか？

公開鍵暗号を最大限有効に活用するためには、通信主体双方において相手の公開鍵による暗号化を行う必要があります。公開鍵が誰でも取得できる構造上、秘密鍵での暗号化は事実上無意味であり、つまるところクライアント側の公開鍵が存在しない限り、サーバからの通信を暗号化する手段が無い訳です。

そこで、共通鍵による暗号化が利用される事になります。
クライアントはサーバとの暗号化通信に使用する共通鍵（実際には共通鍵の元データ）を作成した後、サーバの公開鍵によって暗号化を行いサーバ側に戻します。こうする事で共通鍵を利用できるのはクライアントと秘密鍵の持ち主であるサーバだけとなります。また、この共通鍵の元データはSSLのセッション単位で生成・破棄される為、外部から偽装される可能性もまずありません。
更に公開鍵暗号は暗号・復号化の演算量は共通鍵暗号の比ではありません。この演算量の差はサーバ負荷へ関係しますので、アクセス数に比例して増大する負荷は侮れません。
以上の事から、SSLは公開鍵・共通鍵暗号の長所を組み合わせた、非常に安全で且つ効率的な暗号化通信を可能にする技術となっています。