Identrust dst root ca x3 обновить на windows 7

Есть два способа решить эту проблему: либо установить новый сертификат, либо установить обновления ОС Windows.

Решение через ручную установку сертификата

Скачать сертификат можно по ссылке: https://letsencrypt.org/certs/isrgrootx1.der / зеркало (.der, 1.35Кб)

Необходимо запустить скачанный файл, на вкладке «Общие» нажать «Установить сертификат».

Выберите расположение «Локальный компьютер» и нажмите «Далее».

Выберите пункт «Поместить все сертификаты в следующее хранилище», нажмите «Обзор», выберите раздел «Доверенные корневые центры сертификации», нажмите «ОК» и «Далее», а в следующем окне – «Готово». При появлении вопросов об установке сертификатов – согласитесь на установку.

После этого перезапустите браузер и вновь попробуйте зайти на необходимый сайт.

Решение через установку обновлений

Для решения ошибки сертификата нужно установить обновления KB3020369 и KB3125574:

• KB3020369 из каталога Центра обновлений Microsoft
• KB3125574 из каталога Центра обновлений Microsoft

Дополнительно

Иногда установка одного лишь IdenTrust DST Root CA X3 может не помочь, так же рекомендуем дополнительно установить следующие корневые сертификаты:

• Go Daddy Root Certificate Authority
• GlobalSign Root CA

30 сентября 2021 14:01:15 GMT оканчивается срок действия корневого сертификата IdenTrust DST Root CA X3.

Это событие достойно вашего внимания по той причине, что после наступления этого момента ряд устаревших систем перестанут доверять сертификатам, выпущенным центром сертификации Let’s Encrypt. С учётом того, что на текущий момент Let’s Encrypt предоставляет бесплатные криптографические сертификаты примерно для 250 миллионов доменных имен, а «устаревшие системы» — это порой системы возрастом всего 5-6 лет, вряд ли окончание срока действия сертификата DST Root CA X3 пройдёт для всех гладко и незаметно. В чём причина, кого конкретно это затронет, и что можно сделать?

Немного теории и истории

Не углубляясь в детали, пару слов для неспециалистов, почему окончание срока действия сертификата DST Root CA X3 повлияет на сертификаты, выпущенные Let’s Encrypt. У каждой системы, проверяющей сертификат на валидность, есть своё хранилище доверенных корневых сертификатов. Система при проверке будет доверять сертификатам, которые подписаны с использованием закрытого ключа одного из этих корневых сертификатов. Сами корневые сертификаты как правило имеют длительные сроки действия, меняются редко и не используются при формировании сертификатов конечного субъекта (в данном случае, сертификатов для доменных имен), вместо этого инфраструктура открытых ключей, предполагает использование цепочек доверия  — корневые сертификаты применяются для подписания промежуточных сертификатов, а уже с использованием них подписываются сертификаты конечного субъекта (сертификаты для доменов). При этом, для того, чтобы система доверяла конечному сертификату, она должна быть способна проследить всю цепочку от этого сертификата до одного из корневых сертификатов, которым она доверяет. 

После появления проекта Let’s Encrypt, его корневой сертификат ISRG Root X1 (как и любой новый корневой сертификат) не мог быстро попасть в хранилища доверенных сертификатов заметного количества систем. При этом для успешного функционирования проекта выданным сертификатам с самого начала должно было доверять максимальное количество систем «из коробки» (без дополнительных действий со стороны пользователей этих систем). В связи с этим, для сертификатов Let’s Encrypt стала использоваться цепочка доверия, ведущая к корневому сертификату DST Root CA X3, который признается большинством систем:

• Windows >= XP SP3

• macOS (большинство версий)

• iOS (большинство версий)

• Android >= v2.3.6

• Mozilla Firefox >= v2.0

• Ubuntu >= precise / 12.04

• Debian >= squeeze / 6

• Java 8 >= 8u101

• Java 7 >= 7u111

• NSS >= v3.11.9

• Amazon FireOS (Silk Browser)

• Cyanogen > v10

• Jolla Sailfish OS > v1.1.2.16

