10月13日に発生した証明書エラーについてのご報告

弊社のような認証局（CA）にとりまして失効に関する「通常業務」の一環として、ルート証明書（R2）から署名された証明書失効リスト（CRL）を10月7日に発行しました。そのリストにはシリアルナンバー「040000000001444ef0464e」のクロスルート証明書及び、シリアルナンバー「0400000000011256ad5fb2」の中間CA証明書を記載していました。シリアルナンバー「0400000000011256ad5fb2」の中間証明書は、寿命（EOL）を迎えた中間CAに対して発行されており、そのCAは以前SHA-1 EV SSLを発行していました。上記クロスルート証明書、中間CA証明書ともに、秘密鍵に関連するリスクもなく、通常の手順以外でCRLを発行する必要がなかったため、リーズンコードは双方で「運用停止」としていました。新しいCRLは弊社のCDNのフロントエンドを通して、そのまま利用可能な状態です。失効されたCAはどの証明書利用者にも使用されていなかったため、この時点ではお客様への影響は見られませんでした。前回のCRLは10月15日に有効期限が切れていました。

10月13日16:00、ルート証明書（R2）のレスポンスを行うOCSP（電子証明書の失効問い合わせのためのプロトコル）レスポンダのデータベースが、CRLに含まれていたシリアルナンバーを含んで更新しました。これが、今回お客様に障害が発生した原因です。

ルート証明書（R2）によって失効されたクロスルート証明書は、ルート証明書（R1）の証明書と同じ公開鍵、同じサブジェクトネームを持っており、さらに発行日付がより最近のものだったため、OCSPレスポンダが誤ってすべてのルート証明書（R1）の中間CA証明書を「無効」とみなしていました。

この状況はロールバックされ、ロードバランサ（負荷分散装置）やCDN上にキャッシュされていたOCSPのレスポンスはクリアされましたが、それ以前に取得した「無効」のレスポンスを維持したユーザが存在しました。

弊社は、お客様および証明書信頼者にこうしたレスポンスを提供するため、すべての製品について、第三者が安全性を認定した、負荷分散型OCSPレスポンダシステムを使っています。しかし、弊社のエコシステム、関係者、そしてお客様にとっては不運にも、クロスルート証明書の失効を行ったことが、OCSPレスポンダ内のデータベースにある公開鍵やサブジェクトネームによって失効された証明書を特定するというロジックによって、クイック認証SSLや企業認証SSL、アルファSSLといった他の中間証明書も「無効」となったと判断していました。ロジックではより最近の有効期間開始日を持つクロスルート証明書について、元のルート証明書（R1）に対する置き換えであるとみなしてしまうような実装がされていたため、今回の失効を、ルート証明書（R1）から発行された中間CA証明書すべてを「無効」とみなす指示として判断していました。OCSPレスポンダのデータベースの更新後に受け取ったルート証明書（R1）に関連するすべてのOCSPリクエストに対して、「無効」とするレスポンスが作成され、それがロードバランサ、CDN、最終的には弊社お客様のSSL/TLSが有効なウェブサーバに使われている証明書の失効状況を確認するのに使われる証明書利用者のプラットフォームにまで伝わっていました。すでに以前の有効なレスポンスをキャッシュしてあったクライアントもあるので、全クライアントが一度にレスポンスが必要になるということはありませんでした。以前にどの時点でそのWebサイトにアクセスしていたか等の状況によって、有効とするレスポンスを使っている環境と無効とするレスポンスを新たに取得し使用した環境が混在していたため、影響の出方に差が出ました。

最初の報告、また、内部のテストではいくつかのブラウザプラットフォームのロジックがクロスルート証明書の失効によって不慮にも影響を受けてしまい、エンドエンティティの証明書ステータスを決定してしまったと誤って想定しました。これは明らかに不正確な結論ですが、当時はルート証明書（R1）やルート証明書（R2）が多くのプラットフォームに存在していることを考えると、潜在的にはこれが原因のように見えていました。また、影響を受けたクライアントプラットフォームの種類の数がインシデントの初期の段階ではかなり少なかったことが、今回の障害はクライアントの問題なのではないかという誤った想定をしてしまいました。

