- PVSM.RU - https://www.pvsm.ru -

Сертификаты Минцифры — как им не доверять

Ну что же — то, чего все ожидали (не путать с «ждали») случилось. Многие российские сайты и сервисы начали переходить на сертификаты Минцифры — и у пользователей начали ломаться работавшие ранее сервисы, пользователи начали получать сообщения о том, что подлинность ресурса не может быть проверена. Кто‑то просто не смог продлить свой сертификат, у других сертификаты вообще были отозваны — но, в конечном итоге, это приводит к одному и тому же результату — из за проблем с сертификатом сайты некоторых российских компаний перестают открываться через HTTPS (каковой де‑факто уже давно стал стандартом), а получить новые сертификаты становится проблемой.

Для того, чтобы обойти это ограничение, многие российские подсанкционные компании начали использовать так называемые сертификаты Минцифры — сертификаты, подписанные российскими удостоверяющими центрами с корневым сертификатом, выпущеным Минцифры. Чем это грозит пользователю?

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

  1. Сидеть без привычных цифровых сервисов — крайне грустный вариант

  2. Ставить Яндекс.Браузер — который имеет полноценный доступ к системе и пользовательским данным и разработан компанией со славной и «славной» историей — тоже не лучшая идея

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

А что если просто поставить корневые и выпускающие сертификаты Минцифры? Ведь можно будет и пользоваться привычными браузерам, и получить доступ на сайты с сертификатами российского регулятора!

Но вот вопрос в том, насколько вы доверяете этому регулятору. Давайте рассмотрим такую интересную цепочку действий:

  1. Минцифры подписывае для какого‑нибудь абстрактного «ФГУП Мониторинга и защиты интернета» сертификат, в котором задекларировано CA:true

  2. Компания «Sнаряд» и холдин «МордорТелеком» выпускают комплекс аппаратно‑программной фильтрации данных, которых выполняет перехват всех TLS‑соединений и их терминацию на своих серверах и отгружают этот комплекс в ФГУП из пункта 1

  3. Для генерации сертификатов для перехваченных TLS‑соединений используется сертификат из того же пункта 1

  4. Поскольку корневой Минцифры сертификат добавлен в систему, браузер доверяет сгенерированному сертификату — и мы получаем классическую атаку man‑in‑the‑middle, когда третья сторона успешно прочла ваши сессии

С этим надо что‑то делать, верно? А каждый раз, когда мы собираемся «что‑то делать» в области защиты данных, нам потребуется

Модель угрозы

  1. Третья сторона хочет получить доступ к нашим данным

  2. Эта третья сторона действует в российской юрисдикции и при необходимости может запросить наши данные у любой российской компании — и ей эти данные предоставят

  3. Эта третья сторона не может (или как минимум ограничена) в запросе наших данных у компаний вне российской юрисдикции

  4. Зная это, мы поделили свои данные на те, которые можно хранить в российской юрисдикции — и те, которые лучше хранить вне России

  5. Понимая этот факт, третья сторона (чуть не написал «злоумышленник») установила свое оборудование на линии связи между нами и нероссийскими компаниями

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

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

  8. Пункты 6 и 7 третьей стороне необходимы только для несанкционированного доступа к данным на сайтах вне России, для доступа к данным на ресурсах в российской юрисдикции в этих двух пунктах нет необходимости (пункт 2 об этом прямо говорит)

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

Что нужно сделать? Нужно ограничить корневой сертификат Минцифры так, чтобы его нельзя (невозможно) было использовать для генерации сертификатов для сайтов вне российской юрисдикции. Как это сделать? И на помощь нам приходит команда из двух механизмов, ожидаемого события и предсказуемой реакция бюрократической системы

  1. Механизм ДНС — большинство ресурсов «для России» живут в доменах.RU,.SU и.РФ

  2. Механизм nameConstraint — скоуп действия дерева сертификата и всех его субсертификатов (подписанных им) может быть ограничен через механизм nameContraints, который позволяет указать для каких доменов применимы сертификаты этого дерева сертификатов

  3. Ожидаемое событие — санкционные риски продолжают нарастать и реализовываться, и в рамках санкций может начаться разделегирование доменов российских компаний во всеъ доменах кроме национальных

  4. Реакция системы — для уменьшения санкционных рисков всем компаниям российской юрисдикции которые держат свои ресурсы вне национальных доменов, рекомендовано переезжать в национальные домены

