Все root ca x3 сертификат скачать

От корневых сертификатов в системе может зависеть правильная работа при обращении к ресурсам, которые работают по зашифрованному каналу связи. Если данные сертификаты устареют, мы можем столкнуться с рядом проблем:

• Не открываются или выдают предупреждение безопасности некоторые (или все) сайты, работающие по https.
• Некорректная работа отдельных приложений.
• Ошибки при подключении по ssh.

Установка пакета из репозитория
Установка загруженного пакета
Ручная настройка
Пример ручной настройки корневого сертификата от Let’s Encrypt
Дополнительные ссылки

Это пример ошибок, который не претендует на свою полному. Чаще всего, проблемы встречаются на системах, снятых с обслуживания.

Установка из репозитория

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

а) для систем на базе DEB (Debian, Ubuntu, Mint):

apt install ca-certificates

б) для систем на базе RPM (Rocky Linux, CentOS):

yum install ca-certificates

Если нам повезет и в репозитории будут обновленные корневые центры, наша работа закончена. Иначе, устанавливаем сертификаты вручную.

Загрузка пакета с сертификатами

Установка из репозитория может не дать нужного эффекта, если в нем находятся не самые свежие сертификаты или наша система сильно устарела или не имеет выхода в Интернет.

В этом случае нам нужно загрузить пакет с корневыми сертификатами вручную. Разберем пример на системе Ubuntu. В официальном репозитории или в поисковой системе находим пакет для загрузки, например, по ссылке ftp.ru.debian.org/debian/pool/main/c/ca-certificates копируем ссылку на файл с последней версией сертификатов, и загружаем его на наш компьютер:

Полученный пакет устанавливаем в системе:

dpkg -i ca-certificates_*_all.deb

И обновляем корневые сертификаты:

Установка вручную

Выше рассмотрены самые удобные способы обновления корневых сертификатов. Но если у нас есть сертификат без пакета, то нам его нужно будет установить вручную.

Принцип данной установки сводится к двум шагам:

1. Положит файл с сертификатом в определенный каталог.
2. Запустить команду для импорта сертификата.

В зависимости от типа Linux, действия будут отличаться.

а) Для Deb (Debian / Ubuntu / Astra Linux)

б) Для RPM (Rocky Linux / РЕД ОС)

Копируем файл в каталог /etc/pki/ca-trust/source/anchors:

cp /foo/bar/cert.crt /etc/pki/ca-trust/source/anchors/

Ручная установка Let’s Encrypt

Мы можем столкнуться с ситуацией, когда в предоставляемых официальных пакетах не окажется обновленного сертификата. Например, на момент написания данной инструкции у систем на базе Deb не оказалось нового сертификата для Let’s Encrypt, а старый закончил свое действие 30 сентября 2021 года.

В данном случае, мы можем установить любой нужный нам сертификат руками. Для этого скачала находим его и копируем — приведем пример с Let’s Encrypt. На странице letsencrypt.org/ru/certificates мы можем увидеть ссылки на корневые сертификаты. Допустим, нам нужен Let’s Encrypt Authority X3 (Signed by ISRG Root X1), который доступен по ссылке letsencrypt.org/certs/letsencryptauthorityx3.pem.txt. Копируем последовательность и создаем файл на компьютере:

