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检查/证书发行者

从浏览器中：

  • 打开开发者工具 → 安全选项卡 或点击锁定图标
  • 检查证书链

检查发行者：

  • 代理/企业 CA（例如，Cato） → TLS检查处于活动状态
  • 公共 CA（例如，DigiCert，Let’s Encrypt） → 直接TLS会话

3. 在客户端验证证书信任

  • 确保Cato根证书已正确安装在端点。

  • 验证根证书是否在操作系统信任存储中：
    • 在Windows上，键入 certlm.msc 打开计算机证书管理器，并在 受信任的根证书授权机构 下查找根证书
    • 在Mac上，打开 钥匙串访问，并在 系统钥匙串 下查找根证书
  • 检查系统时间和日期
  • 如果端点缺失Cato根证书，请下载并按在设备上安装Cato证书中的说明安装。

  • 信任配置缺失或不正确将导致TLS立即失败。

4. 从客户端测试TLS握手

使用客户端工具模拟TLS连接，并识别握手失败的具体位置及原因。 这些工具暴露常常隐藏在通用浏览器消息后的错误。

从受影响的端点运行以下命令或类似命令：

curl.exe -v https://<domain>

如果OpenSSL可用：

openssl s_client -connect <domain>:443 -servername <domain>

预期输出（成功）

* 使用TLS1.2/TLS1.3的SSL连接
* 服务器证书：
* 主题：CN=www.google.com
* 发行者：CN=GTS CA 1C3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

首先确定问题是与客户端、目标服务器或TLS检查配置本身有关非常重要。 

常见问题故障排除

注意：
以下列出的问题代表了TLS检查部署中常见的场景。 其中许多错误是通用的，可能或者不一定直接适用于您的特定环境。
如果所描述的症状或解决方案与您的情况不一致，建议收集诊断数据（例如，SSS，HAR和PCAP）并提高帮助请求以获得更深入的分析。

故障应用程序的故障排除 

问题：某些应用程序无法建立安全连接或在启用TLS检查后停止工作。

行为期望：
具备严格安全控制的应用程序（例如，银行应用程序，端点安全工具）可能立即连接失败、无声崩溃或反复尝试连接。 这是由于TLS检查引入了中间人（MITM）证书，这些应用程序专为检测和拒绝设计。

解决方案：
通过在策略顶部的规则验证绕过TLS检查的单个用户或来源IP。 如果应用程序在绕过时有效，创建目标排除（域／FQDN基础）并避免宽泛规则。 此外，Cato的平台的 TLS检查配置向导 可用于以最少配置绕过敏感域。 

如果应用程序或服务器强制执行证书钉扎或严格TLS要求，无法应用TLS检查。 在这种情况下，正确的方法是永久绕过该流量。

示例：
如果金融应用程序登录失败并在绕过该用户的TLS检查后立即工作，这证实了不兼容 - 将该应用程序域添加到绕过列表中。 

浏览器证书警告故障排除

问题：用户看到证书警告或应用程序在启用TLS检查后失败。

行为期望：
用户可能会遇到浏览器警告（例如，“连接不安全”）或完全连接失败。 行为可能因设备而异，具体取决于是否正确安装了Cato证书。

解决方案：
确保Cato TLS检查根证书在所有端点上安装并受信任。 使用 GPO/MDM 部署并验证客户端上的完整证书链。

如果使用私人／内部证书，确保它们受到正确信任或遵循相关TLS检查证书处理程序。

如果行为不一致，通过绕过特定用户或设备的TLS检查验证以确认证书相关影响。

如果在贵组织中使用私人证书，请参考使用私人证书进行TLS检查以保护流量。 

主机名不匹配故障排除

问题：用户在访问某些网站时由于主机名不匹配而遇到证书错误或连接被阻止，尤其是在启用TLS检查时。

行为期望：
当服务器提供的证书的通用名称（CN）或SAN与请求的主机名不匹配时，连接被视为无效。

没有TLS检查时，浏览器会直接检测到这种不匹配并显示证书警告。

启用TLS检查时，浏览器与Cato PoP而不是原始服务器建立TLS会话。 PoP使用Cato Root CA重新签署证书，使其对客户端看起来有效。 因此，即使问题仍存在于后端，浏览器中也不会显示不匹配。

解决方案：
通过绕过特定用户或来源IP的TLS检查验证该行为。 如果浏览器随后显示主机名不匹配错误，这确认问题来源于目标服务器。

由于不匹配由服务器的证书配置引起，无法通过TLS检查进行更正。 适当的操作是可选择：

  • 通过绕过特定域的TLS检查允许访问，或
  • 如果认为不匹配是安全风险，则根据策略阻止流量。

避免宽泛的绕过规则，而是使用需要的目标域/FQDN排除。

示例：
当访问https://www.testingmcafeesites.com/时，服务器提供的证书为platformsplat1.mcafee.com。

没有TLS检查时，浏览器会立即标记主机名不匹配。

启用TLS检查时，浏览器看到一个由Cato Root CA为www.testingmcafeesites.com签发的有效证书，因此没有显示错误。 然而，Cato PoP在后台检测到不匹配并强制执行配置的策略（阻止或警告）。

网站或应用程序加载问题故障排除

问题：在启用TLS检查时，网站无法加载，部分渲染或表现不如预期。