Оцениваем — поскольку большинство российских крупный компаний в российские домены либо переехало, либо переедет в ближайшее время, нам будет достаточно ограничить действие корневого сертификата Минцифры национальными доменам. Это приведет к тому, что вне доменов RU/SU/РФ наши системы не будут принимать из дерева корневого сертификата Минцифры.

Ключевой пункт — для того, чтобы обеспечить конфиденциальность, вам НЕОБХОДИМО проделать это все самостоятельно! Тот, кто владеет приватным ключом корневого сертификата стоящего в вашей системе, может успешно устроить вам SSL bumping и man‑in‑the‑middle в рамках рамках ограничений сертификата. И если то, что госорганы могут устроить нам MitM для национальных доменов, нам не критично (в модели угроз мы это отметили), то тот, кто который может получить наши коммуникации с российскими ресурсами и не соответствует нашей модели нарушителя, в нашу модель угроз не вписан

Все действия сделаем с помощью OpenSSL. Я использую его на MacOS и Linux, и в примерах будут только они (владельцам Windows и безкомпьютерным пользователям могу выразить только моральную поддержку).

ПОЕХАЛИ

Скачиваем сертификаты с сайта Госуслуг — https://www.gosuslugi.ru/crt [1], я скачивал вариант «для Linux» — но там во всех вариантах примерно одно и то же. Нам понадобятся КОРНЕВЫЕ сертификаты (с ними мы будем работать), и опционально ВЫПУСКАЮЩИЕ (их мы менять не будем). Скачав архивы и распаковав их, мы увидим примерно такой набор файлов:

$ ls -1
russian_trusted_root_ca_gost_2025_pem.crt
russian_trusted_root_ca_pem.crt
russian_trusted_sub_ca_2024_pem.crt
russian_trusted_sub_ca_gost_2025_pem.crt
russian_trusted_sub_ca_pem.crt

Те, что с подстрокой gost нам не интересны (если у нас не стоит какого‑нибудь Крипто‑Про или тому подобного ПО для поддержки шифрования ГОСТ).

Смотрим на корневой сертификат

$ openssl x509 -in russian_trusted_root_ca_pem.crt -text | head -n 10
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4096 (0x1000)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
        Validity
            Not Before: Mar  1 21:04:15 2022 GMT
            Not After : Feb 27 21:04:15 2032 GMT
        Subject: C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA

Создаем свой корневой сертификат, похожий на сертификат Минцифры

$ openssl req -x509 -days 3650 -newkey rsa:4096 
  -nodes -keyout ca.key -out ca.crt 
  -subj "/CN=Secured-Private-Root" 
  -addext "basicConstraints = critical,CA:true,pathlen:5" 
  -addext "keyUsage = critical,digitalSignature,keyCertSign,cRLSign" 
  -addext "nameConstraints = critical, permitted;DNS:.ru, permitted;DNS:.su, permitted;DNS:.xn--p1ai"

.....

$ ls -1
ca.crt
ca.key
russian_trusted_root_ca_gost_2025_pem.crt
russian_trusted_root_ca_pem.crt
russian_trusted_sub_ca_2024_pem.crt
russian_trusted_sub_ca_gost_2025_pem.crt
russian_trusted_sub_ca_pem.crt

Файлы ca.crt и ca.key — это наш корневой сертификат и ключ этого сертификата. Опции addext задают сферу применения сертификата — базовое назначение. цели применения и ограничения на доменные имена.

Теперь создаем временную заглушку для подписи сертификата Минцифры

$ openssl req 
  -new -newkey rsa:4096 -nodes 
  -keyout temp.key 
  -out dummy.csr 
  -subj "/CN=Temporary Dummy CSR"
....
$ ls -1
ca.crt
ca.key
dummy.csr
russian_trusted_root_ca_gost_2025_pem.crt
russian_trusted_root_ca_pem.crt
russian_trusted_sub_ca_2024_pem.crt
russian_trusted_sub_ca_gost_2025_pem.crt
russian_trusted_sub_ca_pem.crt
temp.key