——BEGIN CERTIFICATE——
MIIFjTCCA3WgAwIBAgIRANOxciY0IzLc9AUoUSrsnGowDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTYxMDA2MTU0MzU1
WhcNMjExMDA2MTU0MzU1WjBKMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDEjMCEGA1UEAxMaTGV0J3MgRW5jcnlwdCBBdXRob3JpdHkgWDMwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc0wzwWuUuR7dyXTeDs2hjMOrX
NSYZJeG9vjXxcJIvt7hLQQWrqZ41CFjssSrEaIcLo+N15Obzp2JxunmBYB/XkZqf
89B4Z3HIaQ6Vkc/+5pnpYDxIzH7KTXcSJJ1HG1rrueweNwAcnKx7pwXqzkrrvUHl
Npi5y/1tPJZo3yMqQpAMhnRnyH+lmrhSYRQTP2XpgofL2/oOVvaGifOFP5eGr7Dc
Gu9rDZUWfcQroGWymQQ2dYBrrErzG5BJeC+ilk8qICUpBMZ0wNAxzY8xOJUWuqgz
uEPxsR/DMH+ieTETPS02+OP88jNquTkxxa/EjQ0dZBYzqvqEKbbUC8DYfcOTAgMB
AAGjggFnMIIBYzAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADBU
BgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEBATAwMC4GCCsGAQUFBwIB
FiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQub3JnMB0GA1UdDgQWBBSo
SmpjBH3duubRObemRWXv86jsoTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js
LnJvb3QteDEubGV0c2VuY3J5cHQub3JnMHIGCCsGAQUFBwEBBGYwZDAwBggrBgEF
BQcwAYYkaHR0cDovL29jc3Aucm9vdC14MS5sZXRzZW5jcnlwdC5vcmcvMDAGCCsG
AQUFBzAChiRodHRwOi8vY2VydC5yb290LXgxLmxldHNlbmNyeXB0Lm9yZy8wHwYD
VR0jBBgwFoAUebRZ5nu25eQBc4AIiMgaWPbpm24wDQYJKoZIhvcNAQELBQADggIB
ABnPdSA0LTqmRf/Q1eaM2jLonG4bQdEnqOJQ8nCqxOeTRrToEKtwT++36gTSlBGx
A/5dut82jJQ2jxN8RI8L9QFXrWi4xXnA2EqA10yjHiR6H9cj6MFiOnb5In1eWsRM
UM2v3e9tNsCAgBukPHAg1lQh07rvFKm/Bz9BCjaxorALINUfZ9DD64j2igLIxle2
DPxW8dI/F2loHMjXZjqG8RkqZUdoxtID5+90FgsGIfkMpqgRS05f4zPbCEHqCXl1
eO5HyELTgcVlLXXQDgAWnRzut1hFJeczY1tjQQno6f6s+nMydLN26WuU4s3UYvOu
OsUxRlJu7TSRHqDC3lSE5XggVkzdaPkuKGQbGpny+01/47hfXXNB7HntWNZ6N2Vw
p7G6OfY+YQrZwIaQmhrIqJZuigsrbe3W+gdn5ykE9+Ky0VgVUsfxo52mwFYs1JKY
2PGDuWx8M6DlS6qQkvHaRUo0FMd8TsSlbF0/v965qGFKhSDeQoMpYnwcmQilRh/0
ayLThlHLN81gSkJjVrPI0Y8xCVPB4twb1PFUd2fPM3sA1tJ83sZ5v8vgFv2yofKR
PB0t6JzUA81mSqM3kxl5e+IZwhYAyO0OTg3/fs8HqGTNKd9BqoUwSRBzp06JMg5b
rUCGwbCUDI0mxadJ3Bz4WxR6fyNpBK2yAinWEsikxqEt
——END CERTIFICATE——

Открываем на редактирование файл:

И добавляем в него строку с указанием на созданный файл:

Но в моем случае был прописан также файл с устаревшим сертификатом — указание на него нужно закомментировать:

После чего обновить сертификаты:

* опция fresh позволит не только добавить, но и удалить всего того, что нет в конфигурационном файле. Для нас это необходимо, чтобы убрать устаревший сертификат.

Мы должны увидеть что-то на подобие:

Читайте также

Также может быть полезным:

1. Ручное обновление корневых сертификатов на Windows.

2. Получение бесплатного SSL сертификата Let’s Encrypt.

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, который признается большинством систем:

К настоящему моменту корневой сертификат 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.

Если всё в порядке, 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 в числе доверенных: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows

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

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

После выполнения этой последовательности шагов, сертификат должен появиться в защищенном хранилище. Чтобы проверить это, нужно нажать комбинацию клавиш «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: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

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

Чтобы браузер мог аутентифицировать веб-сайт, тот представляет себя действительной цепочкой сертификатов. Типичная цепочка показана сверху, в ней может быть больше одного промежуточного сертификата. Минимальное количество сертификатов в действительной цепочке равно трём.

Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве. Его не поменяешь со стороны сервера. Нужно принудительное обновление ОС или встроенного ПО на устройстве.

Специалист по безопасности Скотт Хельме (Scott Helme) пишет, что основные проблемы возникнут у центра сертификации Let’s Encrypt, потому что сегодня это самый популярный ЦС в интернете, а его корневой сертификат скоро «протухнет». Смена корня Let’s Encrypt назначена на 8 июля 2020 года.

Конечные и промежуточные сертификаты удостоверяющего центра (CA) доставляются клиенту с сервера, а корневой сертификат у клиента уже есть, поэтому с помощью этой коллекции сертификатов можно построить цепочку и аутентифицировать веб-сайт.

Проблема заключается в том, что у каждого сертификата есть срок действия, после чего он нуждается в замене. Например, с 1 сентября 2020 года в браузере Safari планируют ввести ограничение на срок действия серверных TLS-сертификатов максимум 398 дней.

