Ну что же — то, чего все ожидали (не путать с «ждали») случилось. Многие российские сайты и сервисы начали переходить на сертификаты Минцифры — и у пользователей начали ломаться работавшие ранее сервисы, пользователи начали получать сообщения, что подлинность ресурса не может быть проверена. Кто‑то просто не смог продлить свой сертификат, у других сертификаты вообще были отозваны — но, в конечном итоге, это приводит к одному и тому же результату — из‑за проблем с сертификатом сайты некоторых российских компаний перестают открываться через HTTPS (каковой де‑факто уже давно стал стандартом), а получить новые сертификаты становится проблемой.
Для того, чтобы обойти это ограничение, многие российские подсанкционные компании начали использовать так называемые сертификаты Минцифры — сертификаты, подписанные российскими удостоверяющими центрами с корневым сертификатом, выпущенным Минцифры. Чем это грозит пользователю?
Если не вдаваться в подробности, то картину можно описать примерно так — либо ты ставишь сертификаты Минцифры в систему и у тебя всё работает, либо ставишь Яндекс.Браузер — в котором эти сертификаты уже вшиты — и у тебя все работает, либо сидишь без сервисов. Выбор, мягко говоря, не лучший. Почему? Пойдем в обратном направлении:
Сидеть без привычных цифровых сервисов — крайне грустный вариант
Ставить Яндекс.Браузер — который имеет полноценный доступ к системе и пользовательским данным и разработан компанией со славной и «славной» историей — тоже не лучшая идея.
Пользоваться двумя браузерами — привычным для тех сайтов где нет сертификатов Минцифры и Яндекс.Браузером для тех где они есть... Нууу, как минимум это весьма неудобно.
А что если просто поставить корневые и выпускающие сертификаты Минцифры? Ведь можно будет и пользоваться привычными браузерам, и получить доступ на сайты с сертификатами российского регулятора!
Но вот вопрос в том, насколько вы доверяете этому регулятору. Давайте рассмотрим такую интересную цепочку действий:
Минцифры подписывает для какого‑нибудь абстрактного «ФГУП Мониторинга и защиты интернета» сертификат, в котором задекларировано CA:true.
Компания «Sнаряд» и холдинг «МордорТелеком» выпускают комплекс аппаратно‑программной фильтрации данных, который выполняет перехват всех TLS‑соединений и их терминацию на своих серверах, и отгружают этот комплекс в ФГУП из пункта 1.
Для генерации сертификатов для перехваченных TLS‑соединений используется сертификат из того же пункта 1.
Поскольку корневой Минцифры сертификат добавлен в систему, браузер доверяет сгенерированному сертификату — и мы получаем классическую атаку man‑in‑the‑middle, когда третья сторона успешно прочла ваши сессии.
С этим надо что‑то делать, верно? А каждый раз, когда мы собираемся «что‑то делать» в области защиты данных, нам потребуется
Модель угрозы
Третья сторона хочет получить доступ к нашим данным.
Эта третья сторона действует в российской юрисдикции и при необходимости может запросить наши данные у любой российской компании — и ей эти данные предоставят.
Эта третья сторона не может (или как минимум ограничена) в запросе наших данных у компаний вне российской юрисдикции.
Зная это, мы поделили свои данные на те, которые можно хранить в российской юрисдикции — и те, которые лучше хранить вне России.
Понимая этот факт, третья сторона (чуть не написал «злоумышленник») установила свое оборудование на линии связи между нами и нероссийскими компаниями.
Эта третья сторона может вмешаться в трафик между нами и сайтом так, что мы этого не заметим без специальных средств.
После вмешательства, третья сторона получит доступ к нашим данным которые мы передавали на серверы зарубежных компаний и получали обратно, в том числе к аутентификационным — например идентификаторам сессий, токенам и так далее — и, используя их, сможет получить доступ к нашим данным.
Пункты 6 и 7 третьей стороне необходимы только для несанкционированного доступа к данным на сайтах вне России, для доступа к данным на ресурсах в российской юрисдикции в этих двух пунктах нет необходимости (пункт 2 об этом прямо говорит).
И резюме — если мы хотим, чтобы эта третья сторона не получила доступ к нашим данным, расположенным вне России, нам необходимо не допустить незаметного вмешательства в наши сессии. Итого, ключевая точка — это пункт 6. И он стал возможным из‑за того, что браузер и система доверяют всем корневым сертификатам — и установив сертификаты Минцифры мы сами реализовали пункт 6.
Что нужно сделать? Нужно ограничить корневой сертификат Минцифры так, чтобы его нельзя (невозможно) было использовать для генерации сертификатов для сайтов вне российской юрисдикции. Как это сделать? И на помощь нам приходит команда из двух механизмов: ожидаемого события и предсказуемой реакции бюрократической системы
Механизм ДНС — большинство ресурсов «для России» живут в доменах.RU,.SU и.РФ
Механизм nameConstraint — скоуп действия дерева сертификата и всех его субсертификатов (подписанных им) может быть ограничен через механизм nameContraints, который позволяет указать для каких доменов применимы сертификаты этого дерева сертификатов.
Ожидаемое событие — санкционные риски продолжают нарастать и реализовываться, и в рамках санкций может начаться разделегирование доменов российских компаний во всех доменах, кроме национальных.
Реакция системы — для уменьшения санкционных рисков всем компаниям российской юрисдикции которые держат свои ресурсы вне национальных доменов, рекомендовано переезжать в национальные домены.
Оцениваем — поскольку большинство российских крупных компаний в российские домены либо переехало, либо переедет в ближайшее время, нам будет достаточно ограничить действие корневого сертификата Минцифры национальными доменами. Это приведет к тому, что вне доменов RU/SU/РФ наши системы не будут принимать из дерева корневого сертификата Минцифры.
Ключевой пункт — для того, чтобы обеспечить конфиденциальность, вам необходимо проделать это все самостоятельно! Тот, кто владеет приватным ключом корневого сертификата стоящего в вашей системе, может успешно устроить вам SSL bumping и man‑in‑the‑middle в рамках ограничений сертификата. И если то, что госорганы могут устроить нам MitM для национальных доменов, нам не критично (в модели угроз мы это отметили), то тот, кто может получить наши коммуникации с российскими ресурсами и не соответствует нашей модели нарушителя, в нашу модель угроз не вписан
Все действия сделаем с помощью OpenSSL. Я использую его на MacOS и Linux, и в примерах будут только они (владельцам Windows и безкомпьютерным пользователям могу выразить только моральную поддержку).
Поехали
Скачиваем сертификаты с сайта Госуслуг — https://www.gosuslugi.ru/crt, я скачивал вариант «для 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) — и всё. Рекомендуемый порядок
Сначала добавляем из ca.crt и включаем доверие к нему
Затем добавляем new_root_ca.crt
Открываем в сафари 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, как и должно быть
Заключение
Предложенная схема неидеальна — но, как мне кажется, вполне справляется со своей задачей. Да, те ресурсы, которые переехали на сертификаты Минцифры, но остались вне национальных доменов, могут не работать, но это уже значительно лучше, чем «не работает всё» или «абсолютно доверяем Минцифры».
Комментарии (20)
baldr
17.08.2026 12:14То есть вы
простоограничили действие сертификата на зоны .ru и .su (и .рф)? Оригинально, но как-то слишком грубо.Я вполне могу захотеть иметь свой сайт
mysecrets.ruи не хотеть чтобы мой трафик слушали. Я выпущу сертификат от letsencrypt, но с вашим решением MiTM всё ещё возможна. Причём, как хозяин сайта, я не могу на это повлиять для посетителей (вас), если они будут следовать вашему способу.По-моему вариант с отдельным профилем браузера (того же firefox) для недоверенных сайтов - достаточно оптимальный.
JBFW
17.08.2026 12:14С учётом обязательной верификации ru через ГУ и продолжающимися тенденциями вас могут просто обязать предъявить сайт к осмотру.
Для защиты детей.
baldr
17.08.2026 12:14Да, я хотел об этом тоже дописать, но решил играть в оптимиста.
Тем более, что если у сайта будет 2-3 пользователя, то вряд ли он скоро привлечет какое-то внимание
outlingo Автор
17.08.2026 12:14Я вполне могу захотеть иметь свой сайт
mysecrets.ruНу, чтобы быть вам делегированым, ваш домен должен быть подтвержден через Госуслуги. Поэтому к вам (ли к вашему хостеру) просто придут ножками.
Тем не менее, если вы все решили держать сайт в российском национальном домене и не хотите чтобы ваш сайт можно было MitM-нуть, в том же nameConstraints добавить что-то вроде excluded;DNS:mysecrets.ru,DNS:.mysecretes.ru
baldr
17.08.2026 12:14Не мне, а каждому пользователю, который захочет на него ходить. И выпускать новый доверенный сертификат для нового такого сайта? Не много ли мороки?
outlingo Автор
17.08.2026 12:14Не много ли мороки?
Удобство и конфиденциальность как правило антагонистичны. Чем удобней, тем хуже с конциденциальностью, и наоборот - чем лучше с конфиденциальностью - тем хуже с удобством.
vanxant
17.08.2026 12:14Любой сайт в нац. доменах и любой сайт на отечественном хостинге подвержен угрозе получения поддельного сертификата letsencrypt.
outlingo Автор
17.08.2026 12:14Любой сайт в нац. доменах и любой сайт на отечественном хостинге подвержен угрозе получения поддельного сертификата letsencrypt.
Напомните, пожалуйста, трехмесячный MitM для jabber.ru в 2023 году помог устроить хостинг какой страны?
В статье идет речь о методике, которая позволит затруднить российским провайдерам и структурам перехватывать сессии российских пользователей к не-российским ресурсам.
V1tol
17.08.2026 12:14Ещё до всех этих приколов с сертификатами для работы с госухой поставил Chromium GOST (про его существование почему-то все забывают). Просто закинул сертификаты в него и пользуюсь браузером только для банков и прочей налоговой.
vis_inet
17.08.2026 12:14Chromium GOST
А его версии следуют за обновлениями от Гугла?
V1tol
17.08.2026 12:14Вполне. Отставание на единичку считаю некритичным.
https://github.com/deemru/Chromium-Gost/releases
https://update.cryptopro.ru/get/chromium-gost/version
AVikont
17.08.2026 12:14Как по мне, гораздо проще использовать два браузера или даже один браузер с двумя профилями.
JBFW
17.08.2026 12:14Падажжите-пададжите, верно ли я понимаю что можно так самому подписать себе, например, сайт sber-bank.ru?
Ну правда остаётся нюанс с подтверждением доменного имени
baldr
17.08.2026 12:14Себе можно, конечно. Но суть в том, что вы себе свой собственный доверенный сертификат ставите сначала. Атака тут как бы не очень простая получается.
outlingo Автор
17.08.2026 12:14Самому себе можно подписать все что угодно, но там может быть экзотика со всячекими certificate pining.
Siemargl
17.08.2026 12:14Если вы идете на сайт nanohub.org подписанный LetsEncrypt итп, при чем тут сертификаты Минцифры?
Разумеется, не с яндексбраузера.
vanxant
17.08.2026 12:14Два браузера это давно норма. Особенно если у вас ЭЦП с рутокеном и т.д. Ставить это в дефолтный браузер тупо тупо.
Quqas
17.08.2026 12:14есть и куда более простой костыльный способ
на ругню хрома просто жмём "всё равно" и подключаемся без этих сертов
с bspb норм работает
с сбером тоже но тогда это "всё равно" нужно жать стопицот раз на каждой ссылке которые смотреть в devtool
но в итоге тоже работает
пока кэш не чистить хром эти "всё равно" запоминает аккурат только для разрешённых доменов
NeoCode2
Просто поставил виртуалку - линукс с единственным яндекс браузером, причем уже много лет назад, и из нее захожу на сайты банков и госуслуг. Если припрет - и "макс" туда же поставлю (но пока не припирает).
Moog_Prodigy
Обождите ставить "скам", даже на выделенный отдельный комп. При регистрации в нем сработают кучи привязок - в итоге без скама вы потом никуда зайти не сможете классическими методами. Ну почти. Лучше не усложнять себе жизнь. Если уж и ставить его, то и регить на левый аккаунт (а дальше включайте фантазию).