В офисе другой SSL-сертификат: как проверить TLS-инспекцию

Если в офисе браузер показывает для сайта другой SSL-сертификат, чем дома или в мобильной сети, это часто связано с TLS-инспекцией. Корпоративный шлюз, VPN-клиент или защитная программа завершает зашифрованное соединение, проверяет трафик и выпускает для браузера новый сертификат от внутреннего центра сертификации.

Само различие ещё не доказывает перехват и не означает, что сайт взломан. Сертификат мог обновиться, CDN может обслуживать домен с разных узлов, а сравниваемые адреса — вести на разные хосты. Надёжная проверка начинается с одного URL, одного времени и сопоставления всей цепочки, а не только названия издателя.

Что происходит при TLS-инспекции

При обычном HTTPS браузер устанавливает TLS-соединение с сервером сайта или его CDN и получает сертификат для запрошенного имени. При инспекции между браузером и сайтом появляется доверенный корпоративный посредник:

1. устройство подключается к шлюзу или локальному защитному агенту;
2. посредник устанавливает отдельное соединение с сайтом;
3. для браузера он создаёт сертификат на тот же домен, подписанный корпоративным центром сертификации;
4. устройство принимает его, если корпоративный корневой сертификат добавлен в доверенные.

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

Сначала зафиксируйте условия сравнения

Откройте один и тот же полный адрес, например https://example.ru/, без перехода на альтернативный домен. Проверяйте обе сети почти одновременно: при плановой смене сертификата старый и новый варианты могут некоторое время встречаться на разных узлах CDN.

В браузере откройте сведения о соединении и запишите:

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

Не отправляйте коллегам закрытые ключи, пароли, cookies или заголовки авторизации. Для диагностики достаточно публичного URL, реквизитов сертификата и обезличенного снимка цепочки.

Как отделить офисный шлюз от проблемы на устройстве

Одного сравнения «офис — телефон» мало. Проведите четыре проверки по возможности на одном и том же домене.

1. Управляемый компьютер в офисной сети

Это исходная точка. Если издатель похож на название организации, защитного продукта или внутреннего центра сертификации, TLS-инспекция вероятна, но вывод пока предварительный.

2. Тот же компьютер через мобильную точку доступа

Если сертификат снова корпоративный, причина, скорее всего, находится на устройстве: VPN-клиент, антивирус, endpoint-защита или постоянно работающий прокси. Если появился публичный сертификат, проверяйте офисный шлюз и сетевую политику.

Перед переключением сети согласуйте тест с ИТ-службой. Не отключайте защитные средства и не удаляйте доверенный корневой сертификат ради эксперимента.

3. Другое устройство в той же офисной сети

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

Личный телефон может идти по отдельной гостевой сети и не подтверждает поведение корпоративного сегмента. Зафиксируйте, к какой Wi‑Fi-сети или VLAN подключено каждое устройство.

4. Внешняя проверка из интернета

Сравните результат с домашней сетью, мобильным интернетом или публичной проверкой SSL-сертификата. Проверка SSL в Web-Puls показывает сертификат, видимый с внешней точки, и не проходит через офисный прокси. Поэтому она помогает установить публичный ориентир, но не подтверждает исправность корпоративного маршрута.

Для дополнительной проверки администратор может выполнить команду без передачи учётных данных:

openssl s_client -connect example.ru:443 -servername example.ru -showcerts

Параметр -servername важен: без SNI сервер с несколькими сайтами способен вернуть сертификат другого виртуального хоста.

Как читать результат

Публичный сертификат исправен, корпоративный отличается

Если снаружи домен, срок и публичная цепочка корректны, а в офисе сертификат подписан внутренним центром, наиболее вероятна TLS-инспекция. Уточните у ИТ-службы, должна ли политика охватывать этот домен и установлен ли нужный корневой сертификат на всех управляемых устройствах.

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

Ошибка видна и из внешней сети

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

Сертификат отличается только на одном устройстве

Проверьте системный прокси, активный VPN, расширения и защитное ПО. Затем сравните браузеры: они могут использовать разные наборы доверенных центров. Самостоятельное отключение контроля трафика способно нарушить политику безопасности и не устраняет причину.

Отпечатки разные, но обе цепочки публичные и корректные

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

Что передать ИТ-службе или подрядчику

Короткая диагностическая карточка ускоряет разбор:

• публичный URL без приватных параметров;
• время проверки и часовой пояс;
• офисная, домашняя или мобильная сеть;
• устройство и браузер;
• издатель, серийный номер и SHA-256-отпечаток в каждой точке;
• полная цепочка без закрытых ключей;
• текст ошибки и снимок экрана;
• сведения о VPN или прокси без конфигурационных секретов.

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

Вывод

Другой сертификат в офисе нужно проверять сравнением одного адреса в нескольких контролируемых условиях. Корпоративный издатель только в офисной сети указывает на шлюз; тот же сертификат во всех сетях одного устройства — на локальный агент; ошибка снаружи возвращает диагностику к сайту или CDN.

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