Это значит, что всем нам придётся заменять серверные сертификаты по крайней мере каждые 12 месяцев. Это ограничение распространяется только на сертификаты сервера, оно не распространяется на корневые сертификаты CA.

Сертификаты CA регулируются другим набором правил, поэтому имеют разные ограничения на срок действия. Очень часто встречаются промежуточные сертификаты со сроком действия 5 лет и корневые сертификаты со сроком службы даже 25 лет!

С промежуточными сертификатами обычно нет проблем, потому что они поставляются клиенту сервером, который сам гораздо чаще меняет свой собственный сертификат, так что просто в ходе этой процедуры заменяет и промежуточный. Его довольно легко заменить вместе с сертификатом сервера, в отличие от корневого сертификата CA.

Как мы уже говорили, корневой CA встроен непосредственно в само клиентское устройство, в ОС, в браузер или другое программное обеспечение. Изменение корневого CA веб-сайт не может контролировать. Здесь требуется обновление на клиенте, будь то обновление ОС или софта.

Некоторые корневые CA существуют уже очень давно, речь о 20-25 годах. Скоро некоторые из самых старых корневых CA приблизятся к концу своей естественной жизни, их время почти истекло. Для большинства из нас это вообще не будет проблемой, потому что CA создали новые корневые сертификаты, и они уже много лет распространяются по всему миру в обновлениях ОС и браузеров. Но если кто-то очень давно не обновлял ОС или браузер, это своего рода проблема.

Такая ситуация возникла 30 мая 2020 года в 10:48:38 GMT. Это точное время, когда протух корневой сертификат AddTrust от центра сертификации Comodo (Sectigo).

К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.

Следующий — Let’s Encrypt

Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё в апреле 2019 года они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого не произошло.

«Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2019 года на 8 июля 2020 года», — сказано в официальном сообщении Let’s Encrypt.

Дату пришлось перенести из-за проблемы, которую называют «распространением корня» (root propagation), а точнее, отсутствием распространения корня, когда корневой CA не слишком широко распространён на всех клиентах.

Сейчас Let’s Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let’s Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1.

Корень ISRG выпущен 4 июня 2015 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2018 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.

Но в этом и проблема.

Если ваш мобильный телефон, телевизор или другое устройство не обновлялось два года — как оно узнает о новом корневом сертификате ISRG Root X1? А если его не установить в системе, то все серверные сертификаты Let’s Encrypt ваше устройство признает недействительными, как только Let’s Encrypt перейдёт на новый корень. А в экосистеме Android много устаревших устройств, которые давно не обновлялись.

Вот почему Let’s Encrypt отложил переход к собственному корню ISRG и всё ещё использует промежуточное звено, которое спускается к корню IdenTrust. Но переход в любом случае придётся сделать. И датой смены корня назначено 8 июля 2020 года.

Для проверки, что на вашем устройстве (телевизор, приставка или другой клиент) установлен корень ISRG X1, откройте тестовый сайт https://valid-isrgrootx1.letsencrypt.org/. Если не появляется предупреждение безопасности, то обычно всё в порядке.

Let’s Encrypt не единственный, кому предстоит решить проблему с переходом на новый корень. Криптографию в интернете начали использовать чуть более 20 лет назад, так что как раз сейчас наступает момент окончания действия многих корневых сертификатов.

С такой проблемой могут столкнуться владельцы умных телевизоров, которые много лет не обновляли программное обеспечение Smart TV. Например, новый корень GlobalSign R5 Root выпущен в 2012 году, и после некоторые старые Smart TV не могут построить цепочку к нему, потому что этот корневой CA у них просто отсутствует. В частности, эти клиенты не могли установить защищённое соединение с сайтом bbc.co.uk. Чтобы решить проблему, админам BBC пришлось пойти на хитрость: они построили для этих клиентов альтернативную цепочку через дополнительные промежуточные сертификаты, задействуя старые корни R3 Root и R1 Root, которые ещё не протухли.

www.bbc.co.uk (Leaf)
GlobalSign ECC OV SSL CA 2018 (Intermediate)
GlobalSign Root CA - R5 (Intermediate)
GlobalSign Root CA - R3 (Intermediate)

Это временное решение. Проблема никуда не уйдёт, если не обновить клиентское ПО. Умный телевизор — это по сути ограниченный в функциональности компьютер под Linux. И без обновлений его корневые сертификаты неизбежно протухнут.

