ブラウザーが Web サイトを認証するには、有効な証明書チェーンをブラウザー自身に提示します。 典型的なチェーンを上に示しますが、複数の中間証明書が存在する場合があります。 有効なチェーン内の証明書の最小数は XNUMX です。

ルート証明書は認証局の中核です。 これは文字通り OS またはブラウザに組み込まれており、デバイス上に物理的に存在します。 サーバー側からは変更できません。 デバイスのOSまたはファームウェアの強制アップデートが必要です。

セキュリティスペシャリストのスコット・ヘルム пишетLet's Encrypt 認証局は今日インターネット上で最も人気のある CA であり、そのルート証明書はすぐに失効するため、主な問題は Let's Encrypt 認証局で発生することになります。 Let's Encrypt ルートの変更 8年2020月XNUMX日予定.

証明機関 (CA) の最終証明書と中間証明書はサーバーからクライアントに配信され、ルート証明書はクライアントから配信されます。 すでに持っているしたがって、この証明書のコレクションを使用してチェーンを構築し、Web サイトを認証できます。

問題は、各証明書には有効期限があり、それを過ぎると交換する必要があることです。 たとえば、1 年 2020 月 XNUMX 日から、Safari ブラウザーのサーバー TLS 証明書の有効期間に制限を導入する予定です。 最長398日.

これは、私たち全員が少なくとも 12 か月ごとにサーバー証明書を交換する必要があることを意味します。 この制限はサーバー証明書にのみ適用されます。 ノー ルート CA 証明書に適用されます。

CA 証明書は異なるルール セットによって管理されるため、有効期限も異なります。 有効期間が 5 年の中間証明書や、耐用年数が 25 年のルート証明書もよくあります。

中間証明書はサーバーによってクライアントに提供されるため、通常は問題はありません。サーバー自体が自身の証明書を頻繁に変更するため、その過程で中間証明書を置き換えるだけです。 ルート CA 証明書とは異なり、サーバー証明書とともに置き換えるのは非常に簡単です。

すでに述べたように、ルート CA はクライアント デバイス自体、OS、ブラウザ、またはその他のソフトウェアに直接組み込まれています。 ルート CA の変更は、Web サイトの制御の範囲を超えています。 これには、OS またはソフトウェアのアップデートなど、クライアントのアップデートが必要です。

一部のルート CA は非常に長い間存在しており、約 20 ～ 25 年になります。 間もなく、最も古いルート CA の一部が天寿を全うし、寿命が近づいています。 私たちのほとんどにとって、これはまったく問題になりません。CA が新しいルート証明書を作成し、OS やブラウザのアップデートとして長年にわたり世界中に配布されてきたからです。 しかし、OS やブラウザを長い間更新していない人がいると、それは一種の問題になります。

この状況は、30 年 2020 月 10 日の 48:38:XNUMX GMT に発生しました。 これはまさにそのときです AddTrust ルート証明書が壊れています Comodo 認証局 (Sectigo) からの認証です。

これは、ストアに新しい USERTrust ルート証明書を持たないレガシー デバイスとの互換性を確保するための相互署名に使用されました。

残念ながら、問題は従来のブラウザだけでなく、OpenSSL 1.0.x、LibreSSL、および GnuTLS。 たとえば、セットトップボックスでは 年、 サービス ヘロク、Fortinet の Chargify アプリケーション、Linux 用 .NET Core 2.0 プラットフォーム上、および 他にもたくさん.

最新のブラウザは 2.3 番目の USERTRust ルート証明書を使用できるため、この問題はレガシー システム (Android 10.11、W​​indows XP、Mac OS X 9、iOS 1.0 など) にのみ影響すると考えられていました。 しかし実際には、無料の OpenSSL XNUMX.x および GnuTLS ライブラリを使用する何百もの Web サービスで障害が始まりました。 証明書が期限切れであることを示すエラー メッセージが表示され、安全な接続を確立できなくなりました。

次へ - 暗号化しましょう

今後のルート CA の変更のもう XNUMX つの良い例は、Let's Encrypt 認証局です。 もっと 2019年XNUMX月 彼らは Identrust チェーンから独自の ISRG ルート チェーンに切り替えることを計画していましたが、これは 起こらなかった.

「AndroidデバイスでISRGルートが採用されていないことへの懸念から、ネイティブルートの移行日を8年2019月8日から2020年XNUMX月XNUMX日に変更することを決定した」とLet's Encryptは声明で述べた。

この日付は、「ルート伝播」と呼ばれる問題、より正確には、ルート CA がすべてのクライアントにあまり広く分散されていない場合にルート伝播が行われないため、延期する必要がありました。

