Addtrust external ca root windows 7

Корневой сертификат AddTrust от Sectigo истёк 30 мая 2020 года, что вызвало проблемы в клиентах OpenSSL 1.0.x и GnuTLS

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


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

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

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

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

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

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

Первый сертификат принадлежит серверу и выдан центром сертификации 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 нужно сделать следующее:

Но этот способ не работает для GnuTLS.


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

Источник

Проблема с сертификатами Sectigo после 30 мая 2020 года и метод решения

В субботу 30 мая 2020 года возникла не сразу понятная проблема с популярными SSL/TLS сертификатами от вендора Sectigo (бывший Comodo). Сами сертификаты продолжали оставаться в полном порядке, однако «протух» один из промежуточных CA-сертификатов в цепочках, с которыми поставлялись данные сертификаты. Ситуация не сказать, чтобы фатальная, но неприятная: актуальные версии браузеров ничего не заметили, однако большая часть автоматизаций и старых браузеров/ОС оказались не готовыми к такому повороту.

Хабр не стал исключением, поэтому и написан этот ликбез / postmortem.

TL;DR Решение в самом конце.

Опустим базовую теорию про PKI, SSL/TLS, https и прочее. Механика удостоверения сертификатом безопасности домена состоит в построении цепочки из ряда сертификатов до одного из доверенных браузером или операционной системой, которые хранятся в так называемом Trust Store. Этот список распространяется с операционной системой, экосистемой среды исполнения кода или с браузером. Любые сертификаты имеют срок действия, по истечении которого они считаются недоверенными, в том числе сертификаты в trust store. Как выглядела цепочка доверия до наступления рокового дня? Разобраться нам поможет web-утилита SSL Report от компании Qualys.

Итак, одним из самых популярных «коммерческих» сертификатов является Sectigo Positive SSL (ранее разывался Comodo Positive SSL, сертификаты с этим наименованием ещё в ходу), он является так называемым DV-сертификатом. DV — это самый примитивный уровень сертификации, означающий проверку доступа к управлению доменом у выпускающего такой сертификат. Собственно, DV и расшифровывается как «domain validation». Для справки: ещё есть OV (organization validation) и EV (extended validation), а бесплатный сертификат от Let’s Encrypt тоже DV. Для тех, кому по какой-либо причине не устраивает механизм ACME, продукт Positive SSL является самым подходящим по соотношению цена/возможности (однодоменный сертификат стоит около 5-7 долларов за год с суммарным сроком действия сертификата до 2 лет и 3 месяцев).

Типовой сертификат Sectigo DV (RSA) до недавнего времени поставлялся с такой цепочкой промежуточных CA:

Здесь отсутствует «третий сертификат», самоподписной от AddTrust AB, так как в какой-то момент времени стало считаться правилом плохого тона включать в цепочки самоподипсанные корневые сертификаты. Можно обратить внимание, что промежуточный CA, выданный UserTrust от AddTrust имеет срок действия 30 мая 2020 года. Это не спроста, так как для данного CA была запланирована процедура вывода из эксплуатации. Считалось, что к 30 мая 2020 года во всех trust store уже к этому времени появится кросс-подписанный сертификат от UserTrust (под капотом это один и тот же сертификат, вернее публичный ключ) и цепочка, даже с включенным недоверенным уже сертификатом будет иметь альтернативные пути построения и никто этого не заметит. Однако, планы разбились о реальность, а именно пространный термин «legacy systems». Действительно, владельцы актуальных версий браузеров ничего не заметили, однако сломалась гора автоматизаций, построенных на curl и ssl/tls-библиотеках ряда языков программирования и сред исполнения кода. Надо понимать, что многие продукты не руководствуются встроенными в ОС средствами построения цепочек, а «носят» свой trust store с собой. И не всегда они содержат то, что хотело бы видеть CA/Browser Forum. Да и в Linux далеко не всегда обновляются пакеты типа ca-certificates. В итоге всё вроде в порядке, но что-то не работает то там, то здесь.

Читайте также:  Openvpn as windows service