• Kindle > v3.4.1

• Blackberry >= 10.3.3

• PS4 game console with firmware >= 5.00

К настоящему моменту корневой сертификат ISRG Root X1 существует уже более 5 лет и за это время попал в доверенные в большинстве современных систем, ему доверяют:

• Windows >= XP SP3 (при условии, что производилось автоматическое обновление корневых сертификатов)

• macOS >= 10.12.1

• iOS >= 10 

• Android >= 7.1.1 

• Mozilla Firefox >= 50.0

• Ubuntu >= xenial / 16.04 (с установленными обновлениями)

• Debian >= jessie / 8 (с установленными обновлениями)

• Java 8 >= 8u141

• Java 7 >= 7u151

• NSS >= 3.26

Для сертификатов Let’s Encrypt по умолчанию в данный момент предлагается такая цепочка доверия: 

IdenTrust’s DST Root CA X3 -> ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Что произойдет 30 сентября?

Срок действия DST Root CA X3 подходит к концу 30 сентября 2021 14:01:15 GMT, что произойдет после этого?

Те системы, которые не доверяют ISRG Root X1, перестанут доверять сертификатам, выпущенным Let’s encrypt (системы будут выдавать предупреждения при посещении сайтов, использующих сертификаты Let’s Encrypt). За исключением Android >= v2.3.6, т.к. Android не учитывает срок действия своих доверенных корневых сертификатов. 

Проблема с доверием возникнет также у систем, использующих OpenSSL версии меньше 1.1.0. Даже если у таких систем ISRG Root X1 входит в список доверенных сертификатов, особенность проверки сертификата в OpenSSL 1.0.x приведёт к тому, что наличие в цепочке истекшего DST Root CA X3, несмотря на наличие доверия к ISRG Root X1, будет приводить к отрицательному результату проверки на доверие. Аналогичная проблема у OpenSSL 1.0.x возникла 20 мая 2020 года с истекшим сертификатом AddTrust External CA Root.

Что со всем этим делать?

На стороне клиента

Linux

Для того, чтобы проверить, как поведёт себя ваша система при обращении к сайтам, использующим сертификаты Let’s Encrypt, после 30 сентября, можно воспользоваться утилитой faketime. В Debian и Ubuntu она доступна в пакете faketime.

faketime -f '@2021-10-01 00:00:00' curl  https://letsencrypt.org/

Если всё в порядке, curl вернёт содержимое страницы, если же нет — выдаст сообщение об ошибке:

curl: (60) server certificate verification failed.

В этом случае нужно убедиться, что:

1. Ваша система доверяет ISRG Root X1 

2. Вы не пользуетесь устаревшей версией OpenSSL

Проверка доверия к ISRG Root X1

Например, Ubuntu 16.04 xenial и Debian 8 jessie доверяют ISRG Root X1, но при этом поставляются с OpenSSL 1.0.x, поэтому проблема их может коснуться.

Чтобы проверить наличие сертификата ISRG Root X1 в числе доверенных: 

в Debian/Ubuntu: 

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep "ISRG Root X1"

в CentOS:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep "ISRG Root X1"

В выводе команды в обоих случаях должно присутствовать:

subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

Если такой строчки нет, то нужно добавить ISRG Root X1 в доверенные. В Debian/Ubuntu:

curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt | sudo tee /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt

добавить в файл /etc/ca-certificates.conf строчку:

mozilla/ISRG_Root_X1.crt

и выполнить комнаду

sudo update-ca-certificates

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

Если система доверяет ISRG Root X1, нужно проверить версию OpenSSL

openssl version

В выводе должна быть версия 1.1.0 или новее.

Если используется OpenSSL 1.0.x, то достаточным решением проблемы будет удалить из доверенных сертификат DST Root CA X3 (это решение может не сработать для openssl версий <1.0.1p и <1.0.2d). Это можно сделать, не дожидаясь 30 сентября.

В Debian/Ubuntu:

В файле /etc/ca-certificates.conf нужно найти строчку:

mozilla/DST_Root_CA_X3.crt

