HTTPS-инспекция на ИКС: как внедрить без массовых ошибок сертификатов

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

Что получим в итоге

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

1. Сначала определяем цель

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

2. Фиксируем состояние до изменений

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

curl -I https://example.com
curl -Iv https://example.com
openssl s_client -connect example.com:443 -servername example.com

В выводе OpenSSL обратите внимание на issuer, subject и цепочку сертификатов. До включения инспекции сертификат должен быть выдан публичным центром сертификации сайта.

3. Готовим корпоративный CA

В старом интерфейсе ИКС перед настройкой сертификатов включался контент-фильтр в разделе защиты. В новых версиях название пункта может отличаться, но смысл тот же: активировать компонент, который анализирует расшифрованный HTTPS-трафик.

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

Укажите созданный сертификат в настройках прокси ИКС для HTTPS-инспекции.

Экспортируйте только публичную часть CA и передайте её на тестовый компьютер.

Для доменных Windows-компьютеров сертификат разумно распространять через Group Policy. Для Linux и macOS используйте штатные корпоративные механизмы управления сертификатами. Ручная установка допустима только на небольшой тестовой группе.

4. Создаём тестовую группу

Не включайте инспекцию сразу для всей сети. Выберите несколько компьютеров с разными сценариями: обычный браузер, почтовый клиент, мессенджер, обновления ОС и одно критичное бизнес-приложение. Это даст реальную картину совместимости.

5. Включаем инспекцию только для теста

Для контрольной проверки создайте отдельный тестовый список в контент-фильтре. Так проще убедиться, что шлюз действительно анализирует содержимое HTTPS-страницы, а не только домен.

В ИКС создайте отдельное правило HTTPS-фильтрации для тестовой группы. Основная сеть пока должна продолжать работать без расшифровки. После применения откройте несколько сайтов и повторите проверку сертификата.

curl -Iv https://example.com
openssl s_client -connect example.com:443 -servername example.com

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

6. Формируем исключения

Часть приложений использует certificate pinning и проверяет не только доверие к CA, но и конкретный сертификат сервера. Такие приложения после расшифровки могут полностью перестать подключаться. В исключения обычно попадают банковские, медицинские, государственные сервисы, некоторые мессенджеры, агенты обновления и внутренние системы с взаимной TLS-аутентификацией.

Каждое исключение документируйте: домен, приложение, причина, владелец и дата проверки. Иначе список быстро превращается в свалку, где никто не понимает, почему половина трафика обходит инспекцию.

7. Проверяем рабочие сценарии

• браузеры открывают сайты без ошибок сертификата;
• почтовый клиент отправляет и получает почту;
• Windows Update и репозитории Linux загружают обновления;
• мессенджеры и видеосвязь подключаются;
• корпоративные приложения проходят авторизацию;
• загрузка тестового файла фиксируется политикой ИКС.

8. Диагностика

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

curl -Iv https://problem.example
openssl s_client -connect problem.example:443 -servername problem.example
nslookup problem.example
ping problem.example

Команды позволяют разделить DNS, сетевую доступность и ошибку TLS. Не отключайте весь firewall ради проверки: это скроет реальную причину и создаст новую проблему.

9. Расширяем поэтапно

После нескольких дней стабильной работы добавляйте пользователей небольшими группами. Следите за обращениями, ошибками сертификатов и нагрузкой на шлюз. Не совмещайте расширение HTTPS-инспекции с обновлением ИКС или массовой сменой сетевых политик.

10. Откат

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

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