Пользователь не открывает сайт с ГОСТ-сертификатом: разбор причин

MAATRIX

Сайт настроен, сертификат от аккредитованного УЦ установлен, openssl s_client со стороны сервера подключается без ошибок — а пользователь пишет в поддержку, что видит «сайт недоступен» или «ошибка соединения» и не понимает, что делать. Это не значит, что сервер сломан. В девяти случаях из десяти проблема в том, что обычный браузер физически не умеет разговаривать с ГОСТ-TLS, и разбираться в этом придётся вам, а не пользователю. Разберём, откуда берётся эта ошибка, как быстро её продиагностировать и что отвечать людям, которые звонят с вопросом «у меня сайт не открывается».

Что видит пользователь и почему это не баг вашего сервера

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

• Chrome, Firefox, Edge на обычной сборке: страница «Это подключение не является защищённым», ERR_SSL_VERSION_OR_CIPHER_MISMATCH, ERR_SSL_PROTOCOL_ERROR — браузер не смог согласовать набор шифров с сервером и оборвал handshake ещё до применения сертификата.
• Мобильные браузеры на Android/iOS: то же самое, но сообщение обычно короче — «не удаётся установить безопасное соединение».
• Специализированный ГОСТ-браузер или браузер с нужным плагином: сайт открывается нормально — что подтверждает: дело не в конфигурации сервера, а в возможностях клиента.
• Иногда путают с другой историей: сертификат от российского УЦ на обычном (не ГОСТовом) TLS, где браузер просто не доверяет корневому центру. Это другая проблема с похожими симптомами, и вы легко потратите час не на то расследование, если не разделите эти два случая с самого начала.

Важно сразу зафиксировать: если у вас на сервере честный ГОСТ-TLS (шифрование по ГОСТ Р 34.10-2012 / ГОСТ Р 34.11-2012), то обычный браузер на обычной ОС в принципе не может открыть такой сайт — это не вопрос настройки, а вопрос поддерживаемых алгоритмов на уровне TLS-стека клиента. Про то, что реально требуется на сервере для ГОСТ-TLS и когда эта схема оправдана, у нас есть отдельный разбор — ГОСТ TLS на практике: что нужно серверу и клиенту.

Три причины, из-за которых ГОСТ-TLS не открывается в обычном браузере

Все причины сводятся к одному: массовые браузеры и ОС в базовой поставке ориентированы на международный набор алгоритмов (RSA/ECDSA, AES, SHA-2) и не включают в себя криптографию ГОСТ. Но конкретных точек отказа три, и полезно понимать, где именно рвётся цепочка.

1. В TLS-стеке браузера/ОС нет реализации ГОСТ-алгоритмов. Согласование шифронабора (cipher suite negotiation) происходит на этапе ClientHello — браузер присылает серверу список алгоритмов, которые он умеет. Если в этом списке нет ГОСТовых наборов, а сервер требует именно их, handshake обрывается ещё до того, как речь вообще доходит до проверки сертификата. Это самая частая причина ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

2. У клиента нет доверенного корневого сертификата. Даже если бы алгоритмы совпали, браузеру ещё нужно проверить цепочку доверия до корневого центра. Корневые сертификаты российских ГОСТ-УЦ (в том числе головного УЦ) не входят по умолчанию в системные хранилища доверенных корней большинства ОС и браузеров за пределами специализированных сборок. Их нужно устанавливать вручную — и это отдельный шаг, независимый от поддержки самих алгоритмов.

3. Нужен отдельный компонент — плагин или отдельная сборка браузера. Для работы с ГОСТ-криптографией в вебе применяются два общих варианта: расширение/плагин, который встраивает поддержку ГОСТ-алгоритмов в существующий браузер, либо отдельная сборка браузера с уже встроенной поддержкой. Здесь я намеренно не называю конкретные продукты и версии: список актуальных решений и их статус поддержки меняются, и на конец августа 2026 года правильный источник истины — официальные рекомендации вашего удостоверяющего центра или ГИС, к которой подключается пользователь, а не статья в блоге. Проверяйте актуальный список у того, кто выдал сертификат.