и поставить в начало сроки символ «!»:

!mozilla/DST_Root_CA_X3.crt

Далее, необходимо выполнить команду:

sudo update-ca-certificates

В CentOS

Выполнить команды:

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem

sudo update-ca-trust

Локальное продление срока действия сертификата DST Root CA X3

Для тех случаев, когда используется совсем старый openssl (версии меньше 1.0.1p и 1.0.2d, но новее 0.9.8m), или по иной причине не срабатывает метод с изъятием из доверенных сертификата DST Root CA X3, можно воспользоваться еще одним методом, предложенным в статье Scott’а Helme. Метод основан на том, что OpenSSL, начиная с версии 0.9.8m, не проверяет сигнатуру сертификатов, хранящихся в локальном защищенном хранилище. Таким образом, можно изменить время действия сертификата в защищенном хранилище, при этом модифицированный сертификат будет по-прежнему восприниматься OpenSSL как валидный. Для того, чтобы продлить для OpenSSL на системе срок действия сертификата DST Root CA X3 еще на три года можно выполнить следующие команды:

Debian/Ubuntu:

sudo sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" /etc/ssl/certs/DST_Root_CA_X3.pem

sudo update-ca-certificates

CentOS:

sudo sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" /etc/ssl/certs/ca-bundle.crt

sudo update-ca-trust

Не забудьте проверить так же все ваши контейнеры!!! У них свои хранилища корневых сертификатов и могут использоваться другие версии openssl

Windows

Для пользователей, у которых не подключены автоматические обновления корневых сертификатов, можно добавить сертификат ISRG Root X1 вручную. Для этого нужно скачать сертификат с сайта LetsEncrypt по ссылке https://letsencrypt.org/certs/isrgrootx1.der.

Открыть скачанный файл, в открывшемся окне выбрать «Установить сертификат…»:

В мастере импорта сертификатов выбрать «Локальный компьютер»:

Выбрать «Поместить все сертификаты в следующее хранилище», в диалоге выбора хранилища, открывающемся по кнопке «Обзор…», выбрать «Доверенные корневые центры сертификации»:

На последнем шаге мастера нажать кнопку «Готово».

После выполнения этой последовательности шагов, сертификат должен появиться в защищенном хранилище. Чтобы проверить это, нужно нажать комбинацию клавиш «Win+R», откроется диалог «Выполнить», в котором нужно ввести certmgr.msc

В открывшемся окне в подразделе «Сертификаты» раздела «Доверенные корневые центры сертификации» в списке должен появиться сертификат ISRG Root X1:

На стороне сервера 

На стороне сервера от вас мало что зависит. Если вы используете сертификаты от Let’s Encrypt на своем сервере, то должны понимать, что после 30 сентября 2021 14:01:15 GMT к вашему серверу смогут без проблем подключиться только клиенты, доверяющие ISRG Root X1 (см. список выше), а также использующие Android >= v2.3.6. При этом, если клиенты используют OpenSSL, то они должны пользоваться версией OpenSSL >= 1.1.0. 

При этом, у вас есть выбор — ценой отказа от поддержки старых Android (оставив поддержку Android >= 7.1.1), вы можете сохранить поддержку OpenSSL 1.0.x без манипуляций на стороне клиента.

Для этого нужно использовать предлагаемую Let’s Encrypt альтернативную цепочку доверия для своих сертификатов. В этой цепочке исключен DST Root CA X3 и выглядит она так: 

ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Для переключения на альтернативную цепочку нужно воспользоваться документацией вашего ACME-клиента. В частности, в certbot за возможность выбора альтернативной цепочки отвечает параметр  —preferred-chain.

Итоги

30 сентября после окончания срока действия сертификата DST Root CA X3 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let’s Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10. Кроме того, под раздачу могут попасть различные устройства IoT, старые телевизоры и подобные им устройства, для которых не существует обновлений с новыми корневыми сертификатами.

В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let’s Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.

Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

Update2: Добавил, как добавить ISRG Root X1 в доверенные сертификаты в Debian/Ubuntu, спасибо @Kenshouten

Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался

Перейти к контенту