AddTrust ルート証明書の非推奨により、OpenSSL および GnuTLS システムでクラッシュが発生する

30月20日、ルート証明書のXNUMX年間の有効期限が切れました トラストの追加どちら 適用済み 最大の認証局の XNUMX つである Sectigo (Comodo) の相互署名証明書を生成します。 相互署名により、新しい USERTRust ルート証明書がルート証明書ストアに追加されていないレガシー デバイスとの互換性が可能になりました。

AddTrust ルート証明書の非推奨により、OpenSSL および GnuTLS システムでクラッシュが発生する

理論的には、相互署名で使用されている 2.3 番目のルート証明書が残っているため、AddTrust ルート証明書の終了はレガシー システム (Android 10.11、W​​indows XP、Mac OS X 9、iOS XNUMX など) との互換性違反につながるだけです。有効な最新のブラウザでは、信頼チェーンをチェックするときにそれが考慮されます。 練習中 現れた OpenSSL 1.0.x および GnuTLS ベースのクライアントを含む、ブラウザー以外の TLS クライアントにおける相互署名検証の問題。 サーバーが信頼チェーンによって AddTrust ルート証明書にリンクされた Sectigo 証明書を使用している場合、安全な接続が確立されなくなり、証明書が期限切れであることを示すエラーが表示されます。

最新のブラウザのユーザーが、相互署名された Sectigo 証明書を処理するときに、AddTrust ルート証明書の廃止に気付かなかった場合、さまざまなサードパーティ アプリケーションやサーバー側ハンドラーで問題が発生し始め、 違反 働く コンポーネント間の対話に暗号化された通信チャネルを使用する多くのインフラストラクチャ。

たとえば、次のようなものがありました。 問題 Debian および Ubuntu の一部のパッケージ リポジトリにアクセスすると (apt が証明書検証エラーを生成し始めました)、「curl」および「wget」ユーティリティを使用したスクリプトからのリクエストが失敗し始め、Git の使用時にエラーが観察されました。 違反した Roku ストリーミング プラットフォームは動作していますが、ハンドラーは呼び出されなくなりました ストライプ и データドッグ、開始 クラッシュが発生する Heroku アプリでは、 停止 OpenLDAP クライアントが接続すると、STARTTLS を使用した SMTPS および SMTP サーバーへのメール送信に関する問題が検出されます。 さらに、http クライアントでモジュールを使用するさまざまな Ruby、PHP、Python スクリプトでも問題が観察されます。 ブラウザの問題 影響を与える Epiphany は広告ブロック リストの読み込みを停止しました。

Go プログラムは、Go が提供するため、この問題の影響を受けません。 独自の実装 TLS。

はずだったこの問題は古いディストリビューション リリース (Debian 9、Ubuntu 16.04、 RHEL6/7) 問題のある OpenSSL ブランチを使用しますが、問題は 明らかになった APT は GnuTLS ライブラリを使用するため、APT パッケージ マネージャーが Debian 10 および Ubuntu 18.04/20.04 の現在のリリースで実行されている場合も同様です。 問題の核心は、多くの TLS/SSL ライブラリが証明書を線形チェーンとして解析するのに対し、RFC 4158 によれば、証明書は考慮する必要がある複数のトラスト アンカーを含む有向分散円グラフを表すことができることです。 OpenSSL と GnuTLS のこの欠陥について было 知られている 長年。 OpenSSL では、この問題はブランチ 1.1.1 で修正されました。 GnuTLS 残る 未修正.

回避策として、システム ストアから「AddTrust 外部 CA ルート」証明書を削除することをお勧めします (たとえば、/etc/ca-certificates.conf および /etc/ssl/certs から削除してから「update-ca」を実行します)。 -certificates -f -v")、その後、OpenSSL は参加して相互署名証明書の通常の処理を開始します。 APT パッケージ マネージャーを使用する場合、自己責任で個々のリクエストの証明書検証を無効にすることができます (たとえば、「apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false」)。 。

問題をブロックするには フェドーラ и RHEL AddTrust 証明書をブラックリストに追加することが提案されています。

trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust 抽出

しかし、この方法は 動作しません GnuTLS の場合 (たとえば、wget ユーティリティの実行時に証明書検証エラーが引き続き表示されます)。

サーバー側では次のことができます изменить トリム サーバーからクライアントに送信された信頼チェーン内の証明書をリストします (「AddTrust 外部 CA ルート」に関連付けられた証明書がリストから削除された場合、クライアントの検証は成功します)。 新しい信頼チェーンを確認して生成するには、サービスを使用できます。 whatsmychaincert.com。 セクティゴも предоставила 代替の相互署名中間証明書」AAA証明書サービスこれは 2028 年まで有効であり、古いバージョンの OS との互換性が維持されます。

追記:問題も 明らかになっている リブレSSLでは。

出所: オープンネット.ru

コメントを追加します