何度も短縮し過ぎ?!SSL証明書の有効期間がどんどん短くなる理由とは? | SSLサーバー証明書ならさくらインターネット

何度も短縮し過ぎ?!SSL証明書の有効期間がどんどん短くなる理由とは?

2020年9月からSSL証明書の有効期間は最大1年となったばかりですが、この先さらに短縮していく議論もされているようです。今回は「なぜ利便性を無視してSSL証明書の有効期間が何度も短縮されるのか?」という事情についてご紹介します。

何度も短縮し過ぎ?!SSL証明書の有効期間がどんどん短くなる理由とは?

有効期間短縮の歴史

SSLサーバー証明書(以下、SSL証明書)の有効期間は、当初は最長5年でしたが2015年に3年になり、2018年に2年、2020年には1年 + 1ヶ月となり、段階的に長期間のSSL証明書が廃止されてきました。

サーバーを管理している方はよくご存知だと思いますが、SSL証明書の更新作業には結構手間が掛かります。さくらのレンタルサーバなら管理画面からSSL証明書の登録が簡単にできますが、大規模サイトなどでは「他社に外注しているため作業費用が都度発生してしまう」といったケースもあると思います。そのような想像が容易にできるにも関わらず、ハイペースで有効期間が短縮されていく背景とは一体何なのでしょうか?

有効期間を決めるのは誰なのか?

SSL証明書の仕様に関しては、GoogleやMozillaなどのブラウザ開発ベンダーと、DigiCertやSectigoなどの認証局(CA:Certificate Authority)が参加する会議体「CA/Browserフォーラム」にて決定されます。以前にも度々ご紹介していますが、CA/Browserフォーラムでは議案に対して、ブラウザ側と認証局側で投票が行われて可否が決まります。

3~5年のSSL証明書が終了する際は、この合議のうえで終了が決められました。しかしながら、2年のSSL証明書の終了においては2019年8月に議案が否決されたにも関わらず、Apple社が「2020年9月よりSafariブラウザにおいて399日以上のSSL証明書を信頼しない」と2020年3月に突然発表し、ChromeとFirefoxがこれに続いたことによって、短縮せざるを得ない状況となり、1年への短縮が決まりました。

今後、セキュリティを重視するブラウザ側の意向が強く仕様に反映されていく可能性がありますが、今後の短縮についてもCA/Browserフォーラムで議論・決定されるようです。

短縮の経緯はインシデント抜きには語れない

有効期間が短縮される背景には、SSL証明書に関するインシデントが常に関係しています。例えば、特定期間に発行されたSSL証明書に問題が見つかった場合を考えてみましょう。2019年1月1日~2019年2月1日に発行されたSSL証明書に署名の不備があり失効処理を行うことになったと仮定します。

現在は2020年10月なので、上記の対象期間から1年以上経過しています。もし、この期間中に2年間有効なSSL証明書が発行されていたとしたら、それらは再発行しなければいけません。しかし、もし2年証明書がその時点で廃止されており、1年証明書しか存在しなかったとしたらどうでしょうか?その場合、既にそれらのSSL証明書は更新されており、当該期間に発行されたものは存在しないはずです。つまり、1年証明書しか存在しない場合は、再発行対応が不要になります。

これまでSSL証明書は、SHA-1証明書の脆弱性やルート認証局の鍵の危殆化、不正発行への対処といった様々な問題発覚を受けて、発行されたSSL証明書の「大量失効」や「大量入れ替え」を迫られる機会が何度もありました。有効期間が長いということはそれだけ長期間、過去に発行されたSSL証明書が有効であり、こうした問題発覚を受けた再発行対象のSSL証明書が増えてしまうことになります。

もし、SSL証明書の有効期間が90日であったなら、上記のような問題が発生したとしても、対処すべきSSL証明書の数はとても少なくなります。

BygoneSSLの脆弱性への対応

例えば、AさんがSSL証明書の取得後にドメイン契約が切れて、第三者のBさんがそのドメインを取得したとしましょう。その場合、以前のドメイン所有者であるAさんが、所有していないドメインのSSL証明書を持ったままの状態になります。理論的にはAさんが中間者攻撃により、BさんがSSL化したWebサイトのドメインを偽装することができます。これがBygoneSSLの脆弱性と呼ばれるセキュリティリスクです。

  • ※Bygoneとは「過去の」「過ぎ去った」という意味です。

1つのSSL証明書に1つのドメインが設定されており、そこにBygone SSLの脆弱性を利用したとしても、以前の所有者のSSL証明書を失効処理するだけで対処が可能です。しかし、マルチドメイン証明書のSAN(Subject Alternative Name)のドメインの1つだけにBygoneSSL問題があった場合は他のドメインにも影響が出てしまいます。以下のように悪意を持ってSSL証明書の失効を誘発させることができ、これらのサイトを全てサービス停止に陥れることができます。このBygone SSLの脆弱性の緩和を行うためにはSSL証明書の有効期限を短くすることが重要であるため、短縮が行われている大きな要因の1つになります。

BygoneSSLの脆弱性 説明図

BygoneSSLのの脆弱性をマルチドメイン証明書に悪用するケース 説明図

今後の流れ

399日以上の有効期間を持つSSL証明書は、2020年9月1日以降Apple Safari、Google Chrome、Mozilla Firefoxブラウザでは信頼されないことが決定されました。現在、CA/Browser フォーラムでは397日から9ヶ月→6ヶ月→90日と段階的に有効期間を短縮していく施策が検討されており、数年のうちに実施される可能性があります。こうなった場合、サーバー台数が多い大規模なシステムでは何十枚ものSSL証明書を60日程度のサイクルで入れ替える必要が出てくるため、更新の自動化が必須になると考えられます。

さくらのレンタルサーバでも無料SSL機能において60日間隔の自動更新を行う機能がありますが、似たような機能が有料のSSL証明書でも必要となってきます。大規模サービスや、エンドユーザーへ複数のドメインを提供するサービスの提供している場合は、SSL証明書の自動更新手段も検討しておく必要があります。

また、Web制作会社などでお客さんのサイトを運用代行している方は、定期的にSSL証明書を入れ替える作業を行える契約体系などを検討した方が良いかもしれません。

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

マルチドメイン証明書については、『1枚で複数サイトを常時SSL化!ワイルドカード証明書やマルチドメイン証明書とは?』で詳しく解説しています。また、Apple社がSSL証明書の有効期間を短縮した経緯などは、『2020年9月よりAppleがSSL証明書の有効期間を13か月に短縮!詳細や対策とは?』で紹介していますので、併せてご覧ください。

データ読み込み中...