Устранение неисправностей инспекции TLS

Введение

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

При нормальных условиях инспекция TLS незаметна для пользователей. Чтобы проверить, инспектируется ли трафик, проверьте поле Инспекция TLS в событиях учетной записи (1 = инспектировано, 0 = обход), просмотрите издателя сертификата в браузере (Cato Networks) или используйте отчеты инспекции TLS.

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

Симптомы

Возможные причины

Большинство проблем с инспекцией TLS связаны с несколькими общими условиями.

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

  • Проблемы с доверием к сертификату на клиенте — еще одна частая причина. Если корневой сертификат Cato отсутствует, не является доверенным или развернут несоответственно, инспектируемый трафик может не проходить проверку даже при правильной политике.

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

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

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

  • Наконец, специфичное для платформы поведение играет роль. Мобильные устройства, конечные точки BYOD и системы Linux могут вести себя иначе из-за ограничений доверия к сертификатам, специфичной для приложения проверки или правил обхода по умолчанию.

Первоначальная диагностика

При расследовании проблем, связанных с TLS, основной целью является определить, исходит ли проблема от клиента, сети (инспекция TLS) или конечного сервера.

1. Изолировать область

Начните с проверки, является ли проблема специфичной для клиента. Проведите тестирование той же URL адреса:

  • С другого браузера
  • С другого устройства в той же сети
  • С того же устройства в другой сети (например, точка доступа)

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

2. Подтвердите инспекцию TLS / издателя сертификата

Из браузера:

  • Откройте DevTools → вкладку Безопасность или нажмите на значок замка
  • Инспектировать цепочку сертификатов