Обратите внимание — dummy.csr это запрос на сертификат и temp.key это его приватный ключ (впрочем, он нам не нужен).

Смотрим поле subject корневого сертификат Минцифры.

$ openssl x509 -in russian_trusted_root_ca_pem.crt -noout -subject
subject=C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA

В указанном значении subject надо в начало подставить / и заменить пару «запятая‑пробел» на тот же / — и получится subject для нового сертификата минцифры. В нашем случае, новым subject будет 


/C=RU/O=The Ministry of Digital Development and Communications/CN=Russian Trusted Root CA

Извлекаем из сертификата Мицифры публичный ключ

$ openssl x509 -in russian_trusted_root_ca_pem.crt -pubkey -noout > digital-gov.pub

$ ls -1
ca.crt
ca.key
digital-gov.pub
dummy.csr
russian_trusted_root_ca_gost_2025_pem.crt
russian_trusted_root_ca_pem.crt
russian_trusted_sub_ca_2024_pem.crt
russian_trusted_sub_ca_gost_2025_pem.crt
russian_trusted_sub_ca_pem.crt
temp.key

Создаем файл конфигурации расширений сертификата cross.conf вот такого содержания

[ cross_ca_ext ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
basicConstraints        = critical, CA:true
keyUsage                = critical, digitalSignature, cRLSign, keyCertSign

И, наконец‑то, переподписываем корневой сертификат Минцифры. Будьте внимательней с примером, длинное значение subj в статье в браузере может быть показано как перенесенное на другую строку!

$ openssl x509 
  -req -in dummy.csr 
  -CA ca.crt -CAkey ca.key 
  -CAcreateserial -days 3650 -sha256 
  -force_pubkey digital-gov.pub 
  -out new_root_ca.crt 
  -extfile cross.conf 
  -extensions cross_ca_ext 
  -subj "/C=RU/O=The Ministry of Digital Development and Communications/CN=Russian Trusted Root CA"

Certificate request self-signature ok
subject=CN=Temporary Dummy CSR

$ ls -1
ca.crt
ca.key
ca.srl
cross.conf
digital-gov.pub
dummy.csr
new_root_ca.crt
russian_trusted_root_ca_gost_2025_pem.crt
russian_trusted_root_ca_pem.crt
russian_trusted_sub_ca_2024_pem.crt
russian_trusted_sub_ca_gost_2025_pem.crt
russian_trusted_sub_ca_pem.crt
temp.key

Переподписанный сертификат минцифры в файле new_root_ca.crt.

Ну и финал — инсталлируем сертификаты и проверяем как они работают.

Тесты делались в Homebrew на MacOS

Тест изначального сертификата

Сначала делаем копию имеющейся базы сертификатов и чуть‑чуть подправим имеющиеся файлы

# Делаем копию баы корневых сеттификатов
$ cp /opt/homebrew/etc/ca-certificates/cert.pem 
     /opt/homebrew/etc/ca-certificates/cert.pem.orig

# Добавим в конец каждого минцифровского файла сертификатов
# пару пустых строк. В конце двух файлов отсутсвуют символы
# перевода строки и сертификаты слипаются, так что добавляем
# пару пустых строк и "ну вот теперь нормально работает"
$ for i in russian_*.crt ; do echo >> $i ; echo >> $i ; done

Инсталируем ОРИГИНАЛЬНЫЕ сертификаты Минцифры

$ cat /opt/homebrew/etc/ca-certificates/cert.pem.orig 
  russian_trusted_sub_ca_pem.crt 
  russian_trusted_sub_ca_2024_pem.crt 
  russian_trusted_root_ca_pem.crt >/opt/homebrew/etc/ca-certificates/cert.pem

Проверяем online.sberbank.ru — ошибок нет

$ openssl s_client -host online.sberbank.ru -port 443 | head -n 20
Connecting to 84.252.149.51
depth=2 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
verify return:1
depth=1 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
verify return:1
depth=0 C=RU, L=Moscow, O=Sberbank of Russia, ST=77 Moscow, CN=*.online.sberbank.ru, street=Vavilova street, 19, OGRN=1027700132195, 1.2.643.100.4=7707083893
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:C=RU, L=Moscow, O=Sberbank of Russia, ST=77 Moscow, CN=*.online.sberbank.ru, street=Vavilova street, 19, OGRN=1027700132195, 1.2.643.100.4=7707083893
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Nov 10 08:02:16 2025 GMT; NotAfter: Nov 10 08:02:16 2026 GMT
 1 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jul 15 12:50:41 2024 GMT; NotAfter: Jul 19 12:50:41 2029 GMT
 2 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar  1 21:04:15 2022 GMT; NotAfter: Feb 27 21:04:15 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIIOjCCBiKgAwIBAgIQLdMEXK/HTq2JOY43jtRsYDANBgkqhkiG9w0BAQsFADBv
MQswCQYDVQQGEwJSVTE/MD0GA1UECgw2VGhlIE1pbmlzdHJ5IG9mIERpZ2l0YWwg
^C

Проверяем sberbank.com — ошибок нет. Оригинальный сертификат минцифры может подписать все что угодно. И это грустно

$ openssl s_client -host sberbank.com -port 443 | head -n 15
Connecting to 84.252.149.206
depth=2 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
verify return:1
depth=1 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
verify return:1
depth=0 CN=sberbank.com, O=Sberbank, C=RU, ST=77 Moscow, L=Moscow, street=Vavilova street, building 19, 1.2.643.100.4=7707083893, OGRN=1027700132195
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:CN=sberbank.com, O=Sberbank, C=RU, ST=77 Moscow, L=Moscow, street=Vavilova street, building 19, 1.2.643.100.4=7707083893, OGRN=1027700132195
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jan 14 14:57:05 2026 GMT; NotAfter: Jan 14 14:57:05 2027 GMT
 1 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jul 15 12:50:41 2024 GMT; NotAfter: Jul 19 12:50:41 2029 GMT
 2 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar  1 21:04:15 2022 GMT; NotAfter: Feb 27 21:04:15 2032 GMT
^C

А теперь пересоздадим базу сертификатов — но уже с нашим сгенерированным корневым сертификатом — и пусть Минцифры отойдет!

Тест ограниченного сертификата

Записываем в базу НАШ корневой сертификат и ПЕРЕПОДПИСАНЫЙ сертификат минцифры.

$ cat /opt/homebrew/etc/ca-certificates/cert.pem.orig 
      russian_trusted_sub_ca_pem.crt 
      russian_trusted_sub_ca_2024_pem.crt 
      new_root_ca.crt 
      ca.crt >/opt/homebrew/etc/ca-certificates/cert.pem

Снова тестируем online.sberbank.ru — и ожидаем что он БУДЕТ работать

$ openssl s_client -host online.sberbank.ru -port 443 | head -n 20
Connecting to 84.252.149.51
depth=3 CN=Secured-Private-Root
verify return:1
depth=2 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
verify return:1
depth=1 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
verify return:1
depth=0 C=RU, L=Moscow, O=Sberbank of Russia, ST=77 Moscow, CN=*.online.sberbank.ru, street=Vavilova street, 19, OGRN=1027700132195, 1.2.643.100.4=7707083893
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:C=RU, L=Moscow, O=Sberbank of Russia, ST=77 Moscow, CN=*.online.sberbank.ru, street=Vavilova street, 19, OGRN=1027700132195, 1.2.643.100.4=7707083893
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Nov 10 08:02:16 2025 GMT; NotAfter: Nov 10 08:02:16 2026 GMT
 1 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jul 15 12:50:41 2024 GMT; NotAfter: Jul 19 12:50:41 2029 GMT
 2 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar  1 21:04:15 2022 GMT; NotAfter: Feb 27 21:04:15 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIIOjCCBiKgAwIBAgIQLdMEXK/HTq2JOY43jtRsYDANBgkqhkiG9w0BAQsFADBv
MQswCQYDVQQGEwJSVTE/MD0GA1UECgw2VGhlIE1pbmlzdHJ5IG9mIERpZ2l0YWwg
^C

А вот теперь самое интересное — тестируем sberbank.com — и он должен СЛОМАТЬСЯ

$ openssl s_client -host sberbank.com -port 443 | head -n 15
Connecting to 84.252.149.206
depth=3 CN=Secured-Private-Root
verify return:1
depth=2 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
verify return:1
depth=1 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
verify return:1
depth=0 CN=sberbank.com, O=Sberbank, C=RU, ST=77 Moscow, L=Moscow, street=Vavilova street, building 19, 1.2.643.100.4=7707083893, OGRN=1027700132195
verify return:1
depth=0 CN=sberbank.com, O=Sberbank, C=RU, ST=77 Moscow, L=Moscow, street=Vavilova street, building 19, 1.2.643.100.4=7707083893, OGRN=1027700132195
verify error:num=47:permitted subtree violation
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:CN=sberbank.com, O=Sberbank, C=RU, ST=77 Moscow, L=Moscow, street=Vavilova street, building 19, 1.2.643.100.4=7707083893, OGRN=1027700132195
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jan 14 14:57:05 2026 GMT; NotAfter: Jan 14 14:57:05 2027 GMT
 1 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jul 15 12:50:41 2024 GMT; NotAfter: Jul 19 12:50:41 2029 GMT
 2 s:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   i:C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar  1 21:04:15 2022 GMT; NotAfter: Feb 27 21:04:15 2032 GMT

Да, и он сломался — об этом говорит строка verify error:num-47:permitted subtree violation (чуть выше слова CONNECTED).

Теперь осталось просто добавить наши сертификаты из файлов в систему (желающие найдут инструкции в интернете), включить доверие к нашему корневому сертификату (помеченному как Secured‑Private‑Root) — и всё. Рекомендуемый порядок

  1. Сначала добавляем из ca.crt и включаем доверие к нему

  2. Затем добавляем new_root_ca.crt

Сертификат добавленый в MacOS

Сертификат добавленый в MacOS

Открываем в сафари online.sberbank.ru — работает.

Открываем sberbank.com — не работает.

Можно прооверить в терминале с помощью curl:

$ curl -i https://online.sberbank.ru | head -n 15
HTTP/1.1 302 Moved Temporarily
Date: Fri, 14 Aug 2026 09:23:28 GMT
Content-Type: text/html
Content-Length: 137
Connection: keep-alive
Location: https://online.sberbank.ru/CSAFront/index.do

<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>SOWA</center>
</body>
</html>

$ curl -i https://sberbank.com | head -n 15
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Второй тест — в Linux (использую Fedora 44)

Копируем сертификаты в систему и добавляем их в основное хранилище

$ sudo cp ca.crt new_root_ca.crt /usr/share/pki/ca-trust-source/anchors
$ sudo update-ca-trust

Тест online.sberbank.ru — должен отработать нормально (я немного исправил вызов openssl чтобы оставить только stderr и убрать stdout в который печатаются сертификаты и выхлоп удаленной стороны)

$ openssl s_client -host online.sberbank.ru -port 443 >/dev/null
Connecting to 84.252.149.51
depth=3 CN=Secured-Private-Root
verify return:1
depth=2 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
verify return:1
depth=1 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
verify return:1
depth=0 C=RU, L=Moscow, O=Sberbank of Russia, ST=77 Moscow, CN=*.online.sberbank.ru, street=Vavilova street, 19, OGRN=1027700132195, 1.2.643.100.4=7707083893
verify return:1

Так и есть — верификация штатная.

Тест sberbank.com — должна быть получена ошибка:

$ openssl s_client -host sberbank.com -port 443 >/dev/null
Connecting to 84.252.149.206
depth=3 CN=Secured-Private-Root
verify return:1
depth=2 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
verify return:1
depth=1 C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
verify return:1
depth=0 CN=sberbank.com, O=Sberbank, C=RU, ST=77 Moscow, L=Moscow, street=Vavilova street, building 19, 1.2.643.100.4=7707083893, OGRN=1027700132195
verify return:1
depth=0 CN=sberbank.com, O=Sberbank, C=RU, ST=77 Moscow, L=Moscow, street=Vavilova street, building 19, 1.2.643.100.4=7707083893, OGRN=1027700132195
verify error:num=47:permitted subtree violation
verify return:1

permitetd subtree violation, как и должно быть

Заключение

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

Автор: outlingo

Источник [2]

Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/mitm/456721

Ссылки в тексте:

[1] https://www.gosuslugi.ru/crt: https://www.gosuslugi.ru/crt

[2] Источник: https://habr.com/ru/articles/1071256/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1071256