証明書のアレコレ(後編)

前編では、CRL(Certificated Revocation List)とOCSP(Online Certificated Status Protocol)の違いと、証明書の有効/失効をブラウザで確認する方法について解説しました。後編ではまず、現時点で利用できる3種類の証明書「Domain Validation(DV)」と「Organization Validation(OV)」「Extended Validation(EV)」について説明します。

DV(ドメイン認証)証明書

DV証明書は、最も安価で最も良く利用されている証明書です。証明機関は企業や組織に求める情報を独自に設定しており、シンプルな認証内容と簡潔な手続きが特徴です。

一例を挙げると、企業側はWebサーバー上の対象となるドメインに、ドメインの認証証明機関から送信されたファイルを設置します。これだけで証明機関は正しい所有者であるかを認証して、証明書を発行するのです。

この場合、ハッキングによって「実際には所有していないドメインについて証明書を取得する」といったことも可能になります。このトピックについては、別の機会で解説します。

OV(企業認証)証明書

OV証明書は、企業が実際にそのドメイン名を所有しているか、複数のチェックを行います。そのため、DV証明書と比較して信頼性は上がるものの、費用もかさみます。

証明書を要請した企業がドメインの所有者であることを判定するため、DV証明書と同様の発行プロセスを経た上で、電話による確認やバックグラウンドのチェックが行われるケースもあります。

ただし、この後に説明するEV証明書よりも厳格な確認プロセスが用意されておらず、企業・組織の確認手法は、それぞれの認証機関に委ねられています。

EV証明書(EV SSL証明書とも)

EV証明書は、費用が最も高く、証明機関によるバックグラウンド チェックや検証が細部に渡って行われます。これはEV証明書の発行に先立って企業や組織を確認する作業が、CA/Browser Forumの管理下にあるためです。

費用が高額になることから、EV証明書は「セキュリティに対して真剣に取り組んでいる」ということをアピールしたいECサイトなどの個人情報を取り扱うWebサイトに利用されるケースが多く見られます。

証明書が失効していたら……?

ここからは、インターネット トラフィックの9割以上を占めるGoogle ChromeとMozilla Firefox、Microsoft Internet Explorerという3つのブラウザについて、証明書失効への対応状況を説明していきます。

Google Chrome

近年シェア1位になったとも言われるGoogle Chrome。証明書の失効には、独特の対応を取っています。

CRLとOCSPは証明書が失効した際の業界標準となっていますが、Googleはこれを採用せず、「CRLSet」と呼ばれる方法で証明書のステータスを確認しています。

CRLSetは、Googleが独自に作成した失効証明書リストで、Googleが世界中の主要な認証機関のCRLを巡回・作成し、アップデートしています。つまり、「ブラウザが個別にOCSPサーバーやCRLをチェックしなくても、Googleがまとめてステータスを確認してあげるよ」という話です。

GoogleはCRLSetが「従来のCRLやOCSPよりも速く、より安全である」と主張しています。従来の方法よりも、ローカルに保存されたリストをチェックする方が速く、「OCSPサーバーやCRLを配布するポイントが利用できるかどうか」などの心配も必要ないためです。

しかし、Googleが「CRLSetに含める価値あり」と認めた証明書しか掲載されないため、その有用性には一定の疑問符がつきます。また、CRLSetのサイズは250KBに限られているため、Heartbleed問題などの理由で大量の証明書が突然失効した場合はリストから証明書が削除されてしまい、ユーザー側は対応できません。結果として、有効確認のためにオーバーヘッドが残ってしまうのです。

Mozilla Firefox

FirefoxではOCSPで失効した証明書をチェックし、CRLは使用しません。証明書のAuthority Information Access(AIA)にOCSPアドレスが含まれている場合、FirefoxはOCSPサーバにクエリを送り、証明書が失効していないか確認します。

OCSPサーバに接続できないか、OCSPアドレスが証明書のAIAフィールドにない場合、Firefoxは失効ステータスをチェックせずにエラー メッセージを表示します。

Microsoft Internet Explorer

lEは、主要ブラウザで最も徹底した失効チェックを行います。デフォルトの設定ではFirefoxと同様に、証明書のAIAフィールドにアドレスが含まれているとOCSPサーバーを確認します。

しかし、OCSPサーバに接続できないか、OCSPアドレスが記載されていない場合は、CRLを確認します。なお、大きなCRLファイルをいつもダウンロードしなくても済むよう、キャッシュ内に読み込まれているCRLを確認する場合があります。

いずれの方法でも確認できない場合に初めて、警告ページが表示されます。警告ページでは、証明書のステータスが不明でもアクセスを続けるか、ブラウザを閉じるかの選択肢が用意されています。

主要ブラウザそれぞれで、証明書失効への対応が若干異なるとおわかりいただけたことでしょう。Chromeでは失効した証明書をCRLSetに掲載していない可能性、FirefoxがOCSPサーバーに接続できない可能性、IEがキャッシュ内の期限切れCRLを確認する可能性が、それぞれ高いことを注意して覚えておいてください。

著者プロフィール

伊藤 悠紀夫(いとう ゆきお)
F5ネットワークスジャパン
セールスエンジニアリング本部
プリセールスコンサルタント

UNIXサーバ、ストレージ、シン・クライアントといったインフラエンジニアを経て、F5ネットワークスジャパンへ2012年に入社。
現在はセキュリティ・クラウドをキーワードにイベント講演やハンズオンラボを行い、F5ソリューションの啓蒙活動に奮闘中。
最近はOpenStackやIoTといったキーワードを中心に連携ソリューションを模索している。