行为期望：

  • 页面可能会挂起，无限加载，或部分渲染
  • 登录／认证流程可能会失败或循环
  • 由于TLS解密／重新加密开销，某些站点可能显得缓慢
  • 行为可能不一致（例如，在一个网络上工作，通过Cato失败）

这通常发生在使用严格安全控制或复杂TLS依赖的现代Web应用程序中。

解决方案：
通过为特定用户或来源 IP绕过 TLS 检查来验证。 如果站点在绕过时可以工作，创建一个针对性域名/FQDN 排除。

避免使用广泛的绕过规则—将排除范围限制到仅必要的域名。

如果应用程序依赖于严格的安全机制（例如，固定证书或高级 TLS 处理），可能不支持检查，绕过是正确的方法。

场景 – 现代 Web 应用程序 (SaaS)：
一些 SaaS 平台(例如，具有多个后端域名/CDN 的应用程序)可能部分加载(界面工作，API 失败)。 在这些情况下，通过HAR/开发工具识别所有必需域，并确保在绕过规则中全面覆盖。

排查 Cato 证书验证错误

问题： 在浏览或应用程序使用过程中，出现 Cato 与 TLS 相关的错误。

行为预期：

用户可能会遇到如下通用错误： 

  • “安全连接失败”
  • “证书不受信任”
  • 意外连接重置或掉线

这些错误通常不是具体的，不能明确指出问题是源于客户端、服务器或 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 错误请求\n未发送所需的 SSL 证书

在某些情况下：

  • 页面可能无法完全加载
  • 连接可能立即重置
  • 厚客户端或旧应用程序可能静默失败或显示通用连接错误

发生这种情况是因为客户端或服务器无法与充当中间人的Cato PoP协商兼容的 TLS 版本或加密套件。

在事件中，您还会注意到 TLS 错误描述字段中会填入特定信息。 

欲了解更多关于错误的信息请访问了解TLS错误 

解决方案：

  • 临时绕过 TLS 检查，针对特定用户或来源 IP 验证行为
  • 如果应用程序在绕过时可以工作→确认检查期间 TLS 协商不匹配

接下来，使用外部工具，如 https://www.ssllabs.com/ssltest/ 验证 TLS 能力

将结果与您的 TLS 检查策略进行比较：

  • 最低允许的 TLS 版本
  • 加密套件执行级别

如果确认：

  • 更新或升级应用程序或服务器以支持现代 TLS 版本和强大的加密套件
  • 如果升级不可行，为受影响的应用程序或域配置针对性的 TLS 检查绕过

注意：
Cato 默认允许广泛范围的 TLS 版本和加密套件。 但是，管理员可以在 TLS 检查策略中实现更严格的控制（例如，最低 TLS 版本或加密强度），这可能导致旧应用程序失败。 欲了解更多信息，请阅读此处

 

场景 – 旧版内部应用程序：
内部或第三方旧版应用程序在通过 TLS 检查启用的 Cato 路由时可能失败，但在绕过时可用。 通常表明依赖于已弃用的 TLS 版本，需要升级应用程序或永久绕过。

排查特定于操作系统的 TLS 问题（已知限制）

问题：连通性问题、不一致的行为，或在某些操作系统和设备类型（例如，移动设备，BYOD，Linux）上缺乏 TLS 检查可见性。

行为预期：

行为因操作系统和应用程序设计而异。

对于Android 和 Linux 设备，由于证书信任的局限性和应用行为，默认绕过 TLS 检查。 然而，新配置（通过 CMA 中的高级设置）允许管理员在适当建立证书信任的情况下在这些平台上强制 TLS 检查。

对于iOS 设备，支持 TLS 检查，但由于证书钉扎和已知的不兼容性，多个应用程序（例如，类似 Instagram、Facebook 的社交媒体平台）默认绕过。 其他强制严格验证的应用程序可能会失败，需要手动绕过配置。

一般来说：

  • 一旦安装了 Cato 证书，浏览器可能按预期工作
  • 由于证书钉扎或受限信任存储，原生/移动应用程序可能立即失败
  • 行为可能因应用程序而异，即使在同一设备上也是如此

解决方案：

这些行为通常是预期的和平台驱动的，并不表明配置错误。

  • 主要将 TLS 检查应用于管理设备，在那里可控地部署证书
  • 使用MDM 解决方案在系统级别安装 Cato 证书（在支持的情况下）
  • 注意为知名应用程序和平台设置的默认绕过规则
  • 对于因证书钉扎或严格验证而失败的应用程序，配置针对性的 TLS 检查绕过
  • 在 Android 或 Linux 等平台上强制执行 TLS 检查时，在大规模推出之前慎重验证兼容性

场景 – 移动应用程序失败：
一个移动应用（例如，银行或安全应用）无法通过 Cato 连接，而浏览器则可以。 该应用强制证书钉扎且不信任 Cato 证书。 这是预期的——正确的操作是为该应用程序或服务绕过 TLS 检查。

向 Cato 支持提交问题

如果由于合规性或监管原因，对应用程序进行 TLS 检查是强制性的，或者您认为 TLS 阻止是意外的，请提交支持票，并附上上述故障排除步骤的结果。 请在工单中包含以下信息：

  • 所经历问题的详细信息及对用户的整体影响。 用户遇到问题的时间戳/时区。 
  • 相关事件和防火墙/TLS 规则配置。
  • 重现问题，运行支持自助服务。 包括由工具生成的工单号码。

 

这篇文章有帮助吗？

0 人中有 0 人觉得有帮助

0 条评论