Tweet

SSL証明書のフレームワーク（仕組み）

SSLの大きな目的のひとつが、「接続しているサイトのドメイン（ホスト名）が正しいこ」との証明です。ここでは、ブラウザがどのように接続サイトを確認しているかというフレームワークを説明します。

ルート証明書と階層

ブラウザには、信用する第3者の証明書（ルート証明書）があらかじめインストールされています。例えばIEの場合、次のようにインストールされているリストを表示することができます（IEの設定→インターネットオプション→コンテンツ→証明書→信頼されたルート証明機関）：

そして、Webサイトの証明書は、これらのルート証明書と紐付けられた信頼関係を持っています（アドレスバーの鍵マークをクリックすると証明書の詳細が表示されます）。例えば、Crossco社のサイトでは、UserTrustという第3者認証機関（フレンド名UserTrust、前の図の一番上にあるもの）の認証を受けています。この証明書では、間に証明書(COMODO SSL CA)が1枚入っていますが、これは中間証明書と呼ばれ、第3者認証機関が発行している証明書の種類（ドメイン認証、企業認証、EV認証等）等を表しています：

ブラウザによる接続先ドメインの確認

ブラウザはSSLでサイトに接続する際に、以下の手順により接続先が正しいことを確認します：

1. WebサイトのSSL証明書を取得(SSLハンドシェイク)
2. そのSSL証明書が失効していないかの確認(詳細は後術)
3. そのSSL証明書に示されるルート証明書を持っているかを確認
4. そのルート証明書で、取得したWebサイトのSSL証明書の署名を確認

証明書の失効確認

SSL証明書は、生成ミスやクラッキング等の理由により失効（無効化）される場合があります。そのため、クライアントは、SSL証明書の失効確認を行う必要があり、方法としては、以下の3種類があります：

• CRL (Certificate Revocation List)
  • 証明書発行機関が失効証明書のリスト（証明書のシリアル番号と失効日を含む）をWebサーバで公開
• OCSP (Online Certificate Status Protocol)
  • 証明書発行機関が各証明書の有効性を確認するWeb APIを公開
• OCSP Stapling (ステープリング/ホッチキス）
  • Webサーバは、設定されたSSL証明書の失効確認をOCSPにより実施し、その結果をキャッシュします。そして、SSLハンドシェイク時に、SSLサーバ証明書と同時にOCSP情報をクライアントへ送信

クライアントの動作としては、以下になります：

• CRLとOCSP
  • SSLハンドシェイクとは別に、HTTPアクセスによりCRL取得もしくはOCSP確認を行います:
    • CRL:クライアントは、このリスト(CRL)をダウンロードし、対象SSL証明書のシリアル番号が含まれていないか確認します。
    • OCSP:クライアントは、証明書のシリアル番号を、OCSP API送信し、有効であることを確認します。
    • 補足：失効確認をどちらの方法で行うかは、ブラウザの実装に依存し、最近のブラウザでは、OCSPが使用されます。
  • 確認結果を、一定期間、キャッシュします。
  •  そして、失効確認ができない場合、次のような振る舞いをとります：
    • ブラウザ：最近のブラウザでは一般的に無視します。
    • アプリ：多くの場合エラーを表示します（作りこみに依存）。
• OCSP Stapling
  • 証明書の取得と同時に失効確認を実施します。
  • 以下のメリットがあります：
    • アクセス速度向上（CRL取得、OCSPリクエストを省略可能）
    • 安定性向上（証明書発行機関のWebサーバがダウンしていても、WebサーバにOCSPキャッシュがあれば、影響がありません）。

参考：WindowsにおけるCRLおよびOCSPキャッシュの操作

Tweet