По рисунку 1 понятно, что хоть и у подавляющего большинства всё выглядело как обычно, у кого-то что-то сломалось и трафик заметно просел (левая красная черта), потом он подрос, когда заменили один из ключевых сертификатов (правая черта). Были всплески и посередине, когда меняли иные сертификаты, от которых тоже что-то зависело. Так как у большинства визуально всё продолжало работать более-менее штатно (за исключением странных глюков типа невозможности загрузки картинок на Habrastorage), можно сделать косвенный вывод о количестве legacy-клиентов и ботов на Хабре.

Рисунок 1. График «трафика» на Хабре.

По рисунку 2 можно оценить, как строится в актуальных версиях браузеров «альтернативная» цепочка до доверенного CA-сертификата в браузере пользователя, даже при наличии «протухшего» сертификата в цепочке. Это, как считала сама Sectigo, тот самый повод не делать ничего.

Рисунок 2. Цепочка до доверенного сертификата современной версии браузера.

А вот на рисунке 3 можно заметить, как всё выглядит на самом деле, когда что-то пошло не так и у нас legacy система. В таком случае соединение HTTPS не устанавливается и мы видим ошибку типа «certificate validation failed» или подобную ей.

Рисунок 3. Цепочка инвалидировалась, так как корневой сертификат и подписанный им промежуточный «протухли».

На рисунке 4 мы уже видим «решение» для legacy систем: есть ещё один промежуточный сертификат, вернее «кросс-подпись» от иного CA, который как правило предустановлен в legacy системах. Это то, что нужно сделать: найти этот сертификат (который помечен как Extra download) и заменить им «протухший».

Рисунок 4. Альтернативная цепочка для legacy систем.

К слову: у проблемы не было широкой огласки и какого-то общественного обсуждения, в том числе из-за излишней самонадеянности Sectigo. Вот, например, мнение одного из поставщиков сертификатов в отношении к данной ситуации:

Previously they [Sectigo] assured everyone that no issues will be. However, the reality is that some legacy servers/devices are affected.

That is a ridiculous situation. We pointed their attention to the expiring AddTrust RSA/ECC multiple times within a year and each time Sectigo assured us no issues will be.

Я лично задавал вопрос на Stack Overflow на этот счёт месяц назад, но судя по всему, аудитория проекта не очень подходящая для таких вопросов, так что пришлось не него ответить самостоятельно по факту разбора.

Sectigo выпустил на этот счёт FAQ, но он настолько нечитабельный и пространный, что пользоваться им невозможно. Вот цитата, являющаяся квинтэссенцией всей публикации:

What You Need to Do
For most use cases, including certificates serving modern client or server systems, no action is required, whether or not you have issued certificates cross-chained to the AddTrust root.

As of April 30, 2020: For business processes that depend on very old systems, Sectigo has made available (by default in the certificate bundles) a new legacy root for cross-signing, the “AAA Certificate Services” root. However, please use extreme caution about any process that depends on very old legacy systems. Systems that have not received the updates necessary to support newer roots such as Sectigo’s COMODO root will inevitably be missing other essential security updates and should be considered insecure. If you would still like to cross-sign to the AAA Certificate Services root, please contact Sectigo directly.

Очень нравится тезис «very old», конечно. Например, curl в консоли Ubuntu Linux 18.04 LTS (нашей базовой ОС на данный момент) с последними обновлениями не старше месяца, сложно назвать very old, однако оно не работает.

Большинство дистрибьютеров сертификатов выпустили свои заметки с решениями ближе к вечеру 30 мая. Например, очень годная в техническом плане от NameCheap (с конкретным описанием что делать и с готовыми сборками CA-bundles в zip-архивах, но только RSA):

Рисунок 5. Семь шагов, чтобы быстро всё починить.

Есть неплохая статья от Redhat, но там всё более Legacy и нужно инсталлировать даже ещё более корневой legacy сертификат от Comodo, чтобы всё работало.

Решение со стороны сервера

Стоит продублировать решение ещё и тут. Ниже располагаются два набора цепочек для сертификатов DV Sectigo (не Comodo!), одна для привычных RSA сертификатов, другая для менее привычных ECC (ECDSA) сертификатов (мы используем две цепочки достаточно давно). С ECC было сложнее, так как большинство решений не учитывает наличие таких сертификатов в силу их малой распространённости. В итоге, нужный промежуточный сертификат был найден на crt.sh.

