两个独立的客户报告了影响Android用户的SSL故障，尽管他们的证书是有效的并且正确安装。桌面浏览器没有显示错误，而特定的移动设备却拒绝连接，显示为不受信任。
案例研究摘要
- 问题：新的CA链不被旧版Android设备信任。
- 影响：尽管证书有效，移动用户仍看到SSL错误。
- 根本原因：Android信任存储库滞后于CA链迁移。
- 解决方案：使用传统或交叉签名链重新颁发，或迁移到具有更好移动兼容性的CA。
- 关键洞察：SSL信任依赖于客户端平台，不仅仅是证书有效性。
SSL证书可能在技术上有效，但在生产环境中仍然失败。证书有效性只确认它已被颁发且在密码学上是可靠的。它不能确保在所有设备上的通用信任。
这正是CA链迁移期间发生的情况。证书颁发机构出于安全、合规和长期可持续性的考虑轮换根证书和中间证书。
但是客户端平台，特别是移动操作系统，更新其信任存储库的速度要慢得多且不一致。结果是现代证书基础设施与传统设备信任之间出现了断层。
在这个案例研究中，我们检查了两个真实事件，其中CA链更改导致有效的SSL证书在Android设备上失败。我们展示了这些故障如何在生产环境中出现，为什么标准诊断没有立即揭示原因，以及不同的解决方案路径如何在每种情况下恢复移动兼容性。
Xamisoft：当服务器升级破坏了Android信任时
Xamisoft开发跨桌面和移动平台使用的语言学习应用程序。他们的基础设施在Windows Server 2019上一直运行正常，没有SSL问题。桌面浏览器和Android设备都工作正常，证书部署遵循标准的IIS设置。问题只在常规升级后出现。
问题
他们将环境从Windows Server 2019迁移到Windows Server 2025，并使用之前有效的相同方法重新安装了SSL证书。从服务器角度来看，一切都是正确的。
证书已安装，根证书和中间证书都存在，桌面浏览器没有显示任何警告。没有任何迹象表明SSL配置有问题。然后Android用户开始报告故障。在较旧的Android版本上，特别是Android 6，网站显示错误：“此证书不来自受信任的机构。”
在某些情况下，即使在较新的Android版本上也出现了类似的错误。这使得情况更难解释。乍一看，它似乎是配置错误的服务器或缺少证书文件。
从客户的角度来看，这种情况没有任何意义：
- 相同的证书在Windows Server 2019上没有问题。
- 现在在Windows Server 2025上失败了。
- 桌面浏览器仍然工作。
- 只有移动用户被阻止。
根本原因分析
这是典型的”一切都有效，但用户被锁定”的场景。在这一点上，两个技术维度开始浮现。
1. CA链本身
在Windows Server 2019上，证书是在旧的Sectigo RSA Domain Validation Secure Server CA层次结构下颁发的。这个链被广泛信任，包括旧版本。
在Windows Server 2025上，相同的证书现在链接到：Sectigo Public Server Authentication CA DV R36。
这是Sectigo较新信任层次结构的一部分。它是有效的，并被现代系统信任，但一些Android信任存储库尚未包含它。对于这些设备，证书链根本没有受信任的锚点。
2. 证书链传递
Windows Server 2019使用系统存储库填充缺失的中间证书。IIS可以在后台检索中间证书，并向客户端呈现完整的链，即使管理员没有明确安装每个组件。Windows Server 2025改变了这种行为。它要求明确配置完整的链。如果任何中间证书缺失或顺序不正确，即使浏览器可以通过AIA (Authority Information Access) 获取恢复链，一些客户端也会验证失败。
这意味着Xamisoft正在处理两个重叠的问题：
- 一些Android设备不信任新的Sectigo层次结构。
- 一些客户端没有从服务器正确接收完整的链。
任何一个问题都可以破坏SSL。两者结合，会掩盖真正的原因。
这解释了为什么：
- 桌面浏览器仍然工作。
- SSL测试工具显示主要是绿色结果。
- Android设备不可预测地失败，取决于版本和供应商构建。
我们的诊断
首先，我们澄清了Android设备从不使用服务器的信任存储库。在Windows上安装根证书对Android没有任何作用。信任决策完全在设备上做出。
其次，我们解释了Windows Server 2025需要明确的链完整性。服务器需要呈现：
- 服务器证书
- 正确的中间证书
- 按正确的顺序
依赖隐式检索不再可行。
解决方案
不是试图强制IIS可靠地处理这个问题，Xamisoft实施了一个结构性修复。他们将Nginx放置在IIS前面作为代理，并配置Nginx明确提供完整的证书链。
这达到了两个目的：
- 完整的链一致地传递给每个客户端。
- 仍然信任层次结构较旧部分的Android设备可以正确验证。
更改后，SSL错误消失了，Android 6设备可以再次访问网站。不需要更改证书本身。
这个案例强调了SSL失败往往不是由一个错误引起的，而是从CA链演化、平台信任存储库、服务器软件行为和证书传递机制之间的相互作用中产生的。Xamisoft的修复修复了现代CA基础设施和传统客户端信任之间的传递路径。
Coppernic：证书重新颁发后Android 6失败
Coppernic是一家法国技术公司，为身份识别、访问控制和数据收集系统设计和开发专业移动硬件和软件解决方案。
问题
问题出现在常规证书更换期间，仅在传统Android设备上。Coppernic正在从现有SSL证书切换到新订购的证书。
安装本身按预期进行。桌面浏览器接受证书而没有警告。没有可见的服务器端配置错误。然而，Android 6.0.1终端无法再建立受信任的连接。
证书是有效的，正确安装的，并由合法的证书颁发机构颁发，但这些设备拒绝了它。之前的证书有效。基础设施中没有其他任何变化。
根本原因分析
唯一的区别是链。新证书是在Sectigo的更新层次结构下使用R46中间证书颁发的。这个链是Sectigo根迁移过程的一部分。它是合规的，并被现代平台信任，但许多较旧的Android信任存储库不包含验证它所需的锚点。
Coppernic准确地识别了情况：
“似乎新的CA证书（R46）没有嵌入。“
他们尝试通过添加USERTrust证书来恢复兼容性，但这没有帮助。Android设备仍然拒绝链。问题不是服务器上缺少文件，而是设备本身上缺少兼容的信任路径。
在这一点上，问题从安装转向兼容性。
我们的诊断
我们的支持团队确认该行为与Sectigo的CA链迁移相匹配。从2025年中期开始，新证书默认在更新的层次结构下颁发，包括R46链。虽然有效并被现代平台信任，但该信任路径在许多较旧的Android信任存储库中不存在。
我们还澄清了添加诸如USERTrust之类的证书不会影响Android设备。Android完全根据其内部存储库验证信任。如果设备不识别颁发路径，任何服务器端更改都无法覆盖故障。
解决方案
实用的解决方案是使用交叉签名CA重新颁发证书。
在Coppernic联系Sectigo后，证书在交叉签名链下重新颁发，该链保留了到较旧但仍然受信任的根的路径。不需要基础设施更改。只调整了信任路径。
一旦部署了重新颁发的证书：
- Android 6.0.1设备正常连接。
- 桌面平台继续信任证书。
- 不兼容性立即消失。
这个案例很重要，因为它将问题隔离到单个变量。没有服务器迁移或链传递不一致。两个证书都是有效的，但只有一个在生产中可用。
Coppernic的经验显示了当证书颁发机构将其默认颁发向前移动时兼容性可能迅速崩溃。较新的信任路径并不自动是更广泛的路径。在仍然依赖传统Android设备群的环境中，它可能更窄且更脆弱。
设备如何决定是否信任证书
当设备检查SSL证书时，它从网站证书通过一个或多个中间证书到其信任存储库中已经存在的根证书构建信任路径。如果设备无法使用它信任的证书完成该路径，连接就会失败，即使证书本身是有效的。
Android在设计上是分片的。制造商发布不同的版本，更新时间表不同，许多设备在被替换之前很久就停止接收系统更新。手机可以在最后一次安全或信任存储库更新后保持活跃数年。从证书的角度来看，该设备变成了时间胶囊。
信任存储库存在于操作系统内部。如果操作系统不更新，信任存储库也不会更新。这意味着设备可以继续依赖几年前是最新的但不再与现代证书颁发机构如何颁发链保持一致的证书根和信任路径。
为什么这些问题难以诊断
标准SSL诊断确认证书有效、链完整、服务器正确提供。他们不验证的是生态系统中的每个客户端设备是否可以信任该链。
在我们的案例中，所有常规检查都通过了。SSL测试工具返回绿色结果，服务器配置正确，桌面浏览器正常工作而没有错误。从基础设施的角度来看，没有任何东西坏了。
故障发生在传统诊断范围之外。只有特定的设备类别（具有过时信任存储库的较旧Android版本）受到影响。因为大多数验证工作流程不包括设备级信任兼容性测试，所以问题保持不可见，直到真正的用户遇到它。这创造了一个诊断盲点：证书可能有效、正确安装且完全合规，但仍然对毫无戒心的用户抛出错误。
我们如何诊断问题
我们通过模式识别识别了问题。
当有效证书在桌面平台上工作但在特定移动环境中失败时，它指向远离服务器配置而转向信任存储库兼容性。除非你之前接触过CA迁移和平台级信任行为，否则这并不明显。
出现Android特定故障以及新引入的CA链立即缩小了调查范围。问题不再是“为什么SSL坏了”，而是“哪些信任存储库不再接受这个信任路径。”
这需要分离两个经常混淆的概念：
- 证书有效性（密码学正确性）
- 设备信任（平台接受）
认识到这种差异使我们能够快速准确地诊断问题。
我们提供的解决方案路径
一旦我们确认了信任兼容性问题，修复它就变成了策略而不是修复的问题。每个选项代表短期稳定性和长期与信任生态系统对齐之间的不同平衡。
- 使用传统链重新颁发：这立即恢复了与较旧Android设备的兼容性。这是消除面向用户错误和稳定生产流量的最快方法。
- 接受部分兼容性：某些环境选择优先考虑现代平台并接受较旧设备将遇到SSL错误。这简化了基础设施，但限制了受众范围。
- 切换到不同的证书颁发机构：迁移到另一个CA可以提供更长期的移动兼容性并减少对过渡信任链的依赖。
计划分阶段迁移：即使暂时使用传统链，也需要长期规划。基础信任模型将继续发展，网站管理员必须从结构上解决兼容性问题。
为什么重新颁发证书不是永久修复
使用传统或交叉签名链重新颁发推迟了兼容性问题；它没有消除它。这些链存在是为了桥接过渡，而不是取代现代信任路径。
随着证书颁发机构继续现代化其层次结构，较旧的中间证书和兼容性路径将被退休。当这种情况发生时，如果系统仍然依赖它们，相同的故障模式将返回。
因此，重新颁发是一个稳定器，而不是解决方案。它争取时间。长期稳定性需要与信任生态系统如何发展保持一致，而不是抵制它们。
这是两个案例研究背后的结构性教训。
最终想法：为什么”有效”证书在2026年仍然失败
这个案例展示了SSL/TLS在2026年的实际工作方式。证书颁发机构行动迅速。他们轮换链、现代化信任路径并响应新的安全要求。设备则不然。在智能手机上，许多用户仍然固定在落后于当前CA基础设施数年的信任模型上。
因此，“有效”不再自动意味着“可用”。
组织不应将SSL视为一次性设置。它必须作为以下各方之间的兼容性层进行管理：
- 证书颁发机构
- 操作系统
- 设备生命周期
- 用户环境
这意味着：
- 了解您的用户实际运行什么设备，而不仅仅是您测试的浏览器。
- 针对真实移动平台测试证书，包括较旧
