Let’s Encrypt、信頼チェーンを短縮
(letsencrypt.org)- Let’s Encryptは、2024年9月30日に失効する**クロス署名（cross-sign）**を延長せず、ISRG Root X1で終わる短い証明書チェーンへ移行する
- 初期リリース時には独自ルートが十分に信頼されていなかったため、IdenTrustのDST Root CA X3に依存していたが、現在はISRG Root X1の信頼範囲が大きく広がっている
- 2021年に旧型Android互換性のため追加したルートのクロス署名は一時的な措置であり、そのおかげで古いAndroid端末はLet’s Encrypt証明書をさらに3年間信頼できた
- この3年間でISRG Root X1を信頼するAndroid端末の比率は**66%から93.9%**へ上昇し、クロス署名を除去するとTLSハンドシェイクにおける証明書バイト数も40%以上削減される
- Android 7.0以下の利用者にはFirefox Mobileの利用が推奨され、サイト運営者とACMEクライアント作成者は2024年の移行スケジュールに合わせてチェーン処理を点検する必要がある
クロス署名終了の背景
- Let’s Encryptは、リリース初期に証明書が広く信頼されるよう、IdenTrustのDST Root CA X3で中間証明書をクロス署名していた
- 独自ルートであるISRG Root X1がまだ広く信頼されていなくても、その中間証明書が発行した証明書を信頼させる方式だった
- 時間の経過とともに、ISRG Root X1はそれ自体で広く信頼されるようになった
- 2021年末には、クロス署名された中間証明書とDST Root CA X3自体が失効する予定だった
- 当時、最新ブラウザはLet’s Encryptルートを信頼していたが、Android端末の3分の1以上は古いOSバージョンを使用していた
- これらの端末は、Let’s Encrypt証明書を使うWebサイトを突然信頼できなくなる可能性があった
- Let’s Encryptは2021年に、中間証明書ではなくルートに直接クロス署名を適用し、DST Root CA X3より長く持続する一時的措置を用意した
- この措置により、旧型Android端末はLet’s Encrypt証明書をさらに3年間信頼できた
- このクロス署名は2024年9月30日に失効する
短いチェーンへ切り替わる理由
- Let’s Encryptは、互換性延長のための新たなクロス署名をもう取得しない
- この3年間でISRG Root X1を信頼するAndroid端末の比率は**66%から93.9%**へ上昇した
- Android 14では、OS全体を更新しなくても信頼ストアを更新できるため、この比率はさらに増える可能性がある
- クロス署名の除去により、TLSハンドシェイクで送信される証明書バイト数は40%以上削減される
- 運用コストも大幅に下がるため、Let’s Encryptはプライバシー保護とセキュリティ改善に資金を集中できる
2024年の移行スケジュール
- 2024年2月8日（木）:
/acme/certificateAPIエンドポイントへのリクエストで、デフォルトのクロス署名提供を停止- ほとんどの利用者は、ACMEクライアントがISRG Root X1で終わるチェーンを設定し、WebサーバーがTLSハンドシェイクでより短いチェーンを提供するようになった
- 間もなく失効するクロス署名で終わる、より長いチェーンは代替チェーンとして引き続きリクエストできた
- 2024年6月6日（木）: より長いクロス署名チェーンの提供を完全に停止
- クロス署名失効の90日少し前にあたり、これは証明書1件分の有効期間に相当する
- 利用者がクロス署名チェーンから移行できるよう、少なくとも1回の完全な発行サイクルを確保するための日程である
- 2024年9月30日（月）: クロス署名証明書が失効
- 大半の利用者にとっては特別な出来事ではないはずで、クライアント障害はその前の6か月間にすでに発生しているべきだった
利用者と運営者が確認すべき点
- Android 7.0以下の利用者は、Let’s Encrypt証明書で保護されたWebサイトに引き続きアクセスするために対応が必要となる可能性がある
- Let’s Encryptは、Android OSの信頼ストアではなく独自の信頼ストアを使うFirefox Mobileのインストールと利用を推奨している
- サイト運営者は、2024年第2四半期と第3四半期にWebサイト利用統計とアクティブなuser-agent文字列を確認すべきである
- Androidからの訪問が突然減少した場合、Android 7.0以下の利用者が相当数いる可能性がある
- その利用者にFirefox Mobileの利用案内を提供することが推奨される
- ACMEクライアント作成者は、証明書の発行・更新のたびに、APIが提供する証明書チェーンを正しくダウンロードしてインストールしなければならない
- 過去の障害例には、チェーンをまったくダウンロードせず、end-entity証明書だけを提供するケースがあった
- チェーンをダウンロードせず、ハードコードされたチェーンを提供するケースもあった
- 初回発行時にだけチェーンをダウンロードし、更新時には再ダウンロードしないケースもあった
- 移行に関する質問は、Let’s Encryptのcommunity forumで行える
1件のコメント
Hacker Newsのコメント
Let's Encryptが2019年夏にこの移行を行うと発表したものの、コミュニティのフィードバックを受けて延期したことを覚えている
当時、再考を強く求めていた一人だったが、この件で期待をはるかに超えて4年半も遅らせるとは思わなかった。TLSエコシステムをこれほど慎重に扱ってくれてありがたい
Android端末の95%をカバーするには、2016年8月のAndroid 7.0 Nougatまでサポートする必要がある
https://en.wikipedia.org/wiki/Android_Nougat
iOS端末の95%をカバーするには2020年9月のiOS 14で十分で、90%だけを見てもAndroidは8.1（2017年）、iOSは15（2021年）だ
https://iosref.com/ios-usage
https://en.wikipedia.org/wiki/IOS_14
Appleのほうが、人々をより新しいOSへ移行させるよう説得したり許容したりするのがうまいように見える
端末がアップデートされない理由は、メーカーがアップデート提供をやめるからだ
curlのCAバンドルのページによると、Mozillaバンドルは展開後で約200KBで、自分のAndroidではChromeアプリが25MBなので、アプリサイズが1%増えるだけで最新状態を保てるのは妥当に思える
もちろん他のアプリも最新のCAを求めるかもしれないが、すべてのCAが必要なのか、それとも実際に使う可能性のあるCAだけでよいのかは検討の余地がある
低価格メーカーのどこかが顧客向けアップデートをしないと言い出したとしても、Googleにできることは多くない。Android認証の取得や維持の条件として一定期間アップデート提供を求めることはできるが、いずれそのメーカーがAndroid自体を捨てる可能性もある
そのうえQualcommも、古いチップセット向けには時間がたつと更新済みのカーネルとブロブを提供しなくなる。Googleは以前の情けない18か月より長くするよう交渉したが、Qualcommにそれ以上協力する義務はない。Googleが自社製チップセットを作り始めてからは、この問題への関心もやや薄れた
良いという意味ではないが、Androidのモデル上おおむねこうならざるを得ず、Appleのモデルはこうした部分をより強く制御できるようにしている
古いクロス署名を動作し続けさせたやり方はかなり興味深かった
新しいクロス署名はDST Root CA X3の失効後まで続くという点でやや特異だった。Androidでは信頼アンカーとして使われる証明書の有効期限を意図的に強制しないため、可能になった解決策だった
実際、信頼アンカーはほかの証明書とはかなり異なる動作をするので、驚くかもしれない
[1] https://letsencrypt.org/2020/12/21/extending-android-compati...
[2] https://alexsci.com/blog/name-non-constraint/
覚えている限り、大きな問題の一つは古いOpenSSLがルートアンカーの失効をチェックしていたことだった。それだけではなく、当時勤めていた会社ではUbuntuがこの状況に対処するため何らかのパッチを当てる必要があり、失効の数日前になってようやくパッチが出たため、一部システムで一時的な障害が起きた。問題を修正するためにDockerイメージを大量に再ビルドしなければならなかった
この回避策はあまりに大胆で前例がなく、失効しておらず広く互換性のあるルートからクロス署名を受けるコストとの差が非常に大きかったため採用されたのだと思う。テストも膨大に必要だったはずだ。完璧ではなかったが、全体としては滑らかに乗り切れたのが印象的だった
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
しかし調べてみると、実際には5行目がない形で動作しており、すべての時間チェックは現在時刻を基準に行われる。チェーン内のすべての証明書が今この時点で有効でなければならない
コード署名証明書は、自分がTLSもそうだと思っていた方式で動作する。タイムスタンプ付きのコードは、ルート証明書が失効していても、タイムスタンプ時点でルートが有効だったなら依然として有効だ
交差署名証明書の失効が大半の人にとって何事もないものであってほしいが、以前の DST 交差署名失効 はそうではなかった。
記憶している限り、GnuTLS は失効後のパス構築を適切に行えなかった。失効した証明書へ向かうパスだけを作り、それを失効と判定し、他の可能なパスを無視したまま停止していたように見える。
さらに悪いことに、GnuTLS は apt が HTTPS を使う際に利用する TLS ライブラリだった。HTTPS はデフォルトではないが、私たちのセキュリティチームはすべてのパッケージをベンダリングして安全に提供したいと考えており、それ自体は合理的だったものの、コストは障害になっていた。Bullseye では修正されていたようだが、純粋に幸運なことに失効のわずか 1 週間ほど前だった。Azure もその失効に関連して複数の障害を経験していた。
暗号化されていない HTTP を使う以外に、TLS がもはやウェブで最も脆弱な構成要素でなくなるようにする、提案されている解決策はある？
プロトコル廃止、証明書失効、置き換えといった絶え間ない変化は、計画的陳腐化 を過度に増幅しているように見える。
計画的陳腐化につながる悪い部分は、機器があまりにも早くメーカー更新を受けられなくなり、第三者も更新できないことだ。
私が好む解決策は、メーカーが販売終了から 10 年を迎える前にセキュリティアップデートの提供をやめることを禁止するか、やめたいならすべてをオープンソースとして公開するか、購入者全員に全額返金できるようにする法律だ。
そうしなければならない理由は、地球規模での分散失効が途方もなく難しい問題だからだ。ユーザーと証明書のある種の結び付きが事実上失効不能であることを和らげるために、証明書の寿命を短くして被害範囲を小さくしている。
もちろん大きな慰めにはならないが、ACME 以後の短命証明書の世界は、長期 Verisign 証明書の悪夢のような世界よりも開発者体験は良い。TLS の代替も結局は似た問題に直面せざるを得ないことは覚えておく価値がある。
x509 証明書形式は実際のところ長いあいだほとんど変わっていない。
プロトコルの変化はもう安定していきそうだ。TLS 1.2 は 2008 年に導入され、今でも十分良いと見なされているので、もはや新しいとは言い難い。多くの人が綿密に調べてきたのだから、問題の大半はすでに表面化していることを期待したい。
私の考えでは、Let's Encrypt がやっていることは本質的に DANE と見なすこともできるので、だったらそのままサポートすればいいのではないかと思う。もちろん DANE が適さないユースケースもあるかもしれない。
完璧さが十分に良いものを妨げる理由には見えないし、望む人は DANE を使えるようにすればいい。
「運用コストを大幅に削減し、プライバシー保護とセキュリティ改善への資金投入に集中できる」というのは、交差署名 に何百万ドルもの金額を払っているという意味？
同年の総費用は 510 万ドルだったので、この支出は予算のほぼ 10% に相当する。
[0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...
証明書会社がどうやって交差署名してくれることになったのか、その裏話を知っている人はいる？ Let’s Encrypt は彼らのビジネスモデルを完全に壊してしまうのでは？
RapidSSL や GoDaddy のような会社は、「うちの CA 事業全体を買え」と言えるほどの金額を提示されない限り、Let’s Encrypt に交差署名はしなかっただろう。
ただし DV 証明書販売は IdenTrust のビジネスモデルではなかったので、他のところで推測されているように 6 桁未満の金額で交差署名を提供することに前向きだった可能性はある。TLS ルート証明書の仕組み上、IdenTrust の交差署名も、超高収益 CA の交差署名と同じくらい LE にとって有用だった。
IdenTrust が潰れたようにも見えない。
1 IdenTrust 48.5% 53.6%
2 DigiCert Group 13.1% 14.5%
3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
4 GlobalSign 6.1% 6.7%
5 Let's Encrypt 5.8% 6.4%
6 GoDaddy Group 4.8% 5.3%
https://en.wikipedia.org/wiki/Certificate_authority
2021年末にクロス署名された中間証明書とDST Root CA X3自体が失効した際、最新ブラウザはすべてLEルートを信頼していたものの、Android端末の3分の1以上はいまだに古いOSを動かしており、LE証明書を使うWebサイトを突然信頼できなくなる状況だったという。
数週間前にようやく知ったが、Ubiquitiユーザーも影響を受けたようだ
最近AWSからローカルサーバーへバックエンドを移した際、普段使っていたLetsencryptの代わりにZeroSSLへ切り替えなければならなかった。
サポート中の2016年製IoT機器に、LE証明書の検証に必要なルート証明書が入っていなかったためだ。おそらくLEが使っていたR3ルート証明書の2021年失効に関連していたのだと思う。
証明書1つの失効で、販売済み製品全体が文鎮化し得るというのはかなり衝撃的だった。このケースでは別の提供元の有効なルート証明書があったため、大きな問題にはならなかった。
CA/Browser Forumが定めた日付を過ぎた後も発行を続けることさえあった。あのとき、Web PKIを使いながら更新を配布する手段がないのは両立しないと皆が気づいたと思っていたが、そうではなかったようだ
クロス署名が導入された直後から、デスクトップ向けサイトではクロス署名証明書を削除してきた。
それまで存在しなかった互換性問題が生じ、一部の証明書バリデータが失効したルート証明書でつまずいたためだ。影響を受けたユーザーは技術的な背景に詳しくなく、結局根本原因は分からないままだった