Цепочка для сертификатов, основанных на алгоритме ключа RSA. Сравните со своей цепочкой и обратите внимание, что заменился только нижний сертификат, а верхний остался прежним. Я их отличаю в бытовых условиях по последним трём символам блоков base64 не считая символа «равно» (в данном случае En8= и 1+V ):

Цепочка для сертификатов, основанных на алгоритме ключа ECC. Аналогично с цепочкой для RSA, заменился только нижний сертификат, а верхний остался прежним (в данном случае fmA== и v/c= ):

Решение со стороны клиента

Внимание! Тут далее по тексту размещаются сертификаты безопасности и предложения их импортировать в систему. Это референс! Не надо бездумно импортировать их в trust store и делать доверенными. Мы в Интернете и тут нельзя никому доверять (даже Хабру, sad but true)! Если просто импортировать промежуточные сертификаты, как правило, достаточно безопасно (не делая их вручную «доверенными», они наследуют доверие сами и без вас), то импортировать самоподписные руты надо строго включая мозг и сверяя отпечатки сертификатов с эталонными значениями, указанными на сайтах вендоров сертификатов. Praemonitus, praemunitus.

Читайте также:  Windows 10 версия 1909 ошибка 0xc1900223

Как правило, если владелец сервера с проблемным сертификатом уже заменил цепочку, то на стороне клиента делать ничего не нужно, так как недостающий промежуточный сертификат имеет кросс-подпись от достаточно старого CA, который с большей долей вероятности уже был заботливо предустановлен в trust store даже сильно legacy-системы при царе Горохе. И всё должно работать.

Но бывают случаи, что владелец сервера либо не в курсе проблемы, либо не обладает должной компетенцией для её решения, либо решать проблему банально некому, ибо сервер на лютом аутсорсе, и всем в принципе наплевать (что-то на уровне проблемы индейцев и шерифа). А попасть на такой сервер надо из-под системы не первой свежести. Как показали комментарии, к сожалению, такие случаи определённо носят достаточно массовый характер.

Есть известная проблема реализации построения цепочек PKI в ряде старых крипто-библиотек (некотоорые версии OpenSSL и GnuTLS, например), которые банально не умеют строить множество цепочек от нескольких доверенных якорей к конечному сертификату. То есть, они воспринимают цепочку доверия как линейную сущность, а не направленный граф. Первой помощью в таких системах будет удаление из trust store или отключение почившего корневого сертификата AddTrust External CA Root. Выглядит он так:

Конечно, хорошим подспорьем будет обновить OpenSSL, например, в случае проблем именно с этой библиотекой. Но зачастую это практически невозможно, ибо мало заменить библиотеку с удовлетворением зависимостей, надо ещё и пересобрать софт, использующий эту библиотеку. Для большинства это непреодолимый квест и практически гарантированная возможность доломать систему до конца. В случае GnuTLS также гарантировано отдельное развлечение, местами даже пободрее, чем с OpenSSL. Весьма подробная заметка на OpenNET.

Далее, сделует проверить, что тот самый престарелый, но действительный сертификат AAA Certificate Services от Comodo, выпустивший в качестве подорожника кросс-подпись, наличествует в trust store ОС или браузера клиента. Идентифицировать его можно по следующим атрибутам:

Если такой сертификат отсутствует, то надо его импортировать в trust store и сделать доверенным. Без него не будет вообще работать ничего, даже если владелец сервера выполнит рекомендации. Но повторюсь: он должен быть в поодавляющем числе trust store систем и браузеров.

Далее, вторым шагом может стать импорт пачки промежуточных сертификатов, покрывающих большую часть случаев битой цепочки со стороны клиента. На самом деле, упомянутый выше «дедушка» сертификатов наплодил немало дочерних CA, с полным списком можно ознакомится внизу этой страницы. Но нам все не нужны, нам нужно только четыре. Два для продуктов под брендом Comodo и два для продуктов под брендом Sectigo, в каждой паре один для сертификатов, основанных на ключе RSA, а второй для ECDSA.

USERTrust RSA Certification Authority (под ним «ходят» разные промежуточные сертификаты RSA Sectigo):

USERTrust ECC Certification Authority (под ним «ходят» разные промежуточные сертификаты ECDSA Sectigo):

