要約

  • Let’s Encryptは2015年11月9日、証明書を最長90日とし、60日ごとの更新を勧めた。鍵の漏えいや誤発行後の有効期間を縮め、更新の自動化を促すためだった。
  • 3日後の公開ベータ告知では、限定ベータで11,000件を超える証明書を発行したと報告する一方、幅広いプラットフォームで使いやすいクライアント体験にはまだ作業が必要だとしていた。

分析

証明書の期限は、ファイルの中では静かな日付だ。Webサイトがその証明書を使い続ければ、運用上の締切になる。RFC 5280は notBefore から notAfter までを有効期間として定義する。後者の日付が過ぎた証明書は、その日付のままでは使い続けられない。新しい証明書を発行し、サービスに反映する必要がある。

2015年11月9日、Internet Security Research Groupの事務局長Josh Aasは、Let’s Encryptが90日を上限にした理由を説明した。同じ期間に二つの役割を持たせている。秘密鍵が盗まれたり、証明書が誤って発行されたりした場合、その証明書が有効である時間を短くする。さらに更新を頻繁にして、自動化をHTTPSの使いやすさに欠かせないものにする。

60日ごとの更新という推奨が、この設計を具体的にする。期限の最終日まで待つのではない。90日の上限までおよそ1か月あり、更新に失敗すれば人が気付いて手を入れられる。Aasは当時、サービスはまだ新しく、自動化に慣れていない利用者も多いと説明した。ソフトウェアへ仕事を移しながら、手作業で立て直す時間も残す。その妥協が90日だった。

この方針を公開した時点の準備状況は、11月12日の告知に見える。限定ベータは9月12日に始まり、同日付の発表では11,000件超の証明書を発行していた。公開ベータは12月3日の予定だった。告知は自動化を戦略の柱と呼びつつ、幅広い環境でクライアントを滑らかに使えるよう、まだ改善が必要とも述べる。証明書の発行は進んでいたが、どの環境でも安心して更新できる仕組みは完成途上だった。

Let’s Encryptの説明は明快だ。Web全体の管理者に、証明書を毎回手作業で更新させることはできない。発行と更新が自動なら、寿命を短くしてもサイト担当者の手間は増えない。セキュリティ上の時間制限と運用上の自動化は、別々の施策ではなかった。短い時計を採用するからこそ、クライアントが期限に合わせて動く必要があった。

手作業の更新は残されたが、通常の運用を支えるのはソフトウェアになる。更新クライアント、スケジュール、各プラットフォームとの相性、新しい証明書の配置がそろって初めて期限を守れる。60日という数字は暦の指示であり、自動化はそれを多数のサイトで繰り返すための方法だった。

11月12日の発行数は、ベータ中に発行した証明書の総数だ。更新に成功した数や失敗した数は分からない。日付と環境をそろえた更新成功率があれば、手動対応の余裕が十分だったかを測れる。二つの告知にはその記録がない。

出典