弊社は世界中のユーザに素早いレスポンスを提供するため、階層性のキャッシュシステムを運用しています。これらキャッシュの階層がグローバルサインのデータセンター、世界中のCDNに存在しますし、さらにはユーザのブラウザもまた、OCSPレスポンスをキャッシュします。

CA業界基準に基づき、弊社のOCSPレスポンスは最長4日間ユーザのブラウザにキャッシュされるため、ユーザにより、異なる影響を受けました。ブラウザはCDNネットワークを介してレスポンスをロードしますが、リフレッシュされるまでの蓄積時間は1時間です。しかし、弊社のインフラストラクチャ内のロードバランサでは内部ネットワークの負荷を制御するため、キャッシュ時間はより長い8時間です。

OCSPレスポンスがこのように階層的にキャッシュされているため、グローバルサイン内部およびCDNではすでにキャッシュを削除いたしましたが、ユーザの環境で最大4日間までエラーが発生する可能性があります。

弊社は災害回復プロセスやリスク軽減戦略の重要性を真剣にとらえ、製品やサービスによってルート証明書を分離させることで、潜在的な問題に対応することを計画しています。今回はルート証明書が分かれていたため、弊社のEV SSL、文書署名用証明書、パブリックルート署名サービスのお客様は今回の障害の影響は受けていません。また、同じ中間CAに対して発行される、別のルート証明書によって署名されたバックアップ証明書の維持も試みています。今回はこれらのバックアップ証明書をクイック認証SSLや企業認証SSLのお客様に即座に提供いたしました。アルファSSLやクラウドSSLのお客様には、代替鍵を作るのに緊急キーセレモニーが開かれる間、数時間待っていただかなくてはなりませんでした。

弊社では今回のインシデントで影響を受けたお客様と共に継続して解決に努めると同時に、同様な問題が起こらないよう、業界団体を通し、今回の経験を他のCA（認証局）にも伝えようと考えています。グローバルサインが発行するOCSPレスポンスは最長で4日間有効なので、インシデントは10月17日中には完全に終息します。弊社は今回の経験から学び、リスク軽減戦略を強化する所存です。また、弊社技術部におきましては、証明書失効の必要性が本当にある場合、ユーザがより早く保護されるようOCSPの有効期間を縮める方法を模索していきます。

さらに、弊社はOCSPレスポンダのプロバイダと協力し、他のCAの証明書に影響を与えることなくOCSPレスポンダがクロスルート証明書を正しく失効できるようにしたいと考えています。現状最終的にパッチやこの目標に対しての具体的な予定は定まっていませんが、OCSPとCRLの連携の必要性は認識しています。

今回の障害情報と新しい中間CA証明書の取得はこちら

障害の経過

日時	時間	事象
10月07日		ルート証明書（R2）を含むすべてのルート証明書のCRLが更新される
10月13日	16:00	クロスルート証明書のOCSPステータスが更新される
10月13日	18:20	失効された証明書に関してサポートチームに障害報告書が提出される
10月13日	18:40	ChromeとSafariの問題の相関性が強まる
10月13日	19:07	R1チェーンの問題であると判断
10月13日	20:02	失効されたクロスルート証明書に起因するレスポンダ―の問題であることを確認
10月13日	20:20	OCSPデータベースからクロスルート証明書の削除
10月13日	21:20	キャッシュ削除開始
10月13日	22:30	CDNプロバイダと協力しキャッシュを強制的に削除
10月14日	02:14	キャッシュ削除完了
10月14日	04:24	ロードバランサの古いキャッシュを特定
10月14日	05:19	すべてのキャッシュ削除の確認がとれる