COMODO RSA Certification Authority (под ним «ходят» разные промежуточные сертификаты RSA Comodo, ещё не выведенные из эксплуатации):

COMODO ECC Certification Authority (под ним «ходят» разные промежуточные сертификаты ECDSA Comodo, ещё не выведенные из эксплуатации):

По идее, после таких манипуляций всё должно заработать. Разные операционные системы имеют разные механизмы шатания их trust store, в каждом конкретном случае надо обращаться к документации, как это делается. Надо отдать должное, этот случай достаточно сильно переполошил веб и большинство мэйнтейнеров ОС и иных систем выпустили свои FAQ, которые легко ищутся по ключевым словам fix sectigo certificate issue in << system_name >> или схожим в большинстве поисковиков.

Источник

Information Security Office

Computing Services

AddTrust External CA Root Expired May 30, 2020

DAY: Saturday
DATE: May 30, 2020 6:48 AM EDT

WHOM DOES THIS AFFECT?

SUMMARY

Sectigo’s legacy AddTrust External CA Root certificate expired on May 30, 2020 at 6:48 AM EDT. Modern clients should largely be unaffected. However, legacy clients, OpenSSL based clients, OpenLDAP clients, and clients configured to explicitly trust the AddTrust root instead of relying on an operating system or vendor managed truststore may need client or server reconfiguration to avoid loss of service.

Devices that received security updates after mid 2015 should have the modern USERTrust RSA Certification Authority root certificate (valid until Jan 2038) in their operating system or browser truststores and largely be unaffected.

Legacy devices that have not received updates to support newer roots will inevitably be missing other essential security updates and support for standards required by the modern Internet. We strongly encourage decommissioning these devices if their software cannot be upgraded. Non-upgraded, legacy devices should never be exposed to the Internet and special mitigations should be applied to isolate them from neighbor systems.

Client software based on OpenSSL prior to version 1.1.1 appear to have broken certificate path validation logic and require workarounds.

OpenLDAP clients on some platforms appear to have broken certificate path validation logic and require workarounds.

Clients configured to explicitly trust the AddTrust root may need client reconfiguration to either: 1) rely on operating system or vendor managed truststores or 2) explicitly trust the USERTrust RSA Certification Authority root or the alternative legacy AAA Certificate Services root (valid until Dec 2028).

TECHNICAL DETAILS

Certificate authorities (CAs) often control multiple root certificates, and generally the older the root the more widely distributed it is on older platforms. Taking advantage of this fact, CAs generate cross certificates to ensure that their certificates are as widely supported as possible. A cross certificate is where one root certificate is used to sign another. The cross certificate uses the same public key and Subject as the root being signed.

Читайте также:  Windows 10 hyper v включить amd

Certificate path validation is done client-side from leaf to root. Modern clients that receive Trust Chain A with the cross signed intermediate (see below) from servers should ignore it and instead follow Trust Chain B. This applies even after the root of Trust Chain A expires on May 30, 2020. However, some clients may have problems if one or more of the following conditions is true:

Conditions 1 and 2 may be addressed by configuring the server to send Trust Chain C.

Condition 3 requires the client to be reconfigured to either: 1) use the operating system or vendor managed truststore or 2) explicitly trust the USERTrust RSA Certification Authority root or the alternative legacy AAA Certificate Services root.

Certificates issued by the Carnegie Mellon Certificate Authority from April 30, 2020 through InCommon (powered by Sectigo) will include a link to download Trust Chain C. Again, we encourage you to use Trust Chain B unless you specifically need Trust Chain C for legacy device compatibility or to work around broken client issues.

Trust Chain A
AddTrust External CA Root [Root] (Exp: May 30, 2020)
USERTrust RSA Certification Authority [Intermediate 2] (Exp: May 30, 2020)
InCommon RSA Server CA [Intermediate 1] (Exp: Oct 5, 2024)
End Entity [Leaf Certificate]

Trust Chain B
USERTrust RSA Certification Authority [Root] (Exp: Jan 18, 2038)
InCommon RSA Server CA [Intermediate 1] (Exp: Oct 5, 2024)
End Entity [Leaf Certificate]

