重要なお知らせ
2016.10.17
10月13日に発生した障害についてのご報告
お客様各位
平素は、KingSSLをご愛顧いただき誠にありがとうございます。
弊社で使用するroot認証局（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日午後17時、ルート証明書（R2）のレスポンスを行うOCSP（電子証明書の失効問い合わせのためのプロトコル）レスポンダのデータベースが、CRLに含まれていたシリアルナンバーを含んで更新しました。これが、今回お客様に障害が発生した原因です。
ルート証明書（R2）によって失効されたクロスルート証明書は、ルート証明書（R1）の証明書と同じ公開鍵、同じサブジェクトネームを持っており、さらに発行日付がより最近のものだったため、OCSPレスポンダが誤ってすべてのルート証明書（R1）の中間CA証明書を「無効」とみなしていました。
この状況はロールバックされ、ロードバランサ（負荷分散装置）やCDN上にキャッシュされていたOCSPのレスポンスはクリアされましたが、それ以前に取得した「無効」のレスポンスを維持したユーザが存在しました。
root認証局は、お客様および証明書信頼者にこうしたレスポンスを提供するため、すべての製品について、第三者が安全性を認定した、負荷分散型OCSPレスポンダシステムを使っています。しかし、エコシステム、関係者、そしてお客様にとっては不運にも、クロスルート証明書の失効を行ったことが、OCSPレスポンダ内のデータベースにある公開鍵やサブジェクトネームによって失効された証明書を特定するというロジックによって、弊社の中間証明書も「無効」となったと判断していました。ロジックではより最近の有効期間開始日を持つクロスルート証明書について、元のルート証明書（R1）に対する置き換えであるとみなしてしまうような実装がされていたため、今回の停止を、ルート証明書（R1）から発行された中間CA証明書すべてを「無効」とみなす指示として判断していました。OCSPレスポンダのデータベースの更新後に受け取ったルート証明書（R1）に関連するすべてのOCSPリクエストに対して、「無効」とするレスポンスが作成され、それがロードバランサ、CDN、最終的には弊社お客様のSSL/TLSが有効なウェブサーバに使われている証明書の失効状況を確認するのに使われる証明書利用者のプラットフォームにまで伝わっていました。すでに以前の有効なレスポンスをキャッシュしてあったクライアントもあるので、全クライアントが一度にレスポンスが必要になるということはありませんでした。以前にどの時点でそのWebサイトにアクセスしていたか等の状況によって、有効とするレスポンスを使っている環境と無効とするレスポンスを新たに取得し使用した環境が混在していたため、影響の出方に差が出ました。
最初の報告、また、内部のテストではいくつかのブラウザプラットフォームのロジックがクロスルート証明書の停止によって不慮にも影響を受けてしまい、エンドエンティティの証明書ステータスを決定してしまったと誤って想定しました。これは明らかに不正確な結論ですが、当時はルート証明書（R1）やルート証明書（R2）が多くのプラットフォームに存在していることを考えると、潜在的にはこれが原因のように見えていました。また、影響を受けたクライアントプラットフォームの種類の数がインシデントの初期の段階ではかなり少なかったことが、今回の障害はクライアントの問題なのではないかという誤った想定をしてしまいました。
弊社利用のroot認証局であるグローバルサインは世界中のユーザに素早いレスポンスを提供するため、階層性のキャッシュシステムを運用しています。これらキャッシュの階層がグローバルサインのデータセンター、世界中のCDNに存在しますし、さらにはユーザのブラウザもまた、OCSPレスポンスをキャッシュします。
CA業界基準に基づき、OCSPレスポンスは最長4日間ユーザのブラウザにキャッシュされるため、ユーザにより、異なる影響を受けました。ブラウザはCDNネットワークを介してレスポンスをロードしますが、リフレッシュされるまでの蓄積時間は1時間です。しかし、グローバルサインのインフラストラクチャ内のロードバランサでは内部ネットワークの負荷を制御するため、キャッシュ時間はより長い8時間です。
OCSPレスポンスがこのように階層的にキャッシュされているため、グローバルサイン内部およびCDNではすでにキャッシュを削除いたしましたが、ユーザの環境で最大4日間までエラーが発生する可能性があります。
災害回復プロセスやリスク軽減戦略の重要性を真剣にとらえ、製品やサービスによってルート証明書を分離させることで、潜在的な問題に対応することを計画しています。KingSSLのお客様には、代替鍵を作るのに緊急キーセレモニーが開かれる間、数時間待っていただかなくてはなりませんでした。
今回のインシデントで影響を受けたお客様と共に継続して解決に努めると同時に、同様な問題が起こらないよう、業界団体を通し、今回の経験を他のCA（認証局）にも伝えようと考えています。グローバルサインが発行するOCSPレスポンスは最長で4日間有効なので、インシデントは10月18日中には完全に終息します。弊社は今回の経験から学び、リスク軽減戦略を強化する所存です。また、弊社技術部におきましては、証明書失効の必要性が本当にある場合、ユーザがより早く保護されるようOCSPの有効期間を縮める方法を模索していきます。
さらに、OCSPレスポンダのプロバイダと協力し、他のCAの証明書に影響を与えることなくOCSPレスポンダがクロスルート証明書を正しく失効できるようにしたいと考えています。現状最終的にパッチやこの目標に対しての具体的な予定は定まっていませんが、OCSPとCRLの連携の必要性は認識しています。
今回の障害情報と新しい中間CA証明書の取得はこちら
【障害の経過】
| 日時 | 時間 | 事象 |
|---|---|---|
| 10月7日 | ルート証明書（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日 | 午前2時14分 | キャッシュ削除完了 |
| 10月14日 | 午前4時24分 | ロードバランサの古いキャッシュを特定 |
| 10月14日 | 午前5時19分 | すべてのキャッシュ削除の確認がとれる |
ご利用のお客様には多大なるご迷惑をお掛けいたしまして、誠に申し訳ございません。
ご質問や不明な点などございましたら、お問い合わせフォームよりご連絡ください。
