インシデントの概要

私たちが認証局や『さくらのSSL』のような販売代理店で購入するSSLサーバー証明書（以下、SSL証明書）は、以下のように「中間CA証明書」というものを経由して「ルート証明書」と関連付けられています。

この例のように、ルート証明書である「example CA Root X1」を起点として、中間CA証明書である「Example CA intermediate G2」が設定されています。この中間CA証明書によって「ssl.sakura.ad.jp」は署名されているのです。

• ※中間CA証明書は1～2枚設定されているのが一般的です。

この中間CA証明書にセキュリティリスクが存在することが判明したため、認証局側で中間CA証明書の失効と秘密鍵の破壊が必要とされました。中間CA証明書が失効されると、その配下のSSL証明書も無効になってしまいます。これを回避するため、別の中間CA証明書から発行されたSSL証明書に入れ替える必要があります。

通常、SSL証明書に関するインシデントが発生した場合、24時間～7日以内に対象証明書を失効する必要があります。しかしながら、今回は中間CA証明書の失効であり、その中間CA証明書によって発行された電子証明書が全て利用できなくなるため、大量の電子証明書※が影響を受ける事態となりました。

• ※SSL証明書以外にも電子メールで利用する「S/MIME証明書」、アプリケーションで利用する「コードサイニング証明書」なども対象になっています。

現在、各認証局で数ヶ月～半年程度のタイムスケジュールで発行済の証明書を入れ替えていく予定が組まれています。全世界で14の認証局、実に数百万枚の電子証明書が影響を受けています。

「なぜここまで影響が大きいのか？」と言うと、2019年に別の事象が発生し、その事象を回避するために中間CA証明書に行われた設定が今回のセキュリティインシデントの原因になってしまったという経緯があります。

セキュリティリスクについて

本件のセキュリティリスクを簡単に説明すると、「WebサイトへのSSL接続」や「コードサイニング証明書の検証」のみに利用しているはずの中間CA証明書が、実は「OCSPレスポンスの署名」にも利用できるように設定されていたこと起因します。

OCSP（Online Certificate Status Protocol）とは、接続に利用しようとしているSSL証明書が「失効していないか？」を確認できるプロトコルであり、Webサイトにアクセスする前に、ブラウザ側が「このSSL証明書はまだ有効ですか？」と認証局の運用するOCSPサーバーに確認して、OCSPサーバー側が「OK！有効です！」もしくは「NO！失効してます！」と教えてくれる仕組みです。

• ※失効されていた場合は、Webサイトにアクセスすることができません。

これにより、失効したSSL証明書を使っているサイトにアクセスしてしまうリスクが低減されます。SSL証明書はWebサイトを公開しているサーバー内に保管されており、有効期間は記載されていますが、実際の有効/失効の状態はわかりません。有効期間内に失効される場合もあるため、こうしたオンラインでSSL証明書の状態を管理できる仕組みが必要になります。

SSL証明書の詳細情報には上記のようにOCSPサーバーのURLが記録されており、ブラウザ側がこのURLにアクセスしてSSL証明書のステータスを確認しています。

もちろん、このOCSP応答が悪意のある第三者に偽造されて、失効した証明書を「失効してないよ」と偽の応答をされることを防ぐため、電子署名する必要があります。今回のセキュリティリスクとは、このOCSP応答の署名を、”本来OCSP応答の署名に利用しない”はずの中間CA証明書の秘密鍵で署名ができてしまうため、中間認証局同士がお互いの中間CA証明書の有効性を確認するOSCPレスポンスを偽装できるというものでした。

中間認証局はそれぞれが別の企業の場合もあります。ルート認証局が共通で、中間認証局同士がお互いのOCSP応答を偽装できるとしたらリスクは高いものになります。また、悪意を持った中間認証局がルート認証局のビジネスを妨害する目的で不正なOCSPレスポンスをしてインシデントを起こす、といったことも可能になります。

実際にリスクはあるのか？

『さくらのSSL』で販売しているSSL証明書のうち、過去の一部期間にJPRSが発行したSSL証明書が今回のインシデント対象です。JPRSが中間認証局、セコムトラストシステムズがルート認証局となるため、セコムトラストシステムズが発行している”別の中間認証局”の中間CA証明書の状態をJPRSが偽装できることになります。

しかしながら、JPRSではセコムトラストシステムズの発行した中間CA証明書の秘密鍵を保持していないため、偽のOCSP応答を作っても署名することができません。さらにOCSPサーバーはセコムトラストシステムズが管理しているため、秘密鍵を解読して応答を偽造できたとしても、ネットワークへ侵入したりドメインを偽装したりする必要があります。そのたため、現実的なリスクは非常に限定的と言えます。

また、2020年7月29日に中間CA証明書の切り替えが行われ、現在販売されているSSL証明書は問題の無く利用することができますのでご安心ください。

• ※詳しくはJPRSのお知らせをご覧ください。

このようにインターネットのセキュリティにおいて、過去の時点では安全と思われることでも後からリスクが顕在化し、対処しなければいけない事象が発生してしまうのはよくあることです。こういった影響を低減する目的でLet’s EncryptはSSL証明書の有効期間が90日に設定されています。”有効期間が短い”ということは、それだけ途中で失効する対象が減るということでもあり、未知のセキュリティリスクに対しては効果的です。

ただし、”有効期間が短い”と更新作業を行う頻度が上がり利便性が低下してしまうため、現在は最大1年（397日）が一般的なSSL証明書の有効期限になっています。

SSL証明書利用者の対処方法は？

各認証局からお知らせが出ているので、まずは利用しているSSL証明書の認証局や販売代理店のサイトを見てみましょう。影響がある場合、再発行等の対処方法が記載されていると思いますので、ガイダンスにしたがって手続きを進めましょう。

『さくらのSSL』での対応はどのように進むのか？

以前、旧シマンテック（現デジサート）社のSSL証明書が主要ブラウザで無効化されたことがあり、多くのお客様に”再発行のお願い”をご案内しましたが、今回も同様の対応が必要となります。

前回の経験を活かしてお客様へ再発行のご案内を進めていきます。再発行対象のSSL証明書につきましては、お知らせに記載しておりますのでご確認ください。現時点で対応期限が確定していませんが、2021年初頭と予想されます。

• ※対象のお客様にはメールにてご連絡いたしますので、今しばらくお待ちください。

こちらの記事もあわせておすすめ！

セキュリティと利便性のバランスについては、超高性能な量子コンピューターとSSL/TLSの対応を紹介した『あと数年で量子コンピューターにSSL通信が解読される？SSL/TLSの未来を担うPQCとは？』をご覧ください。OCSP等のSSL証明書の失効情報の管理等について詳しく解説した『SSL証明書の失効・無効化とは？』も併せてご覧ください。