SSL証明書をLet's Encryptに変更しました
いつも Feedeen をご利用いただき、ありがとうございます。運営者の伊藤です。
本日は、 Feedeen が利用するSSL証明書を RapidSSL から Let's Encrypt に変更したことをご報告します。シマンテック傘下のRapidSSL（以降、旧RapidSSL）が発行した証明書は今年10月頃に無効化される予定で、これまでFeedeenで使用してきた証明書も無効化対象に含まれているため、その対応も兼ねて変更を実施しました。
この変更によるユーザーの皆様への影響はありません。万が一エラーなどが発生する場合は、お問い合わせフォームよりご連絡いただければ幸いです。
以降では、SSL証明書（の発行元）を変更するに至った理由などについてご説明させていただきます。 Feedeen のご利用にあたって必須の情報ではありませんので、ご興味のある方のみお読みください。
発端は昨年3月にGoogleが公表した提案です。旧RapidSSLを含むシマンテック傘下のSSL証明書事業において不正な証明書の発行が繰り返されており、それがもたらすリスクからユーザーを保護するため、シマンテックの証明書を段階的に無効化していくというものでした。
その後、昨年の9月にGoogleが提案の実行を決定し、Mozilla（Firefoxの開発元）も追随することを発表しました。これにより、Feedeenが使用していた証明書が期限前に無効化されることが確実になりました。
以上のような経緯でなんらかの対処が必要になったわけですが、取り得る選択肢は大きく分けて2つありました。RapidSSLの証明書を再発行するか、他の事業者に乗り換えるかです。手間が少ないのは前者で、詳細は後述しますが現在のRapidSSLはシマンテックの手を離れており、証明書を再発行して差し替えるだけで無効化の対象からは外れます。
しかし、今後このようなトラブルを避けることができるならば、手間をかけてでも事業者を乗り換える価値があります。そこで注目したのが、今回移行先としたLet's Encryptです。Let's Encryptは完全に自動化されたプロセスで証明書を発行するため、人為的なミスや不正が入り込む余地がなく、おそらく今回のような問題は発生しないでしょう。さらにMozillaやGoogleなどのブラウザベンダーが協賛しており、なんらかの問題が発生した場合でも円滑に対処されることが期待できます。
その他、Feedeenの開発面でもいくつかメリットがあり、最終的にLet's Encryptへの移行を実施させていただきました。以上が今回の変更の経緯となります。
問題は、ドメイン所有者の許可を得ずに証明書を発行していたケースがあったことです。こちらのメーリングリストで顕著な例が報告されていますが、example.comやtest.comといったドメインの証明書が許可なく発行されていたようです。2015年にgoogle.comのテスト証明書を無断で発行したのもシマンテックでした。その他にも多くのルール違反があったようで、Mozillaが詳細を公開しています。
さらに、シマンテックがこれらの指摘に対して有効な対策を取らず、ブラウザベンダーへの情報提供も遅れがちだったことが問題を深刻にしました。前述したGoogleによる最初の提案でもシマンテックの消極的な姿勢が書き連ねてあり、相当に業を煮やしていたようです。
シマンテックの説明では、不正発行された証明書は社内のテスト目的であったり、パートナー企業によるものだったりしたようです。近年SSLの重要度が高まり厳格な運用が求められていますが、そうした環境の変化に社内の体制や意識が追いつかず、最終的にすべての証明書が無効化される事態を招いてしまった、というのが真相ではないでしょうか。
繰り返しになりますが、Feedeenのサイト上での暗号化についてはなんら問題は発生していません。その点については、なにとぞご安心ください。
シマンテックが抱えていた問題をDigiCertがどこまで解決できたのかは今後を見ないとわかりませんが、少なくとも現在のRapidSSL等が新しく発行する証明書はChrome, Firefoxを含む主要なブラウザに信頼されており、期限前に無効化されることはありません。
現在のRapidSSLはここまでご説明してきたシマンテック傘下の時代とは別組織であるということで、ご理解いただければ幸いです。
Let's Encryptは米国の公益法人 ISRG (Internet Security Research Group) が運営するSSL認証局で、暗号化通信をWeb全体に普及させることを目的に、無料で証明書の発行を行っています。費用の支払いやメールによるやり取りなどを省略することで、証明書発行プロセスの完全自動化を達成しているのが大きな特徴です。
無料ということで信頼性を心配されるかもしれませんが、暗号化の強度などは有料の証明書とまったく変わりません。すべての証明書の発行・失効の記録を公開するなど透明性が重視されており、ブラウザベンダーをはじめ多くの企業からの協賛も得ているなど、運用についてもじゅうぶんに信頼できるものとなっています。
Feedeenへの導入にあたっては、コストを気にせずに複数のドメインに対して暗号化を導入できるのも大きなメリットになります。これにより、将来的にサブドメインを活用した機能なども検討する余地が生まれました。前述のとおり信頼性も遜色なく、自動化によって運用負担を軽減できる点などもあわせて、採用の判断をさせていただきました。
Feedeenでは、ユーザーの皆様に安心してご利用いただくため、引き続き必要な措置を講じてまいります。今後とも Feedeen をなにとぞよろしくお願いいたします。
本日は、 Feedeen が利用するSSL証明書を RapidSSL から Let's Encrypt に変更したことをご報告します。シマンテック傘下のRapidSSL（以降、旧RapidSSL）が発行した証明書は今年10月頃に無効化される予定で、これまでFeedeenで使用してきた証明書も無効化対象に含まれているため、その対応も兼ねて変更を実施しました。
この変更によるユーザーの皆様への影響はありません。万が一エラーなどが発生する場合は、お問い合わせフォームよりご連絡いただければ幸いです。
以降では、SSL証明書（の発行元）を変更するに至った理由などについてご説明させていただきます。 Feedeen のご利用にあたって必須の情報ではありませんので、ご興味のある方のみお読みください。
変更に至った経緯
今回の変更に至った最大の理由は、Chrome, Firefoxなどの主要ブラウザにおいて旧RapidSSLの証明書を段階的に無効化する決定がなされたことです。発端は昨年3月にGoogleが公表した提案です。旧RapidSSLを含むシマンテック傘下のSSL証明書事業において不正な証明書の発行が繰り返されており、それがもたらすリスクからユーザーを保護するため、シマンテックの証明書を段階的に無効化していくというものでした。
その後、昨年の9月にGoogleが提案の実行を決定し、Mozilla（Firefoxの開発元）も追随することを発表しました。これにより、Feedeenが使用していた証明書が期限前に無効化されることが確実になりました。
以上のような経緯でなんらかの対処が必要になったわけですが、取り得る選択肢は大きく分けて2つありました。RapidSSLの証明書を再発行するか、他の事業者に乗り換えるかです。手間が少ないのは前者で、詳細は後述しますが現在のRapidSSLはシマンテックの手を離れており、証明書を再発行して差し替えるだけで無効化の対象からは外れます。
しかし、今後このようなトラブルを避けることができるならば、手間をかけてでも事業者を乗り換える価値があります。そこで注目したのが、今回移行先としたLet's Encryptです。Let's Encryptは完全に自動化されたプロセスで証明書を発行するため、人為的なミスや不正が入り込む余地がなく、おそらく今回のような問題は発生しないでしょう。さらにMozillaやGoogleなどのブラウザベンダーが協賛しており、なんらかの問題が発生した場合でも円滑に対処されることが期待できます。
その他、Feedeenの開発面でもいくつかメリットがあり、最終的にLet's Encryptへの移行を実施させていただきました。以上が今回の変更の経緯となります。
RapidSSL 証明書の問題点
具体的に旧RapidSSL（およびその他のシマンテック系ブランド）にどのような問題があったかですが、結論から言うと一般に配布された証明書自体に問題はありません。第三者による証明書の偽造が可能だったというような話ではないので、Feedeenを含む旧RapidSSLの証明書を使用していたサイトの通信内容が危険にさらされたわけではありません。問題は、ドメイン所有者の許可を得ずに証明書を発行していたケースがあったことです。こちらのメーリングリストで顕著な例が報告されていますが、example.comやtest.comといったドメインの証明書が許可なく発行されていたようです。2015年にgoogle.comのテスト証明書を無断で発行したのもシマンテックでした。その他にも多くのルール違反があったようで、Mozillaが詳細を公開しています。
さらに、シマンテックがこれらの指摘に対して有効な対策を取らず、ブラウザベンダーへの情報提供も遅れがちだったことが問題を深刻にしました。前述したGoogleによる最初の提案でもシマンテックの消極的な姿勢が書き連ねてあり、相当に業を煮やしていたようです。
シマンテックの説明では、不正発行された証明書は社内のテスト目的であったり、パートナー企業によるものだったりしたようです。近年SSLの重要度が高まり厳格な運用が求められていますが、そうした環境の変化に社内の体制や意識が追いつかず、最終的にすべての証明書が無効化される事態を招いてしまった、というのが真相ではないでしょうか。
繰り返しになりますが、Feedeenのサイト上での暗号化についてはなんら問題は発生していません。その点については、なにとぞご安心ください。
現在の RapidSSL について
ここまで旧RapidSSLおよびシマンテックのSSL証明書事業についての問題をご説明してきましたが、シマンテックはGoogleの決定に先立つ昨年8月にSSL証明書関連の事業をすべてDigiCertに売却しており、現在はSSL証明書の事業から撤退しています。シマンテックが抱えていた問題をDigiCertがどこまで解決できたのかは今後を見ないとわかりませんが、少なくとも現在のRapidSSL等が新しく発行する証明書はChrome, Firefoxを含む主要なブラウザに信頼されており、期限前に無効化されることはありません。
現在のRapidSSLはここまでご説明してきたシマンテック傘下の時代とは別組織であるということで、ご理解いただければ幸いです。
Let's Encrypt について
最後になりましたが、移行先であるLet's Encryptについても簡単にご紹介します。Let's Encryptは米国の公益法人 ISRG (Internet Security Research Group) が運営するSSL認証局で、暗号化通信をWeb全体に普及させることを目的に、無料で証明書の発行を行っています。費用の支払いやメールによるやり取りなどを省略することで、証明書発行プロセスの完全自動化を達成しているのが大きな特徴です。
無料ということで信頼性を心配されるかもしれませんが、暗号化の強度などは有料の証明書とまったく変わりません。すべての証明書の発行・失効の記録を公開するなど透明性が重視されており、ブラウザベンダーをはじめ多くの企業からの協賛も得ているなど、運用についてもじゅうぶんに信頼できるものとなっています。
Feedeenへの導入にあたっては、コストを気にせずに複数のドメインに対して暗号化を導入できるのも大きなメリットになります。これにより、将来的にサブドメインを活用した機能なども検討する余地が生まれました。前述のとおり信頼性も遜色なく、自動化によって運用負担を軽減できる点などもあわせて、採用の判断をさせていただきました。
Feedeenでは、ユーザーの皆様に安心してご利用いただくため、引き続き必要な措置を講じてまいります。今後とも Feedeen をなにとぞよろしくお願いいたします。
コメント
コメントを投稿