Проверьте издателя:

  • Прокси/Корпоративный CA (например, Cato) → инспекция TLS активна
  • Общедоступный CA (например, DigiCert, Let's Encrypt) → прямое TLS сессия

3. Проверка доверия к сертификату на клиенте

  • Убедитесь, что корневой сертификат Cato правильно установлен на конечной точке.

  • Проверьте, чтобы корневой сертификат находился в хранилище доверия ОС:
    • На Windows откройте Диспетчер сертификатов компьютера, введя certlm.msc, и найдите корневой сертификат под Доверенными корневыми сертификационными органами.
    • На Mac откройте Keychain Access, и найдите корневой сертификат в Системной цепочке ключей.
  • Проверьте системные время и дату
  • Если корневой сертификат Cato отсутствует на конечной точке, загрузите его и установите, как объяснено в установка сертификата Cato на устройства
  • Отсутствующая или некорректная конфигурация доверия приведет к немедленным сбоям TLS.

4. Тестировать TLS Handshake от клиента

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

Выполните следующее или аналогичное с пострадавшей конечной точки:

curl.exe -v https://

Если OpenSSL доступен:

openssl s_client -connect :443 -servername 

Ожидаемый вывод (успех)

* SSL соединение с использованием TLS1.2 / TLS1.3
* Сертификат сервера:
* subject: CN=www.google.com
* issuer: CN=GTS CA 1C3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

Важно прежде всего определить, связана ли проблема с клиентом, конечным сервером или конфигурацией инспекции TLS

Диагностика типичных проблем

Примечание:
В списке ниже приведены общие сценарии, наблюдаемые в развертываниях инспекции TLS. Многие из этих ошибок общие и могут не прямо соответствовать вашей конкретной среде.
Если описанные симптомы или решения не совпадают с вашим случаем, рекомендуется собрать диагностические данные (например, SSS, HAR и PCAP) с клиентского устройства и создать заявку о поддержке для глубокого анализа.

Диагностика отказа приложений 

Проблема: Определенные приложения не могут установить безопасные соединения или перестают работать после включения инспекции TLS.

Ожидание поведения:
Приложения с жестким контролем безопасности (например, банковские приложения, инструменты безопасности конечных точек) могут немедленно завершить соединения, молча завершаться или неоднократно пытаться повторить соединения. Это происходит потому, что инспекция TLS вводит сертификат перехвата (MITM), который данные приложения специально разработаны для обнаружения и отклонения.

Решение:
Проверить, обходя инспекцию TLS для одного пользователя или IP-источника, используя правило в начале политики. Если приложение работает при обходе, создайте целевой исключение (на основе домена/FQDN) и избегайте широких правил. Кроме того, Мастер настройки инспекции TLS Cato можно использовать для обхода чувствительных доменов с минимальной конфигурацией. 

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

Пример:
Если финансовое приложение не может войти и работает немедленно после обхода инспекции TLS для этого пользователя, это подтверждает несовместимость - добавьте домен приложения в список обхода. 

Диагностика предупреждения сертификата в браузере

Проблема: Пользователи видят предупреждения о сертификатах или приложения не работают после включения инспекции TLS.

Ожидание поведения:
Пользователи могут столкнуться с предупреждениями браузера (например, "соединение не безопасно") или полными сбоями соединений. Поведение может варьироваться в зависимости от устройств, в зависимости от того, установлен ли сертификат Cato правильно.

Решение:
Убедитесь, что корневой сертификат инспекции TLS Cato установлен и является доверенным на всех конечных точках. Установите через GPO/MDM и проверьте полную цепочку сертификатов на клиенте.

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

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

Обратитесь к Защита трафика с инспекцией TLS с использованием частных сертификатов, если используете частные сертификаты в вашей организации. 

Диагностика несоответствия имени хоста

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

Ожидание поведения:
Когда сервер предоставляет сертификат, общий имя (CN) или SAN которого не совпадает с запрошенным именем хоста, соединение считается недействительным.

Без инспекции TLS браузер напрямую обнаруживает это несоответствие и отображает предупреждение сертификата.

При включенной инспекции TLS браузер устанавливает TLS-сессию с Cato PoP, а не с исходным сервером. PoP перевыпускает сертификат, используя корневой СА Cato, создавая видимость корректности сертификата для клиента. Таким образом, несоответствие в браузере не отображается, хотя проблема все еще существует на заднем фоне.

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

Поскольку несоответствие вызвано конфигурацией сертификата сервера, оно не может быть исправлено инспекцией TLS. Соответствующее действие — либо:

  • Разрешить доступ, обходя инспекцию TLS для конкретного домена, или
  • Блокировать трафик на основе политики, если несоответствие считается риском безопасности

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

Пример:
При доступе к https://www.testingmcafeesites.com/ сервер представляет сертификат для platformsplat1.mcafee.com.

Без инспекции TLS браузер немедленно отмечает несоответствие имени хоста.

При включенной инспекции TLS браузер видит действительный сертификат, выдаваемый корневыми CA Cato для www.testingmcafeesites.com, поэтому ошибка не отображается. Однако Cato PoP обнаруживает несоответствие на заднем фоне и применяет настроенную политику (блокировка или предупреждение).

Диагностика проблем загрузки веб-сайтов или приложений

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

Ожидание поведения:

  • Страницы могут зависать, загружаться бесконечно или частично отображаться
  • Процессы входа/аутентификации могут не работать или зацикливаться
  • Некоторые сайты могут казаться медленными из-за нагрузки TLS дешифрования/ре-шифрования
  • Поведение может быть непоследовательным (например, работает в одной сети, не работает через Cato)

Это обычно наблюдается с современными веб-приложениями, использующими строгие меры безопасности или сложные зависимости TLS.

Решение:
Проверить путем обхода инспекции TLS для специфического пользователя или IP-адреса источника. Если сайт работает при обходе, создайте исключение для целевого домена/FQDN.

Избегайте широких правил обхода — ограничьте исключения только необходимыми доменами.

Если приложение опирается на строгие механизмы безопасности (например, закрепленные сертификаты или обработка TLS), инспекция может не поддерживаться, и обход является правильным подходом.

Сценарий – Современные веб-приложения (SaaS):
Некоторые платформы SaaS (например, приложения с множеством бэкэнд-доменов/CDNs) могут загружаться частично (UI работает, API не удаются). В таких случаях определите все необходимые домены с помощью HAR/DevTools и убедитесь в полном покрытии правила обхода.

Устранение неполадок с подтверждением сертификата Cato

Проблема: отображаются ошибки, связанные с TLS от Cato, при просмотре или использовании приложения.

Ожидаемое поведение:

Пользователи могут столкнуться с типовыми ошибками, такими как: 

  • "Защищенное соединение не удалось"
  • "Сертификат не доверен"
  • Незапланированные сбросы или обрывы соединения

Эти ошибки обычно неконкретные и не указывают четко, исходят ли проблемы от клиентского устройства, сервера или процесса инспекции TLS.

Решение:
Проверить поведение, временно обходя инспекцию TLS для одного пользователя или IP-адреса источника.

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

В качестве временного решения рекомендуется обойти инспекцию TLS для пораженного домена/приложения, одновременно открывая случай поддержки.

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

Постоянные меры должны сосредоточиться на:

  • Обеспечение сервера полной и действительной цепочки сертификатов
  • Использование сертификатов, выданных известными доверенными CA

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

Новые доверенные / недавно опубликованные домены

Домены, которые недавно опубликованы, обновлены или переклассифицированы в интернете, могут пока не признаваться всеми системами репутации, центрами сертификации или хранилищами доверия.

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

Ожидаемое поведение:
Такие домены могут:

  • Быть неправильно классифицированными или непоследовательно категоризированными в разных системах безопасности
  • Представлять сертификаты, которые не полностью распространены или доверены глобально
  • Вызвать ошибки TLS во время инспекции из-за неполных цепочек доверия
  • Быть заблокированными на основе политики, а не фактической проблемы со связью

Это поведение звичайно короткое после того, как домен становится активным или претерпевает изменения.

Решение:

  • Проверить сертификат непосредственно с конечного устройства, чтобы подтвердить его легитимность
  • Если домен подтвержден как безопасный:
    • Переклассифицируйте его в разрешенную категорию на основе требований политики, либо
    • Создайте целевое правило разрешения/обхода (избегайте широких исключений)
  • Обходные правила следует рассматривать как временные, если это возможно
  • Переоцените домен через некоторое время, когда его репутация и доверие к сертификату будут полностью установлены глобально

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

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

Не поддерживаемые протоколы и устаревшие системы

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

Ожидаемое поведение:
Сбой обычно происходит во время обмена ключами TLS и виден непосредственно в браузере или клиенте.

Общие ошибки браузера включают:

  • ERR_SSL_PROTOCOL_ERROR
  • ERR_EMPTY_RESPONSE
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_CONNECTION_CLOSED
  • 400 Плохой запрос
    Необходимый SSL сертификат не был отправлен

В некоторых случаях:

  • Страница может полностью не загрузиться
  • Соединение может немедленно сбрасываться
  • Толстые клиенты или устаревшие приложения могут тихо сбой или показывать общие ошибки соединения

Это происходит потому, что клиент или сервер не могут договориться о совместимой версии TLS или наборе шифров с Cato PoP действующим как MITM.

В событиях вы также заметите поле Описание ошибки TLS, заполненное конкретной информацией 

Для получения дополнительной информации об ошибках посетите Узнать об ошибках TLS 

Решение:

  • Временно обходите инспекцию TLS для специфического пользователя или IP-адреса источника, чтобы проверить поведение
  • Если приложение работает при обходе → подтверждает несоответствие переговоров TLS во время инспекции

Далее, подтвердите возможности TLS, используя внешние инструменты, такие как https://www.ssllabs.com/ssltest/

Сравните результаты с вашей политикой инспекции TLS:

  • Минимально допустимая версия TLS
  • Уровень исполнения набора шифров

Если подтверждено:

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

Примечание:
По умолчанию, Cato позволяет широкий диапазон версий TLS и наборов шифров. Однако, администраторы могут ужесточить контроль в политике инспекции TLS (например, минимальная версия TLS или сила шифрования), что может привести к сбою устаревших приложений. Для получения дополнительной информации читайте здесь

 

Сценарий – Устаревшее внутреннее приложение:
Внутреннее или стороннее устаревшее приложение может сбой только при маршрутизации через Cato с включенной инспекцией TLS, но успешно работать при обходе. Это обычно указывает на зависимость от снятых с использование версий TLS, требующих модернизации приложения или постоянного обхода.

Устранение неполадок с специфическими для ОС проблемами TLS (предполагаемые ограничения)

Проблема: Проблемы с соединением, ненавязчивое поведение или отсутствие видимости инспекции TLS на определенных операционных системах и типах устройств (например, мобильные, BYOD, Linux).

Ожидаемое поведение:

Поведение значимо различается в зависимости от операционной системы и дизайна приложения.

Для устройств на Android и Linux инспекция TLS обходится по умолчанию из-за ограничений доверия к сертификатам и поведения приложений. Однако, новейшие конфигурации (через расширенные настройки в CMA) позволяют администраторам применить инспекцию TLS на этих платформах, если доверие к сертификатам может быть правильно установлено.

Для устройств на iOS инспекция TLS поддерживается, но несколько приложений (например, платформы социальных медиа, такие как Instagram, Facebook и аналогичные) обходятся по умолчанию из-за закрепления сертификатов и известных несовместимостей. Другие приложения, которые проводят строгую проверку, могут сбой и требовать ручной настройки обхода.

В общем:

  • Браузеры могут работать как ожидается, когда сертификат Cato установлен
  • Нативные/мобильные приложения могут сбой немедленно из-за закрепления сертификатов или ограниченных хранилищ доверия
  • Поведение может отличаться по приложению, даже на одном устройстве

Решение:

Эти поведения, как правило, ожидаются и обусловлены платформой, не указывают на некорректную конфигурацию.

  • Применяйте инспекцию TLS преимущественно на управляемые устройства, где развертывание сертификатов контролируется
  • Используйте решения MDM для установки сертификата Cato на уровне системы (где поддерживается)
  • Будьте осведомлены о правилах обхода по умолчанию для известных приложений и платформ
  • Для приложений, которые сбой из-за закрепления сертификатов или строгой проверки, настройте целевой обход инспекции TLS
  • Когда применяете инспекцию TLS на платформах, таких как Android или Linux, внимательно подтвердите совместимость перед широким развертыванием

Сценарий – Сбой мобильного приложения:
Мобильное приложение (например, банковское или приложение безопасности) не удается подключиться через Cato, в то время как браузер работает. Приложение проводит закрепление сертификатов и не доверяет сертификату Cato. Это ожидается — правильное действие заключается в том, чтобы обойти инспекцию TLS для этого приложения или сервиса.

Поднятие случаев на поддержку Cato

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

  • Подробности о возникшей проблеме и общем воздействии на пользователей. Отметка времени/часовой пояс пользователя, испытывающего проблему. 
  • Связанные события и конфигурация правила файервола/TLS.
  • Воспроизведите проблему и выполните самообслуживание поддержки. Включите номер тикета, созданный инструментом.

 

Была ли эта статья полезной?

Пользователи, считающие этот материал полезным: 0 из 0

0 комментариев