Это касается всех устройств, не только телевизоров. Если у вас любое устройство, которое подключено к интернету и которое рекламировали как «умный» девайс, то проблема с протухшими сертификатами почти наверняка касается его. Если устройство не обновляется, то корневое хранилище CA со временем устареет, и в конечном итоге проблема всплывёт на поверхность. Как скоро возникнет проблема, зависит от времени последнего обновления корневого хранилища. Это может быть за несколько лет до даты реального выпуска устройства.

Кстати, в этом проблема, почему некоторые крупные медиаплатформы не могут использовать современные автоматизированные центры сертификации типа Let’s Encrypt, пишет Скотт Хельме. Для умных ТВ они не подходят, и количество корней слишком мало, чтобы гарантировать поддержку сертификата на устаревших устройствах. В противном случае ТВ просто не сможет запустить современные стриминговые сервисы.

Последний инцидент с AddTrust показал, что даже крупные IT-компании бывают не готовы к тому, что у корневого сертификата заканчивается срок действия.

Решение проблемы только одно — обновление. Разработчики умных устройств должны заранее обеспечить механизм обновления программного обеспечения и корневых сертификатов. С другой стороны, производителям невыгодно обеспечивать работу своих устройств по окончании срока гарантии.

Одна из санкций, которая досталась России, — запрет на выдачу и продление SSL-сертификатов. Это приводит к тому, что у некоторых компаний сертификат может протухнуть и сайты перестанут открываться.

Основных решений два:

1. Использовать российский Яндекс.Браузер или Атом.

2. Поставить на компьютер сертификат или профиль от Минцифры.

Для мобильных приложений это превращается в особую проблему — могут перестать проходить платежи разных эквайрингов.

Например, 15 февраля 2023 года у Сбера истечёт действие сертификата и надо переходить на самоподписанный. Если этого не сделать, то эквайринг через Сбер может перестать работать. SberPay будет работать как и раньше.

В статье покажу, что делать разработчикам приложений, чтобы экраны c 3-D Secure открывались и эквайринг продолжал работу.

Info. plist

На уровне конфигурации проекта ничего менять не нужно. Скорее всего, у вас уже стоит флаг NSAllowsArbitraryLoadsInWebContent в Info.plist: он нужен, чтобы вообще уметь хоть что-то грузить в WKWebView.

<key>NSAppTransportSecurity</key>
<dict> <key>NSAllowsArbitraryLoadsInWebContent</key> <true/>
</dict>

На ревью Apple спросит, зачем это вам — расскажите про 3-D Secure.

Подставляем правильный сертификат

Сертификаты берём отсюда https://www.gosuslugi.ru/crt. Нам понадобится сертификат для macOS в .pem формате.

Увы, это страница для пользователей, а не для разработчиков, поэтому сертификаты придётся привести в другой вид. Важно, что сертификатов два: Russian Trusted Root CA и Russian Trusted Sub CA. Нужны оба.

Чтобы получить их, можно взять .pem файл, разделить его на два и сконвертировать каждый в .der, потому что iOS только с .der умеет работать.

openssl x509 -outform der -in certificate1.pem -out certificate1.der

Если вы почему-то доверяете мне, а не Минцифре, то можете сразу взять готовые:

Russian Trusted Sub CA.der

Russian Trusted Root CA.der

Добавляйте их в проект, линкуйте так, чтобы они попал в бандл.

Дополнительная проверка сертификата

Если экран не проходит стандартную валидацию сертификатом, зашитым в операционную систему, то в делегате WKWebView вызывается дополнительная проверка подключения. По документации мы должны спросить у пользователя, стоит ли открывать эту страницу или как-то иначе проверить безопасность подключения. Будем разрешать подключение после проверки сертификата от Минцифры.

Поймаем провалившуюся проверку. В челлендже есть serverTrust-объект, по которому мы должны принять решение. Если валидация не прошла, то возвращаемся к дефолтному поведению через .performDefaultHandling