Trust Chain C
AAA Certificate Services [Root] (Exp: Dec 31, 2028)
USERTrust RSA Certification Authority [Intermediate 2] (Exp: Dec 31, 2028)
InCommon RSA Server CA [Intermediate 1] (Exp: Oct 5, 2024)
End Entity [Leaf Certificate]

WHAT YOU NEED TO DO

We strongly encourage decommissioning these legacy devices if their software cannot be upgraded. Non-upgraded, legacy devices should never be exposed to the Internet and special mitigations should be applied to isolate them from neighbor systems. Legacy compatibility may be extended by reconfiguring servers to send Trust Chain C (see above). Contact your server admins to discuss whether that is possible.

Reconfigure the server to send Trust Chain B or Trust Chain C and reconfigure the client to use the operating system managed truststore. Click the link for additional configuration information.

Client software that use OpenSSL libraries prior to version 1.1.1 for certificate path validation appear to always validate the full Trust Chain A sent from the server even though modern roots were configured to validate Trust Chain B.

This unfortunate behavior was observed on Red Hat Enterprise Linux 6 (OpenSSL 1.0.1e-fips) and 7 (OpenSSL 1.0.2k-fips). On our test devices, advancing the clock past June 1, 2020 and attempting connections to servers that sent Trust Chain A resulted in failed connections. In these tests, OpenSSL returned expired certificate errors even though Trust Chain B’s root was available in the truststores. This behavior appears to be fixed in Red Hat Enterprise Linux 8 (OpenSSL 1.1.1c FIPS) and Ubuntu 14.04 (OpenSSL 1.1.1) as the same clock advancing tests resulted in successful connections and OpenSSL validating properly to Trust Chain B’s root.

To workaround this unfortunate behavior, configure the server to send Trust Chain B or Trust Chain C and configure the clients to use the operating system managed truststore or explicitly trust either the USERTrust RSA Certification Authority root or AAA Certificate Services root (depending on what the server sends).

Examples of client programs that use OpenSSL for certificate path validation and were tested include OpenLDAP and postfix.

OpenLDAP clients on Red Hat Enterprise Linux 6 and 7 appear to always validate the full Trust Chain A sent from the server even though modern roots were configured to validate Trust Chain B. Once the client device clock was advanced to June 1, 2020, LDAPS connections failed validation on the expired AddTrust root until our test server was reconfigured to send either Trust Chain B or Trust Chain C.

OpenLDAP clients only enable TLS when either TLS_CACERT or TLS_CACERTDIR is set in ldap.conf. Either set TLS_CACERT to be the operating system managed PEM file or set TLS_CACERTDIR to an empty directory to force fallback to the operating system managed truststore.

ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

Configure the server to send Trust Chain B or Trust Chain C and configure the clients to use the operating system managed truststore or explicitly trust either the USERTrust RSA Certification Authority root or AAA Certificate Services root (depending on what the server sends).

See Condition 3 below for client configuration details.

Reconfigure the client to use the operating system or vendor managed truststore if possible. If not, reconfigure the client to explicitly trust either the USERTrust RSA Certification Authority root or AAA Certificate Services root (depending on what the server sends). Click the links for additional configuration information.

See vendor documentation for more information.

ldap.cmu.edu and ldap.andrew.cmu.edu were reconfigured to send Trust Chain C on Wednesday, May 27, 2020 at 11:00 AM. Please reconfigure your OpenLDAP clients to use the operating system managed truststore if you are experiencing query failures.

Downloads

* When configuring the trust chain sent by a server, only the intermediate(s) and end entity certificates are required. Sending the root certificate is optional as the client must already have the root in its truststore. Please use the «Intermediate» or «Intermediates» downloads above instead of the «Root/Intermediate(s) only» or «Intermediate(s)/Root only» links in the InCommon (Sectigo) Enrollment Successful emails.

Testing

Print the PEM encoded trust chain certificates

MORE INFORMATION

CONTACT

Please direct any questions or feedback to the Carnegie Mellon Certificate Authority (certificate-authority@andrew.cmu.edu)

Support Contact

Documentation

Revision History

Information Security Office
Computing Services
5000 Forbes Avenue Pittsburgh, PA 15213
Office: (412) 268-2044 | Support: (412) 268-4357

Источник

Поделиться с друзьями
Советы экспертов и специалистов
Adblock
detector