Коротко — да и нет. Есть несколько подходов, но универсального «щелчком» решения, которое бы заставляло все клиенты доверять корню только для одного домена, не существует: нужна комбинация серверных настроек и контроля клиентских доверительных хранилищ или встроенного пиннинга в приложениях.
Ниже — кратко по опциям и что реально работает на практике.
1) Для владельца сайта / разработчика
- Certificate Authority Authorization (CAA). DNS‑запись, которая указывает, какие CA могут выдавать сертификаты для домена. Это предотвращает нежелательный выпуск, но не мешает клиентам доверять уже выданным сертификатам от других корней.
- DANE (DNSSEC + TLSA). Позволяет связать конкретный сертификат/ключ с доменом на уровне DNS. Работает только если у клиента поддержка DANE и у домена включён DNSSEC.
- Встроенный пиннинг сертификата/ключа в мобильном/настольном приложении (certificate pinning). Надёжный способ: приложение принимает только конкретный публичный ключ/сертификат для домена — тогда никакой сторонний корень не сможет подделать соединение. HPKP в браузерах устарел/депрекейтнут.
- HSTS и preloading повышают безопасность, но не решают проблему доверия к корню.
2) Для администратора/корпоративной сети (централизованный контроль клиентов)
- Управление доверенными корнями через групповые политики / MDM: можно развернуть набор доверенных корней или удалить существующие на управляемых устройствах. Это даёт тонкий контроль, но требует управления каждым клиентом.
3) Для обычного пользователя, который не хочет «устанавливать» государственный CA
- Не устанавливайте корневой сертификат, если не доверяете. Установка даёт возможности MITM (расшифровка и подмена HTTPS).
- Но учтите: некоторые сети/провайдеры могут блокировать доступ к сайтам или показывать предупреждения, если сертификат не установлен. Им будут видны только то, что вы обращаетесь к хосту (SNI, IP), но не содержимое HTTPS, если они не имеют доверенного корня.
- Можно пользоваться браузером/клиентом с собственным хранилищем корней (например, Firefox использует свой root store), это усложнит централизованному наблюдению.
- Используйте VPN или Tor/обфускацию для защиты трафика от сетевого перехвата — это самый практичный способ избежать MITM на уровне сети (но помните о юридических рисках/политике в вашей юрисдикции).
- Используйте приложения, которые реализуют пиннинг (мессенджеры с end‑to‑end шифрованием, клиенты для вашего сервиса).
4) Практическая рекомендация по второму вопросу
- Нет, вам не обязательно устанавливать сертификат «Центра сертификации Минцифры», если вы не хотите разрешать этому центру делать перехват HTTPS: установка даёт им возможность расшифровывать трафик. Если сайт работает по стандартному HTTPS и вы не установите их корень, вы либо получите предупреждение о недоверенном сертификате (если они пытались MITM), либо сайт будет доступен нормально (если перехвата нет).
- Если провайдер/организация требует установку корня под угрозой блокировок — тогда без установки часть ресурсов может быть недоступна; в таком случае используйте VPN/Tor или доступ через приложения/сервисы, которые поддерживают собственный пиннинг.
5) Ограничения и предупреждения
- Технические меры не дают 100% гарантии против централизованного контроля, если у атакующей стороны есть административный доступ к устройству или они принудительно внедряют корень на уровне оборудования/ПО.
- Обходы централизованного наблюдения могут иметь юридические последствия в некоторых странах. Убедитесь в законности ваших действий.
Вывод: если вы не хотите давать «товарищу майору» доступ к содержимому HTTPS — не устанавливайте его корневой сертификат и используйте дополнительные меры (VPN/Tor, приложения с пиннингом, браузеры с собственным хранилищем, DANE/CAA на стороне сервера). Для строгого ограничения доверия к корню только для одного домена нужно либо клиентский пиннинг/DANE, либо контроль доверенных корней на самом устройстве.