01.06.2020 09:03
GlobalSign_admin 6 5300 Источник


Центр сертификации Sectigo (Comodo) заранее предупредил пользователей об истечении срока действия корневого сертификата AddTrust, который использовался для перекрёстной подписи, чтобы обеспечить совместимость с устаревшими устройствами, в хранилище которых нет нового корневого сертификата USERTrust.

20-летний срок действия AddTrust истёк 20 мая 2020 года в 10:48:38 UTC. К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku (см. ответ в техподдержке от 30.05.2020), Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.

Предполагалось, что проблема затронет только устаревшие системы (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 и т.п.), поскольку современные браузеры могут задействовать второй корневой сертификат USERTRust, как показано на диаграмме.


Цепочка сертификатов

Но 30 мая 2020 года по факту начались сбои в сотнях веб-сервисов, которые использовали свободные библиотеки OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата.

Соответствующий тикет в баг-трекере OpenSSL (логин и пароль: guest) закрыт 25 февраля 2020 года только для версии OpenSSL 1.1.0.

Почему возникает ошибка


При подключении клиента TLS-сервер отправляет ему свой сертификат. Клиент должен построить цепочку сертификатов от сертификата сервера до корневого сертификата, которому клиент доверяет. Чтобы помочь клиенту построить эту цепочку, сервер отправляет дополнительно один или несколько промежуточных сертификатов вместе со своим собственным.



Например, веб-сайт отправляет следующие два сертификата:

1.
Субъект = *.habr.com
Издатель = Sectigo ECC Domain Validation Secure Server CA
Начало действия = ?суббота, ?30 ?мая ?2020 ?г. 3:00:00
Окончание действия = ?пятница, ?3 ?декабря ?2021 ?г. 2:59:59

2.
Субъект = Sectigo ECC Domain Validation Secure Server CA
Издатель = USERTrust ECC Certification Authority
Начало действия = ?пятница, ?2 ?ноября ?2018 ?г. 3:00:00
Окончание действия = ??среда, ?1 ?января ?2031 ?г. 2:59:59

Первый сертификат принадлежит серверу и выдан центром сертификации Sectigo. Второй выдан центром сертификации USERTrust ECC и является корневым сертификатом. Эти два сертификата образуют полную цепочку к доверенному корню.

Однако центр сертификации USERTrust — это относительно новый корень. Он был создан в 2010 году, и потребовалось много лет, чтобы ему стали доверять все клиенты. Ещё в прошлом году появлялись сообщения, что отдельные клиенты не доверяют этому корню. Поэтому некоторые серверы высылают клиенту дополнительный промежуточный сертификат USERTrust ECC Certification Authority, выданный AddTrust External CA Root. Этот сертификат был сгенерирован в 2000 году, и именно у него срок действия закончился 30 мая 2020 года.

У грамотных валидаторов сертификатов, включая современные браузеры, это не вызвало проблем, потому что они сами могут построить цепочку доверия до USERTrust, но вот с клиентами, которые используют OpenSSL 1.0.x или GnuTLS, возникла проблема. Даже если эти клиенты доверяют корневому центру сертификации USERTrust и хотят построить цепочку к нему, у них всё равно в конечном итоге получается цепочка к AddTrust External CA Root, что приводит к сбою проверки сертификата.

Компания Sectigo предоставила альтернативный перекрёстно подписанный промежуточный сертификат AAA Certificate Services, который будет действовать до 2028 года.

Проверка своих сервисов


Операторам серверных обработчиков и клиентских приложений рекомендуется проверить свою цепочку сертификатов на наличие устаревшего корневого сертификата AddTrust.

По сути, нужно просто удалить AddTrust External CA Root из цепочки доверия.

Для серверных операторов есть сервис What's My Chain Cert?, который выполняет такую проверку и помогает сгенерировать новую цепочку доверия со всеми необходимыми промежуточными сертификатами. В эту цепочку необязательно включать корневой сертификат, поскольку он уже есть в хранилище у всех клиентов. Кроме того, включать его в цепочку просто неэффективно из-за увеличения размера рукопожатия SSL.

Операторам клиентских приложений рекомендуется проапгрейдится на последнюю версию библиотеки TLS. Если это невозможно, нужно удалить из своего хранилища сертификат AddTrust External CA Root. Если он отсутствует в хранилище, то строится корректная цепочка доверия к новому корневому сертификату USERTrust RSA Certification Authority, так что проверка TLS проходит корректно.

Для удаления AddTrust External CA Root нужно сделать следующее:

  1. Отредактировать /etc/ca-certificates.conf и закомментить mozilla/AddTrust_External_Root.crt
  2. Запустить update-ca-certificates

Для устранения проблемы в 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.

См. также:
«Проблема с сертификатами Sectigo после 30 мая 2020 года и метод решения» в корпоративном блоге Хабра




PKI-решения для вашего предприятия. Свяжитесь с нами +7 (499) 678 2210, sales-ru@globalsign.com.