3月9日から17日までの間にGoogle Chromeを使ってTake Controlサイトにアクセスした方は、下のスクリーンショットのように、「接続はプライベートではありません」という恐ろしい警告を目にされたかもしれません。この警告は実際の状況よりもはるかに過激でしたが、背景を知らずにサイトの利用をためらわれた方もいらっしゃるかもしれません。この件についてお詫び申し上げますとともに、発生した事象と今後の対応についてご説明いたします。
証明書の背景— まず、安全なWeb接続の暗号化基盤は、「デジタル証明書」が不可欠な要素となるエコシステムに依存しています。httpsで始まるWeb URLを読み込み、ページがエラーなく読み込まれ、ブラウザのアドレスバーのURLの横に鍵アイコンが表示されれば、接続が安全であると判断できます。（以下のスクリーンショットは、Safari、Chrome、Firefoxでの表示例です。）安全な接続は、悪意のある人物によるトラフィックの盗聴を防ぐため、クレジットカード情報などの機密情報を安全に送信できます。
システム全体は、検証によって裏付けられた信頼に基づいています。（興味深いことに、「信頼せよ、されど検証せよ」という格言は、
ロナルド・レーガン大統領が頻繁に使っていたロシアの諺を翻訳したものです。）最上位には大手ブラウザメーカーがいます。Apple、Google、Microsoft、Mozillaはいずれも、サードパーティの検証機関が自社のブラウザに組み入れられ、信頼されるためには、厳格な要件を満たさなければなりません。
これらの第三者検証機関は、証明書の有効性について独立した権限を与えるため、「証明機関（CA）」と呼ばれます。最上位のCA、つまりルートCAは、ブラウザメーカーが「ルート証明書」をブラウザにバンドルするための厳格な規則を満たす必要があります。この基準を満たしているのは世界中でわずか数百の組織であり、ブラウザメーカーは監査を義務付け、問題があれば報告を継続的に評価しています。
ルートCAは、実質的には副署された証明書を発行します。TidBITSのような企業がセキュアなWebサーバーを構築したい場合、テキスト部分と暗号化部分を含むリクエストを作成し、CAは、そのリクエストがセキュア化したいドメインの正当な当事者であるかどうかを検証します。検証に合格すると、CAはルート証明書を使用して暗号的に署名された証明書を発行します。
委任されたCA、つまり中間CAと連携することもできます。ルートCAはルート証明書から派生した中間証明書を作成し、DNSやWebホスティング会社、企業向けハードウェアを販売する企業など、他の組織がルートCAと同じ基準を満たす有効な証明書を作成できるようにします。
その結果、信頼の連鎖が形成されます。一方の端には CA のルート証明書があり、その中間には多くの場合、再販業者からの中間証明書、そしてもう一方の端には個別に発行された証明書が存在します。ブラウザ（およびオペレーティングシステム）はルート証明書を埋め込むことで、ユーザーが特定の Web サイトへの接続が安全であることを確認できます。つまり、証明書を販売した CA が、ユーザーが名乗るとおりの身元であることを保証し、最上位の CA が発行元の CA を保証します。その結果、ユーザーはブラウザメーカーが信頼できるルート証明書のみをサポートすると信頼します。（ブラウザは「帯域外」の信頼要素を提供します。つまり、CA ルート証明書の有効性を確認するために、安全でない可能性のあるインターネット接続を使用する必要がないということです。
この信頼は既にブラウザに組み込まれているからです。）
この証明書システムは公開鍵暗号に基づいており、公開証明書はチェーン内の各エンティティが保有する秘密鍵に関連付けられています。その結果、証明書は単なる本人確認にとどまらず、Webブラウザとサーバーが傍受されることなくセッション暗号化鍵を交換し、接続を通過するすべてのトラフィックを暗号化することを可能にします。
従来、Webサーバーの証明書を取得するプロセスは高額で面倒なものでした。それほど遠くない昔には、年間300ドルから500ドルもかかっていました。2010年に初めてこの方法を採用して以来、私たちはStartComというCAを利用しており、同社は大幅に安価な証明書を提供していました。StartComから証明書を取得するには、複数の認証手順と、個人および法人の身元を確認する法的文書のスキャンが必要で、手続きは必ず詳細を確認するための電話で終了していました。
StartComから証明書を入手したら、インストールする必要がありました。証明書とStartComの中間証明書をサーバーにコピーし、ApacheとSendmailの設定ファイルを変更して証明書を参照するようにする必要がありました。証明書の有効期間は2年間だったので、これまでに3回もこの作業を繰り返す必要があり、正直言って面倒でした。手順を再現できるように大量のメモを取らなければならず、Unix管理の知識はそこそこしかないので、何か大きな間違いをしてしまうのではないかと常に不安でした。それでもなんとかやり遂げ、最後の更新は2016年8月でした。（長年オンデマンドシステム管理者を務めているGlenn Fleishmanも、数年前にこの面倒な作業にうんざりするまでStartComを使っていました。）
StartCom問題— 問題の発端はここにあります。StartComは2015年末、中国の認証局WoSignにひっそりと買収されたようです。詳細は未だ不明ですが、買収の詳細が公表されていないことと、WoSign側の様々な不正行為により、Apple、Google、Mozillaは昨年秋、WebブラウザでStartComが発行する新しい
証明書
を信頼しないことを発表しました。
2017年3月9日、GoogleがChromeバージョン57をリリースし、StartComの古い証明書（私たちの証明書も含む）の信頼を停止するまで、この問題は発生しませんでした。突然、Chrome 57ユーザーは、私たちのサイトが読み込まれる前に「接続はプライベートではありません」という警告が表示されるようになりました。「詳細設定」リンクと「続行」リンクをクリックしてこの警告を無視すると、Take Controlサイトのすべてのページに「保護されていません」というラベルが付けられました。私の驚きは想像に難くありません！SafariもFirefoxも、StartComの古い証明書を依然として信頼しているため、警告は表示されませんでした。幸いなことに、Chromeは時間の経過とともに自動的に更新され、新しいバージョンが読み込まれる前に再起動する必要があるため、この問題に気付いた人は比較的少数でした。
(Chrome の挙動について教えてくれた Twitter ユーザーの @shepgo に感謝します。当時は Chrome がバージョン 57 にまだ更新されていなかったため、私も彼も何が起こっているのか把握できませんでしたが、翌日顧客からの苦情を受けたときには、かなり早くすべてを把握することができました。)
これらの警告にもかかわらず、私たちのサイトのセキュリティや、サイトとの間のトラフィックの暗号化には実際には何も変わっていなかった。(私は TidBITS セキュリティ編集者の Rich Mogull にこのことを確認させた。) しかし、Google はもはや自社の評判をユーザーのプライバシー保証に利用したくなかった。StartCom が評判の良い行動をとると信じなくなったからだ。より正確なメッセージは「Google はあなたの接続がプライベートであることを確認できません」とでも言うべきだったかもしれないが、それではユーザーの怒りをかき立てることはできない。本質的に、Google は Apple や Mozilla と共に、StartCom と WoSign の悪い行動に対して、彼らの顧客を確実に流出させることで罰を与えていたのだ。そしてそれはうまくいった。
（StartCom は、この問題についてすべての証明書保有者に警告し、組織を再編して信頼を回復するまで他の有効な CA への移行を提案することで、積極的かつ積極的にこの問題に対処することができました。StartCom はこうした対策を一切講じなかったため、この状況は、私がもっと落ち着いて対処できたはずの技術的なタスクではなく、危機的な状況になってしまったのです。）
皆さん、Let's Encrypt をご利用ください！ — 何が起こったのかが分かった後、私たちはLet's Encrypt を使うようになりました。これは非営利の認証局で、無料の証明書を提供しています。Let's Encrypt の証明書は90日間しか有効ではなく、その後は更新が必要ですが、これは簡単に自動化できます（そして自動化すべきです）。
幸いなことに、Let's Encrypt は、ACME (Automatic Certificate Management Environment) をサポートするクライアントソフトウェアのおかげで、StartCom で2年ごとに苦労して行っていたプロセスを劇的に簡素化してくれました。Web サーバーで実行できる ACME クライアントは数多くありますが、Let's Encrypt は EFF の Certbot を推奨しています。Certbot は比較的簡単にインストールでき、様々なオペレーティングシステムや Web サーバーで実行できます。Certbot は、ユーザーが複雑な認証手順を踏む代わりに、ユーザーが管理している
と主張するドメイン名を使用してサーバーへの接続を検証することで、Web サーバーがドメインに対して信頼できるサーバーであることを検証します。これは信頼チェーンを構築するには十分なようです。
Unixアプリケーションのインストールに慣れている方なら、Certbotも問題なく使えるでしょう。サーバーをクラッシュさせてしまうようなミスをしてしまうのではないかといつも心配していたので、Glennに手伝ってもらいました。しかし、最終的には驚くほど簡単でした。wgetを使ってCertbotのコピーを取得し、権限をいくつか変更して実行すると、自動的にインストールされました。証明書の取得とインストールは、Apache用にすべてを設定するように指示するフラグを付けてCertbotを再度実行するだけで済みました。設定ファイルを読み込み、サポートするドメインに関するいくつかの質問を行い、証明書を取得してインストールし、Apacheの.confファイルを更新しました。
初回の動作確認をしたいため、Certbot による証明書の自動更新は設定していませんでしたが、最初の手動更新後に、Certbot による証明書自動更新をスケジュールする cron ジョブを作成して、自動更新を設定する予定です。(Certbot には自動更新用の「ドライラン」オプションが用意されており、問題が発生するかどうかをテストできます。)
その間ずっと、Qualys SSL Server Testを実行していましたが、Let's Encryptに切り替えた後もB評価しか得られませんでした。さらに調査を進めたところ、Apacheの.confファイルでSSL暗号の選択が最適に設定されておらず、サーバーが他の暗号よりも安全性の低い暗号を使用している可能性があることが判明しました。これらの推奨事項に従ってSSL暗号の行を修正したところ、サイトは無条件のA評価を獲得するようになりました。また、.confファイルからStartCom
証明書を参照している不要な行をいくつか削除する必要がありました。
まだやっていない主な作業は、Sendmailの設定にあるStartCom証明書をLet's Encrypt証明書に置き換えることです。やり方はわかっているつもりですが、Certbotが証明書を更新したことをSendmailがどのように認識するかについては、もう少し調べる必要があります。
何が起こったのか、そして問題を解決するにはどうすればよいのかを理解するのに何時間も費やしましたが、Let's Encrypt を使用する方が StartCom を使用するよりも安価で簡単であり、私が行った追加の構成変更によってサイトのセキュリティがさらに強化されたため、最終的にはその価値が倍増しました。
最後に一つ。今回の件ではStartComとWoSignが悪者であり、被害を受けたのは彼らの顧客です。しかし、認証局（CA）の不審な行動は前代未聞ではありません。Googleは、世界最大の認証局であるSymantecに対し、様々な疑わしい行為を理由に処罰を開始する予定です。SymantecまたはSymantec傘下の再販業者から証明書を取得している場合は、代替手段を検討することをお勧めします。
したがって、証明書プロバイダーに満足していない場合、特に StartCom から証明書を購入した場合は、Let's Encrypt を試してみることをお勧めします。