Let's Encrypt は現在、IdenTrust DST ルート CA X3 にチェーンされた相互署名中間証明書を使用しています。 このルート証明書は 2000 年 30 月に発行され、2021 年 1 月 XNUMX 日に期限切れになります。 それまでは、Let's Encrypt は独自の自己署名 ISRG Root XXNUMX に移行する予定です。

ISRG ルートは 4 年 2015 月 XNUMX 日にリリースされました。 その後、認証局としての承認手続きが始まり、認証局としての承認手続きは終了した。 6 8月2018年。 この時点から、オペレーティング システムまたはソフトウェア アップデートを通じてすべてのクライアントがルート CA を利用できるようになりました。 あとはアップデートをインストールするだけでした。

しかし、それが問題なのです。

携帯電話、テレビ、その他のデバイスが 1 年間更新されていない場合、新しい ISRG Root XXNUMX ルート証明書をどのようにして知ることができるのでしょうか? また、システムにインストールしない場合、Let's Encrypt が新しいルートに切り替わるとすぐに、デバイスはすべての Let's Encrypt サーバー証明書を無効にします。 また、Android エコシステムには、長期間更新されていない古いデバイスが多数あります。

Android エコシステム

これが、Let's Encrypt が独自の ISRG ルートへの移行を遅らせ、依然として IdenTrust ルートに至る中間を使用している理由です。 しかし、いずれにしても移行は行われなければならない。 そしてルート変更の日付が割り当てられます 7月8 2020年.

ISRG X1 ルートがデバイス (テレビ、セットトップ ボックス、またはその他のクライアント) にインストールされていることを確認するには、テスト サイトを開きます https://valid-isrgrootx1.letsencrypt.org/。 セキュリティ警告が表示されない場合は、通常は問題ありません。

新しいルートへの移行という課題に直面しているのは Let's Encrypt だけではありません。 インターネット上の暗号化は 20 年ほど前に使用され始めたため、現在、多くのルート証明書の有効期限が切れようとしています。

スマート TV ソフトウェアを長年更新していないスマート TV の所有者は、この問題に遭遇する可能性があります。 たとえば、新しい GlobalSign ルート R5ルート は 2012 年にリリースされましたが、その後、一部の古いスマート TV はこのルート CA を持たないため、それにチェーンを構築できなくなりました。 特に、これらのクライアントは bbc.co.uk Web サイトへの安全な接続を確立できませんでした。 この問題を解決するために、BBC 管理者はあるトリックに頼らなければなりませんでした。 私たちはこれらのクライアントのために代替チェーンを構築しました 古いルートを使用して、追加の中間証明書を介して R3ルート и R1ルート、まだ腐っていません。

www.bbc.co.uk (リーフ) GlobalSign ECC OV SSL CA 2018 (中級) GlobalSign Root CA - R5 (中級) GlobalSign Root CA - R3 (中級)

これは一時的な解決策です。 クライアントソフトウェアを更新しない限り、問題は解決しません。 スマート TV は本質的に、Linux を実行する機能が制限されたコンピューターです。 そして更新がなければ、そのルート証明書は必然的に腐ってしまいます。

これはテレビだけでなくすべてのデバイスに当てはまります。 インターネットに接続され、「スマート」デバイスとして宣伝されているデバイスをお持ちの場合、腐った証明書の問題がほぼ確実にそれに関係します。 デバイスが更新されていない場合、ルート CA ストアは時間の経過とともに古くなり、最終的には問題が表面化します。 問題がどの程度早く発生するかは、ルート ストアが最後に更新された時期によって異なります。 これは、デバイスの実際の発売日より数年前になる可能性があります。

ちなみに、これが、一部の大手メディア プラットフォームが Let's Encrypt のような最新の自動認証局を使用できない理由である、と Scott Helme 氏は書いています。 これらはスマート TV には適しておらず、ルートの数が少なすぎるため、レガシー デバイスでの証明書のサポートを保証できません。 そうしないと、テレビは最新のストリーミング サービスを開始できなくなります。

AddTrust の最新の事件は、大規模な IT 企業ですら、ルート証明書の有効期限が切れるという事実に対する備えができていないことを示しました。

この問題に対する解決策は XNUMX つだけ、それはアップデートです。 スマートデバイスの開発者は、ソフトウェアとルート証明書を更新するためのメカニズムを事前に提供する必要があります。 一方、メーカーにとって、保証期間が終了した後にデバイスの動作を保証することは利益がありません。

出所： habr.com