Устаревание корневого сертификата AddTrust привело к массовым сбоям
30 мая истёк 20-летний срок действия корневого сертификата AddTrust, который применялся для формирования перекрёстной подписи (cross-signed) в сертификатах одного из крупнейших удостоверяющих центров Sectigo (Comodo). Перекрёстная подпись позволяла обеспечить совместимость с устаревшими устройствами, в хранилище корневых сертификатов которых не был добавлен новый корневой сертификат Sectigo.
Теоретически прекращение действия корневого сертификата AddTrust должно было привести лишь к нарушению совместимости с устаревшими системами (старее Android 2.3, Windows XP и т.п.), так как второй корневой сертификат, используемый в перекрёстной подписи остаётся актуальным и современные браузеры учитывают его при проверке цепочки доверия. На практике обнаружились проблемы с проверкой перекрёстной подписи в не использующих браузеры HTTP-клиентах, в том числе на базе OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата, если на сервере используется сертификат Sectigo, связанный цепочкой доверия с корневым сертификатом AddTrust.
Если пользователи современных браузеров не заметили устаревания корневого сертификата AddTrust при обработке перекрёстно подписанных сертификатов Sectigo, то в различных сторонних приложениях и серверных обработчиках начали всплывать проблемы, что привело к нарушению работы многих инфраструктур, использующих шифрованные каналы связи для взаимодействия между компонентами.
Например, возникли проблемы с доступом к некоторым репозиториям пакетов в Debian и Ubuntu (apt стал выдавать ошибку проверки сертификата), стали завершаться сбоем обращения из скриптов при помощи утилит «curl» и «wget», наблюдаются ошибки при использовании Git, нарушилась работа платформы потокового вещания Roku, перестали вызываться обработчики Stripe и DataDog, начали возникать крахи в приложениях Heroku, наблюдаются проблемы в Ruby-, PHP- и Python-скриптах, использующих модуль с http-клиентом. Программы на языке Go проблеме не подвержены, так как в Go предлагается собственная реализация TLS.
Предполагалось, что проблема затрагивает старые выпуски дистрибутивов (включая Debian 9, Ubuntu 16.04, RHEL 6/7) в которых используются проблемные ветки OpenSSL, но проблема проявилась также при работе пакетного менеджера APT в актуальных выпусках Debian 10 и Ubuntu 18.04/20.04, так как APT использует библиотеку GnuTLS. Суть проблемы в том, что многие TLS/SSL-библиотеки разбирают сертификат как линейную цепочку, в то время как в соответствии с RFC 4158 сертификат может представлять ориентированный распределённый циклический граф с несколькими якорями доверия, которые нужно учитывать. О данной недоработке в OpenSSL было известно уже много лет и она была устранена в ветке 1.1.x. В GnuLTS проблема остаётся неисправленной.
В качестве обходного пути устранения сбоя предлагается удалить из системного хранилища сертификат AddTrust External CA Root (например, удалить из /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»).
Для блокирования проблемы в Fedora и 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 extract
Но данный способ не работает для GnuTLS (например, продолжает выдаваться ошибка проверки сертификата при запуске утилиты wget).
На стороне сервера можно изменить порядок перечисления сертификатов в цепочке доверия, отправляемых сервером к клиенту (если связанный с «AddTrust External CA Root» сертификат будет убран из списка, то проверка клиентом пройдёт успешно). Для проверки и генерации новой цепочки доверия можно использовать сервис whatsmychaincert.com. Компания Sectigo также предоставила альтернативный перекрёстно подписанный промежуточный сертификат «AAA Certificate Services», который будет действовать до 2028 года.
Источник: http://www.opennet.ru/opennews/art.shtml? num=53061
© OpenNet
