发布日期：2026-09-18 浏览次数：
PQC 迁移需要针对六种特定故障模式制定专门的事件响应流程，而非通用的故障处理手册：中间件或客户端不兼容导致的握手失败、不支持的证书被拒绝、CA 或供应商错误、HSM 签名或密钥可用性问题、生产负载下的性能下降以及信任链验证失败。每种故障模式都有不同的根本原因、不同的诊断路径和不同的回滚操作，如果将它们视为一个未加区分的“PQC 出现故障”事件类别，就会在最需要速度的时候拖慢响应速度。本文是针对所有六种故障模式的详细操作手册。
本文均已涵盖如何精心规划和测试 PQC 迁移。请注意：假设即使进行了周密的规划，生产环境中仍然出现了问题，因为在涉及如此庞大基础设施的多年迁移过程中，出现问题在所难免。应对措施必须与部署过程一样周密。
症状：在被认为是混合型基础设施上，TLS 连接完全失败，或者仅使用传统方式回退的意外激增。
诊断：首先检查协商算法遥测数据，以确认这是回退模式（客户端或中间件拒绝混合组）还是握手失败（更严重的兼容性问题）。确定故障是否与特定网络路径、客户端版本或中间件相关。
应对措施：对于中间件特有的问题，请对设备进行修补或重新配置。对于更广泛的客户端兼容性问题，请在确定根本原因期间暂停向受影响的客户端群体进一步部署混合模式。
症状：依赖方拒绝了预期能够成功验证的 PQC 或混合证书。
诊断：确认依赖方是否已按照分段规则，在颁发证书之前实际包含在您已验证的、准备就绪的分段中，或者这是否是一个真正的、以前未发现的兼容性差距。
应对措施：如果依赖方被错误地归类为“就绪”，请立即从传统层级结构中重新颁发受影响的证书，并更正分段数据。如果这是一个新的兼容性差距，则应将其视为一个信号，在进一步颁发证书之前，对该依赖方类别中的其余部分进行重新审核。
症状：颁发失败、验证失败或意外行为，且追溯到您的 CA 平台或特定供应商的 PQC 实现，而不是您自己的配置。
诊断：请对照供应商已知的错误列表或您自己的更改日志，确认所使用的具体固件或平台版本，因为在 2026 年，跨供应商的 PQC 支持还比较新，平台级别的错误是真实存在的，而不是理论上的。
应对措施：联系供应商支持渠道，提供具体的固件版本和可复现的故障模式。同时，如果并行层级平台本身出现故障，则将受影响证书类别的重新颁发路由回传统层级结构。
症状： HSM 平台上的 PQC 密钥类型出现签名操作失败、意外延迟峰值或密钥不可用等问题。
诊断：确认这是否专门影响 PQC 密钥类型，还是更广泛的 HSM 平台问题，并检查它是否与您在部署前基准测试中建立的吞吐量和并发阈值相关，这些阈值在我们的HSM 基准测试指南中有所介绍。
应对措施：如果问题与负载相关，请在解决容量问题的同时，限制受影响的 HSM 分区的证书颁发量。如果是固件级缺陷，请联系供应商支持；如果签名功能完全不可用，请在 HA 配置支持的情况下故障转移到备用 HSM，或者完全暂停该证书类别的颁发，以免出现不一致状态。
揽阁信息是Thales的重要合作伙伴，我们提供的 Luna HSM 已经在固件中支持 PQC 算法，并有成功的客户案例，欢迎联系我们获取更多资料。
症状：在实际生产量下出现的延迟或吞吐量下降，与 POC测试期间 观察到的任何情况都不同。
诊断：将当前指标与POC数据进行直接比较，以确认生产量是否真的超过了测试阈值，或者是否有其他因素发生了变化。
应对措施：如果访问量超过测试容量，则属于扩展性问题，应增加容量或降低发放速率，而非将其视为缺陷。如果性能下降但访问量并未相应增加，则应将其视为真正的性能退化，需要进行根本原因调查后再继续部署。
症状：证书链验证失败，尽管每个单独的证书看起来都已正确颁发。
诊断：确认整条链均为同质 PQC 链，因为混合了经典根链和 PQC 从属链的链无法提供真正的后量子保护，并且还可能根据依赖方的具体验证逻辑产生验证不一致，需确认信任锚分发已实际到达受影响的依赖方。
应对措施：如果信任锚分发存在问题，则这是分发问题，而非证书问题，请通过标准的信任锚推送机制上报。如果链本身格式错误或混杂不一致，则应将其视为证书颁发机构配置问题，需要在该层级进一步颁发证书之前立即进行调查。
在事件发生之前（而非发生期间），定义具体的、数值化的回滚触发条件：例如故障率阈值、特定的业务影响严重程度，或者未解决事件超过一定持续时间后自动触发回滚，而不是继续调查。预先授权意味着值班响应人员可以立即执行决策，而不是在事件发生过程中向上级申请批准，而后者往往是造成响应时间损失的主要原因。
在迁移上线生产环境之前，就应该构建这套包含六个类别的回滚方案，而不是等到第一次故障发生后才被动地编写。在回滚计划所需的整个期间，务必保持传统层级结构的完全运行，而不是部分停用。明确预先授权回滚触发条件，并在实际发生故障之前，针对每种故障模式至少进行一次桌面演练。
遵循本系列文章中涵盖的规范（包括发现、风险评分、实验室测试、试点验证和并行层级结构）构建的 PQC 迁移，仍然需要制定同样周密的计划来应对可能出现的故障。六种不同的故障模式，每种模式都有其自身的诊断路径和响应措施，能够将“PQC 出现故障”的恐慌转化为具体可执行的流程。预先授权回滚决策，并确保传统层级结构真正有效运行（而不仅仅是作为备用方案记录在案），才能保证该流程在真正需要时能够迅速发挥作用。
六种不同的故障模式，握手、证书、提供商错误、HSM 问题、性能和信任链，每一种都需要自己的诊断路径和回滚程序，而不是单一的通用响应。
只有当本系列文章中推荐的并行经典基础设施在迁移过程中始终保持完全运行，而不是部分停用时，回滚速度才会很快。
我们的 PKI 可观测性指南中介绍的协商算法可观测性能够快速进行诊断；如果没有它，每次事件发生后，您甚至都无法开始修复它，只能先重建实际发生的事情。
回滚决定应根据已定义的触发条件预先获得授权，而不是临时做出，这样就不会浪费响应时间去讨论是否要回滚。
为什么 PQC 迁移需要与一般 PKI 操作不同的事件响应流程？
因为故障模式与过渡、混合混合和纯 PQC 基础设施、中间盒和客户端不兼容、新的 HSM 和 CA 平台代码以及通用故障运行手册有关，所以无法清晰地映射到快速诊断和解决这些问题。
为什么回滚触发条件应该在事件发生之前定义，而不是在事件发生期间定义？
因为在事件发生过程中讨论是否回滚会耗费最宝贵的响应时间。预先授权的数值触发条件可以让值班人员立即执行决策，而无需在事件进行中向上级申请批准。
当真正需要回滚计划时，最常见的失败原因是什么？
传统体系在尚未完全安全退役之前就被部分拆解。一项回滚计划的有效性取决于其所依赖的传统体系是否仍然真正有效运转。
如何区分中间件兼容性问题和真正的握手失败？
协商算法遥测：回退到仅经典协商的比率上升表明中间盒或客户端专门拒绝混合组，而完全握手失败且没有成功回退则表明存在更严重的兼容性问题。
是否应该在实际需要之前测试事件响应程序？
是的。在实际事故中依赖应急预案之前，针对六种失效模式中的每一种至少进行一次桌面演练，可以在风险较低的时候发现预案本身的漏洞。
揽阁信息 · 值得您信赖的信息安全顾问！
沪公网安备31011202021337号 网站地图
友情链接： Thales官网 芯片产品网站 服务热线