extension ViewController: WKNavigationDelegate { func webView( _ webView: WKWebView, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void ) { guard let serverTrust = challenge.protectionSpace.serverTrust else { return completionHandler(.performDefaultHandling, nil) } Task.detached(priority: .userInitiated) { if await self.validator.checkValidity(of: serverTrust) { // Allow our sertificate let cred = URLCredential(trust: serverTrust) completionHandler(.useCredential, cred) } else { // Default check for another connections completionHandler(.performDefaultHandling, nil) } } }
}

Всю работу с сертификатами спрячем в валидатор. Вся работа должна быть в отдельном потоке, поэтому весь код обёрнут в актор для синхронизации значений внутри него. В примере много специфичного кода из фреймворка Security, но его документация все объясняет очень подробно.

actor CertificateValidator { var certificates = [SecCertificate]() func prepareCertificates(_ names: [String]) { certificates = names.compactMap(certificate(name:)) } private func certificate(name: String) -> SecCertificate? { let path = Bundle.main.url(forResource: name, withExtension: "der") let certData = try! Data(contentsOf: path!) let certificate = SecCertificateCreateWithData(nil, certData as CFData) return certificate } func checkValidity(of serverTrust: SecTrust, anchorCertificatesOnly: Bool = false) -> Bool { SecTrustSetAnchorCertificates(serverTrust, certificates as CFArray) SecTrustSetAnchorCertificatesOnly(serverTrust, anchorCertificatesOnly) var error: CFError? let isTrusted = SecTrustEvaluateWithError(serverTrust, &error) return isTrusted }
}

Ну и вызовем загрузку сертификатов во viewDidLoad:

class ViewController: UIViewController { let validator = CertificateValidator() override func viewDidLoad() { super.viewDidLoad() Task { let names = ["Russian Trusted Root CA", "Russian Trusted Sub CA"] await validator.prepareCertificates(names) } let url = URL(string: "https://3dsecmt.sberbank.ru/payment/se/keys.do")! webView.navigationDelegate = self webView.load(URLRequest(url: url)) } @IBOutlet weak var webView: WKWebView!
}

Полный пример вы можете посмотреть в GitHub. Запускайте проект, сайт должен открыться.

В статье я показал самый простой пример, чтобы была понятна суть, но в руководстве от Сбера вы можете найти полный текст с дополнительными проверками.g

Вопросы

Как это сделать на Andriod?

Посмотрите инструкцию от Сбера

Будут ли проблемы у других банков?

Рано или поздно. Решение прогоняет все запросы через сертификат Минцифры, поэтому должно быть массовым решением.

Что будет с эквайрингами в других странах?

Если мы не прошли проверку по сертификату Минцифры, то передаём контроль поведению по умолчанию, что позволит грузиться и иностранным эквайрингам.

Как это решение влияет на PCI DSS?

Никак не должно влиять, потому что NSAllowsArbitraryLoadsInWebContent и так стоял, а других решений для России нет пока.

Когда надо обновлять сертификат?

Через 5 лет истекает самый короткоживущий. Заведите себе напоминание обновить за год, тогда большинство пользователей бесшовно обновится. Мы себе написали unit-тест который упадет за год до истечения срока сертификата.

Сертификат Минцифры безопасен?

По сути, вы передаёте возможность читать ваш трафик государству. Подходит вам это или нет — решайте сами, у всех разные ситуации. Можно отдать это на откуп пользователям, чтобы они сами поставили нужный профиль, но большинство из них просто не поймут проблему и способ решения, так как столкнутся с этим впервые.

Вижу в логах текст [Security] This method should not be called on the main thread as it may lead to UI unresponsiveness.

Вся работа с фреймворком Security должна быть в фоновом потоке, но видимо где-то в WKWebView это нарушено.

У меня эквайринг подключен через SDK и я не могу поменять код, что делать?

Скорее всего последняя версия SDK уже содержит это исправление. Уточните у своего экваера.

Есть ли решение для UIWebView?

Я такого не нашел

Если понравилась статья и хочешь больше узнать о разработке приложений Dodo Brands, подписывайся на наш канал Dodo Mobile.

Последнее обновление: 2 окт. 2021 г.

Корневые сертификаты

Наши корневые сертификаты хранятся в надёжном месте и недоступны онлайн. Мы выпускаем сертификаты для пользователей на основе промежуточных сертификатов из следующего раздела. Для дополнительной совместимости с новым Root X2 с различными корневыми хранилищами, мы также подписали его с Root X1.

• Активные
  • ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
    • Самоподписанный: der, pem, txt
    • Кросс подписанный DST Root CA X3: der, pem, txt
• Действующий, с ограничениями
  • ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
    • Самоподписанный: der, pem, txt
    • Кросс-подписанный ISRG Root X1: der, pem, txt

Мы создали сайты для проверки цепочки сертификатов вплоть до активных корневых.

Промежуточные сертификаты

Как правило, сертификаты, выпущенные Let’s Encrypt, создаются на основе “R3”, промежуточного RSA. В настоящее время выпуск сертификатов из “E1”, промежуточного ECDSA-сертификата, возможен только для ключей ECDSA из разрешенных аккаунтов. В будущем выпуск сертификатов из “Е1” будет доступен для всех.

Дополнительные промежуточные сертификаты (“R4” и “E2”) зарезервированы для восстановления после стихийных бедствий, и будут использованы только в том случае, если мы потеряем доступ к нашими основным межуточным сертификатам. Мы больше не используем промежуточные сертификаты X1, X2, X3 и X4.

IdenTrust кросс-подписал наши промежуточные сертификаты RSA для дополнительной совместимости.

Промежуточные сертификаты

Каждый из наших промежуточных сертификатов представляет собой одну публичную/частную ключевую пару. Это позволяет всем основным браузерам принимать наши сертификаты с нашим же корневым сертификатом.

Кросс-подпись означает, что каждый из наших промежуточных сертификатов имеет два сертификата, представляющих один и тот же ключ подписи. Один подписан DST Root CA X3, другой подписан ISRG Root X1. Самый простой способ отличить их — посмотреть на поле “Issuer” (издатель).

При настройке web-сервера, администратор указывает не только листовые сертификаты, но и список промежуточных сертификатов. Это помогает браузеру проверить, входит ли листовой сертификат в цепочку доверия, ведущую к корневому сертификату. Почти все операторы серверов будут выбирать для обслуживания цепочку, включающую промежуточный сертификат с субъектом “R3” и издателем “ISRG Root X1”. Рекомендуемое клиентское программное обеспечение Let’s Encrypt, Certbot, выполнит эту задачу без затруднений.

Корневые сертификаты

Как и промежуточные сертификаты, корневые сертификаты могут быть кросс-подписаны, часто для увеличения клиентской совместимости. Наш корневой ECDSA-сертификат, ISRG Root X2 был создан осенью 2020 года и является корневым сертификатом для иерархии ECDSA. Он представлен двумя сертификатами: самоподписанным и подписанным ISRG Root X1.

Все сертификаты, подписанные промежуточным ECDSA-сертификатом “E1”, будут иметь цепочку с промежуточным сертификатом, у которого субъект “ISRG Root X2”, а издатель “ISRG Root X1”. Почти все сервера выберут для обслуживания эту цепочку, поскольку она обеспечивает наибольшую совместимость до тех пор, пока ISRG Root X2 не получит широкого доверия.

Сертификат подписания ответов OCSP

Этот сертификат используется для подписания ответов OCSP для промежуточных Центров Сертификации Let’s Encrypt. Таким образом нам не нужно иметь онлайне-доступ к корневому сертификату, чтобы подписать эти ответы. Копия сертификата подписания включена в ответ OCSP для информирования, дополнительно пользователям ничего делать не нужно.

• ISRG Root OCSP X1 ([Подписанный ISRG Root X1](https://crt. sh/? id=2929281974)): [der](/certs/isrg-root-ocsp-x1. der), [pem](/certs/isrg-root-ocsp-x1. pem), [txt](/certs/isrg-root-ocsp-x1. txt)

У наших новых промежуточных сертификатов нет OCSP URL-адресов (их информация об отзыве вместо этого используется CRL), поэтому мы не выпустили сертификат подписи OCSP от ISRG Root X2.

Прозрачность сертификата

В Let’s Encrypt мы в нацелены на прозрачность в наших процессах и в сертификатах, которые выпускаем. Мы записываем сертификаты в журнал Certificate Transparency сразу, как только выпускаем их. Все наши сертификаты доступны по ссылкам:

Root Certificates

Our roots are kept safely offline. We issue end-entity certificates to subscribers from the intermediates in the next section.
For additional compatibility as we submit our new Root X2 to various root programs, we have also cross-signed it from Root X1.

• Active
  • ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
    • Self-signed: der, pem, txt
    • Cross-signed by DST Root CA X3: der, pem, txt
• Active, limited availability
  • ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
    • Self-signed: der, pem, txt
    • Cross-signed by ISRG Root X1: der, pem, txt

We’ve set up websites to test certificates chaining to our active roots.

Under normal circumstances, certificates issued by Let’s Encrypt will come from “R3”, an RSA intermediate.
Currently, issuance from “E1”, an ECDSA intermediate, is possible only for ECDSA subscriber keys for allowlisted accounts. In the future, issuance from “E1” will be available for everyone.

Our other intermediates (“R4” and “E2”) are reserved for disaster recovery and will only be used should we lose the ability to issue with our primary intermediates.
We do not use the X1, X2, X3, and X4 intermediates anymore.

IdenTrust has cross-signed our RSA intermediates for additional compatibility.

Cross Signing

Each of our intermediates represents a single public/private
key pair. The private key of that pair generates the signature for all end-entity
certificates (also known as leaf certificates), i.e. the certificates we issue
for use on your server.

Our RSA intermediates are signed by ISRG Root X1. ISRG Root X1 is widely trusted at this
point, but our RSA intermediates are still cross-signed by IdenTrust’s “DST Root CA X3”
(now called “TrustID X3 Root”) for additional client compatibility. The IdenTrust
root has been around longer and thus has better compatibility with older devices
and operating systems (e.g. Windows XP, Android 7). You can download “TrustID X3 Root” from
IdenTrust (or, alternatively,
you can download a copy from us).

Having cross-signatures means that each of our RSA intermediates has two
certificates representing the same signing key. One is signed by DST Root
CA X3 and the other is signed by ISRG Root X1. The easiest way to distinguish
the two is by looking at their Issuer field.

When configuring a web server, the server operator configures not only the
end-entity certificate, but also a list of intermediates to help browsers verify
that the end-entity certificate has a trust chain leading to a trusted root
certificate. Almost all server operators will choose to serve a chain including
the intermediate certificate with Subject “R3” and
Issuer “ISRG Root X1”. The recommended Let’s Encrypt client software,
Certbot, will make this configuration seamlessly.

Roots

Similar to intermediates, root certificates can be cross-signed, often to increase client
compatibility. Our ECDSA root, ISRG Root X2 was generated in fall 2020 and is the root
certificate for the ECDSA hierarchy. It is represented by two certificates: one that is
self-signed and one that is signed by ISRG Root X1.

All certificates signed by the ECDSA intermediate “E1” will come with a chain including an intermediate
certificate whose Subject is “ISRG Root X2” and whose Issuer is “ISRG Root X1”. Almost all server operators
will choose to serve this chain as it offers the most compatibility until ISRG Root X2
is widely trusted.

OCSP Signing Certificate

This certificate is used to sign OCSP responses for the Let’s Encrypt Authority
intermediates, so that we don’t need to bring the root key online in order to
sign those responses. A copy of this certificate is included automatically in
those OCSP responses, so Subscribers don’t need to do anything with it. It is
included here for informational purposes only.

• ISRG Root OCSP X1 (Signed by ISRG Root X1): der, pem, txt

Our newer intermediates do not have OCSP URLs (their revocation information is
instead served via CRL), so we have not issued an OCSP Signing Cert from ISRG Root X2.

Certificate Transparency

We are dedicated to transparency in our operations and in the certificates we
issue. We submit all certificates to Certificate Transparency
logs as we issue them. You can view all
issued Let’s Encrypt certificates via these links:

Внимание! Английская версия сайта была обновлена, перевод неактуален
(30 сент. 2021 г.)
Просмотреть на английском

30 сентября 2021 года произойдет небольшое изменение в вопросе того, как старые браузеры и устройства доверяют сертификатам Let’s Encrypt. Если у вас обычный веб-сайт, то вы не заметите разницы — подавляющее большинство ваших посетителей все равно примут ваш сертификат Let’s Encrypt. Если вы предоставляете API или должны поддерживать устройства IoT, вам, возможно, придется уделить немного больше внимания этому изменению.

У Let’s Encrypt есть “корневой сертификат” под названием ISRG Root X1. Современные браузеры и устройства доверяют сертификату Let’s Encrypt, установленному на вашем веб-сайте, поскольку ISRG Root X1 включен в их список корневых сертификатов. Чтобы сертификаты, которые мы выпускаем, являлись доверенными на старых устройствах, у нас также есть “перекрестная подпись” из старого корневого сертификата: DST Root CA X3.

Когда мы только начинали, этот старый корневой сертификат (DST Root CA X3) помог нам сдвинуться с мертвой точки и сразу получить доверие практически каждого устройства. Более новый корневой сертификат (ISRG Root X1) теперь также широко пользуется доверием, но некоторые старые устройства никогда не будут доверять ему, потому что они не получают обновлений программного обеспечения (например, iPhone 4 или HTC Dream). Нажмите здесь, чтобы узнать, какие платформы доверяют ISRG Root X1.

Срок действия DST Root CA X3 истекает 30 сентября 2021 г. Это означает, что те старые устройства, которые не доверяют ISRG Root X1, начнут получать предупреждения о сертификате, при посещении сайтов, использующих сертификаты Let’s Encrypt. Есть важное исключение: старые Android-устройства, не доверяющие ISRG Root X1, продолжат работу с Let’s Encrypt благодаря специальной кросс-подписи DST Root CA X3, которая распространится после истечения срока действия этого корневого сертификата. Это исключение работает только для Android.

Что вам делать? Для большинства людей ничего! Мы настроили выдачу сертификатов таким образом, чтобы ваш веб-сайт в большинстве случаев работал правильно, обеспечивая широкую совместимость. Если вы предоставляете API или должны поддерживать устройства IoT, вам нужно убедиться в двух вещах: (1) все клиенты вашего API должны доверять ISRG Root X1 (а не только DST Root CA X3), и (2) если клиенты вашего API используют OpenSSL, они должны использовать версию 1.0 или новее. В OpenSSL 1.0.x загвоздка при проверке сертификата в том, что даже клиенты, которые доверяют ISRG Root X1, потерпят неудачу при представлении совместимой с Android цепочки сертификатов, которую мы рекомендуем по умолчанию.

Если вам нужна дополнительная информация о текущих изменениях нашей производственной цепочки, пожалуйста, посмотрите эту тему на нашем форуме.

Если у вас есть вопросы о предстоящем окончании срока действия, пожалуйста, напишите в эту тему на нашем форуме.

Привет, Хабр! С вами Екатерина, React Native разработчик.

Осенью 2022 года “Сбер” объявил о переводе всех своих ресурсов на работу с применением российских сертификатов от Минцифры (ссылка на новость). Это изменение затрагивало сервис онлайн-оплаты, поэтому при планировании одного из недавних спринтов я ожидаемо увидела в своем беклоге задачу по внедрению сертификатов в мобильное приложение.

О сертификатах

Изначальной причиной перехода на российские сертификаты является то, что зарубежные компании начали отзывать сертификаты безопасности у российских сайтов. После этого МинЦифры выпустило свои собственные российские сертификаты и рекомендовало перейти на их использование. Крупные российские компании уже начали переходить на новый стандарт, и “Сбер” оказался одной из первых таких компаний.

У “Сбера” есть официальная документация для подключения сертификатов https://securepayments.sberbank.ru/wiki/doku.php/certificates:start. 

В документации есть инструкции по внедрению сертификатов на многие популярные платформы. Однако, инструкции для React Native приложений нет, поэтому мы искали решение самостоятельно.

Android

• russian_trusted_root_ca.cer — корневой;

• russian_trusted_sub_ca.cer — выпускающий.

Для простоты их можно переименовать в root.cer и sub.cer соответственно.

После этого, перемещаем скачанные файлы в папку project_name/android/src/res/raw. Далее нужно создать файл network_security_config.xml со следующим содержанием:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config> <domain-config> <domain includeSubdomains="true">3dsecmt.sberbank.ru</domain> //домен можно не указывать, тогда сертификаты будут работать для любых доменов <trust-anchors> <certificates src="@raw/root"/> <certificates src="@raw/sub"
/> </trust-anchors> </domain-config>
</network-security-config>

Этот файл помещаем в project_name/android/src/res/xml и на этом добавление сертификатов для Android устройств будет окончено.

IOS

Перейдем к внедрению для iOS устройств.

openssl x509 -outform der -in certificate_name.pem -out certificate_name.der

Далее создаем в проекте папку Certificates и добавляем в нее конвертированный сертификат. Заходим в настройки проекта в Xcode во вкладку Build Phase и добавляем в Cope Bundle Resource наш сертификат.

На нашем проекте мы используем библиотеку react-native-webview для отображения страницы оплаты в мобильном приложении. Мы воспользовались методом из библиотеки setCustomCertificatesForHost, который предназначен для добавления сертификатов в приложение.

Таким образом, в файле AppDelegate.m, нужно изменить метод didFinishLaunchingWithOptions. В него добавляем следующий код:

 // Get the bundle where the certificates in DER format are present. NSBundle *bundle = [NSBundle mainBundle]; NSMutableDictionary* certMap = [NSMutableDictionary new]; NSData *rootCertData = [NSData dataWithContentsOfFile:[bundle pathForResource:@"Russian Trusted Root CA" ofType:@"der"]]; SecCertificateRef certificate = SecCertificateCreateWithData(NULL, (CFDataRef) rootCertData); OSStatus err = SecItemAdd((CFDictionaryRef) [NSDictionary dictionaryWithObjectsAndKeys:(id) kSecClassCertificate, kSecClass, certificate, kSecValueRef, nil], NULL); [certMap setObject:(__bridge id _Nonnull)(certificate) forKey:@"3dsec.sberbank.ru"]; [RNCWebView setCustomCertificatesForHost:certMap];

Не забудьте изменить путь к сертификату, если у вас он отличается от приведенного.

На этом внедрение сертификатов для iOS устройств окончено.

Спасибо за внимание и желаю удачи с внедрением сертификатов в ваши приложения!