Все три причины независимы друг от друга: можно закрыть первую и вторую, но забыть про третью, и пользователь всё равно не откроет сайт.

Как быстро отличить проблему ГОСТ от обычной проблемы с сертификатом

Прежде чем писать инструкцию пользователю, убедитесь, что причина именно в ГОСТ, а не в банальной проблеме с обычным сертификатом — истёк срок, не хватает промежуточного сертификата в цепочке, домен не совпадает с CN/SAN. Три быстрые проверки со своей стороны:

# 1. Проверяем handshake обычным TLS-клиентом с сервера
openssl s_client -connect example.ru:443 -servername example.ru

# Если сервер настроен строго под ГОСТ, вы увидите обрыв
# на этапе согласования шифров или ошибку вида
# "no cipher match" / "sslv3 alert handshake failure"

# 2. Смотрим полный список шифронаборов, которые предлагает сервер
nmap --script ssl-enum-ciphers -p 443 example.ru

Если в выводе ssl-enum-ciphers вы видите только ГОСТовые OID-и алгоритмов (например, идентификаторы из линейки TC26) и ни одного стандартного набора вроде TLS_AES_128_GCM_SHA256 — это подтверждает, что сервер принимает только ГОСТ-соединения, и обычный браузер просто не сможет подключиться в принципе, вне зависимости от того, что установлено у пользователя из корневых сертификатов.

# 3. Проверяем, что видит сам пользователь — попросите прислать
# скриншот адресной строки и полный текст ошибки, либо
# результат команды на его машине (если это технический пользователь)
curl -v https://example.ru 2>&1 | grep -E "SSL|TLS|error"

Дальше — простая таблица для быстрой сортировки обращений в поддержку:

Если проблема массовая и появилась резко — это почти наверняка серверная сторона, а не клиентская: клиентские причины (не установлен плагин/сертификат) обычно проявляются точечно, у конкретных новых пользователей, а не у всех разом.

Что попросить установить пользователя — по шагам

Когда диагностика подтвердила, что дело именно в клиенте, дайте пользователю чёткую последовательность, а не общую фразу «настройте ГОСТ». Порядок такой:

1. Уточните, для какого именно контура/УЦ нужен доступ. У разных ГИС и разных удостоверяющих центров может быть разный набор рекомендуемых компонентов и разные ссылки на официальные дистрибутивы. Не пытайтесь дать универсальную инструкцию «на все случаи ГОСТ» — привяжите её к конкретному УЦ, чей сертификат стоит у вас на сервере.
2. Установить корневой и, если нужен, промежуточный сертификат УЦ — обычно это делается через официальный портал УЦ или через Госуслуги, скачиванием .crt-файла и импортом в системное или браузерное хранилище доверенных корневых сертификатов. Это отдельный шаг от установки криптомодуля — многие путают эти два действия и устанавливают только один из компонентов.
3. Установить криптографический модуль/плагин, обеспечивающий поддержку ГОСТ-алгоритмов в браузере, либо перейти на браузер с изначальной поддержкой ГОСТ. Дайте пользователю прямую ссылку на официальную страницу дистрибутива, а не на сторонние зеркала — в этой области особенно важно не подсовывать людям файлы с непроверенных источников.
4. Перезапустить браузер полностью (не просто вкладку) — TLS-модули и списки корневых сертификатов подхватываются заново только при перезапуске процесса браузера, и это частая причина «я всё установил, а всё равно не работает».
5. Проверить на тестовой странице, если УЦ или ГИС предоставляет отдельный URL для самопроверки поддержки ГОСТ — это экономит цикл переписки «не открывается» → «а теперь?» → «всё ещё нет».

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

Готовый скрипт объяснения для техподдержки

Людям, которые впервые сталкиваются с ГОСТ-TLS, бесполезно объяснять через термины «шифронабор» и «корневой центр». Рабочая формулировка, которую можно адаптировать под свою поддержку:

> «Этот сайт защищён по российскому стандарту шифрования (ГОСТ), а не по обычному, который понимают Chrome, Safari или обычный Firefox из коробки. Это не поломка — это особенность конкретного сайта, требование к безопасности соединения. Чтобы открыть его, нужно либо установить дополнительный компонент в ваш браузер, либо использовать браузер, который такой стандарт поддерживает изначально. Мы пришлём вам официальную ссылку на нужный компонент — устанавливать что-то со сторонних сайтов не нужно и небезопасно. После установки полностью закройте и снова откройте браузер — иначе изменения не применятся».

Дальше — три вещи, которые стоит подготовить заранее, чтобы не объяснять это каждый раз с нуля:

• Шаблон письма с прямой ссылкой на официальный источник дистрибутива/плагина именно от того УЦ, чей сертификат у вас на сервере.
• Короткий FAQ на самом сайте (или на отдельной странице-заглушке, куда можно перенаправлять по ошибке handshake) — многие организации делают отдельную посадочную страницу с инструкцией именно для этого случая.
• Скрипт для первой линии поддержки — вопрос «в каком браузере вы открываете сайт» должен быть первым, а не десятым, потому что 90% таких обращений закрываются на этом шаге без эскалации.

Когда пора переходить на гибридную схему: обычный TLS + ГОСТ-контур

Если после разбора обращений вы видите, что доля пользователей, которые физически не могут поставить нужный компонент (корпоративные ограничения на установку ПО, устаревшие устройства, мобильные пользователи, внешняя аудитория без технической квалификации) — заметная часть всей аудитории сайта, стоит honestly задать себе вопрос: а обязательно ли шифровать по ГОСТ вообще всё?

Гибридная схема — это разделение на два контура:

• Публичный контур на обычном TLS (Let's Encrypt или коммерческий сертификат) — для основной массы пользователей, у которых нет требования подключаться именно по ГОСТ. Обычный браузер, никаких дополнительных установок.
• Регуляторный/ведомственный контур на ГОСТ-TLS — для конкретных интеграций, где ГОСТ действительно обязателен (например, взаимодействие с определённой ГИС или требование конкретного контрагента), и куда заходят пользователи, которые заведомо готовы к установке нужных компонентов.

Технически это может быть отдельный поддомен (secure-gost.example.ru) со своим сертификатом, либо отдельный порт на том же сервере, но принципиально — это два разных TLS-эндпоинта, не один сайт с "универсальным" сертификатом. Смешать оба набора алгоритмов на одном слушателе nginx штатными средствами не получится: обычный OpenSSL-стек nginx не понимает ГОСТ без специальной пересборки и engine, а сборка с GOST-engine, наоборот, теряет часть стандартной функциональности, если её не настраивать аккуратно раздельно по server-блокам. Пример разделения по доменам на одном сервере:

# Обычный контур — стандартный TLS, доступен всем
server {
    listen 443 ssl;
    server_name example.ru www.example.ru;

    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
}

# ГОСТ-контур — отдельный поддомен, отдельный сертификат,
# требует сборки nginx/OpenSSL с GOST-engine
server {
    listen 443 ssl;
    server_name secure-gost.example.ru;

    ssl_certificate     /etc/gost-certs/secure-gost.crt;
    ssl_certificate_key /etc/gost-certs/secure-gost.key;
    ssl_engine          gost;
}

Подробности по серверной настройке именно ГОСТ-контура — engine, требования к сборке OpenSSL, что можно и что нельзя автоматизировать через Let's Encrypt-подобные инструменты — вынесены в отдельный материал: ГОСТ TLS на практике. Здесь важно другое: решение о гибридной схеме — это не техническая мелочь, а архитектурное решение, которое стоит принимать вместе с той стороной, которая требует ГОСТ (регулятор, контрагент, служба безопасности), а не в одиночку по итогам жалоб от пользователей. Иногда требование ГОСТ жёсткое и не подлежит компромиссу для всего периметра — тогда разговор идёт не про «делить на два контура», а про «обучать всю аудиторию».

Если у вас сертификат от российского УЦ, но проблема не в ГОСТ-алгоритмах, а именно в доверии к корневому центру на обычном TLS — это отдельная, более простая по решению ситуация, разобранная в статье Сертификат российского УЦ на nginx: установка по шагам.

Частые вопросы