【求助】掉电重启后，SSL证书概率性失效

Security SIG
1

问题描述

1，生产组装过程中，先升级V3版本，然后导入SSL证书，SSL证书导入成功后，WEB可正常登录；

2，掉电重启后概率性出现证书失效，WEB无法登录，再次导入SSL证书后，恢复正常。

环境信息

  • 操作系统：[RTOS]

  • 软件版本：[OpenUBMC2512]

  • 硬件配置：[略

重现步骤

  1. [第一步] BMC从V2升级到V3

  2. [第二步] 导入SSL证书，验证WEB是否可正常登录

  3. [第三步] 掉电重启，升级BMC、BIOS、模组CPLD固件。

  4. [第四步] 验证WEB是否可正常登录，此时发现WEB无法正常登录。

期望结果

期望能够在第一步导入证书后，掉电重启，WEB仍可正常登录。

实际结果

导入证书，升级BMC、BIOS、模组CPLD等固件后，WEB概率性无法登录

尝试过的解决方案

导入证书，升级BMC、BIOS、模组CPLD等固件后，再次导入证书。

分析结论

出现证书失效后，再次导入证书后，再次掉电重启不会出现该问题。

2

答案内容由AI生成，仅供参考：

总结与建议

您观察到的“再次导入证书后，再次掉电重启不会出现该问题”，是因为手动导入证书的过程会强制更新系统内的密钥和证书存储，使其建立正确的匹配关系，从而覆盖了之前升级流程中留下的错误状态。

解决方案建议（参考知识库 reference_id: "1" 中的解决方案）：

要根本解决此问题，需要修改BMC固件中的**key_mgmt组件**。在“恢复出厂设置”的回调函数（on_recover）中，增加以下逻辑：

  1. 删除旧路径下的备份密钥文件：/data/trust/ksf/datatocheck_bak.dat
  2. 删除新路径下的备份密钥文件：/data/backup/ksf/datatocheck_bak.dat

这样做的目的是：让BMC根系统初始化时，重新生成一个全新的、同步的密钥文件，而不是加载一个来自旧版本的、不匹配的备份文件。从而确保key_mgmt启动后，加载的密钥一定是最新且与证书匹配的。

临时解决方案：您目前采用的“再次导入证书”是一个有效的临时恢复手段。在进行批量生产时，可以将其作为标准操作流程的一部分，即在所有固件升级完成后，统一执行一次SSL证书的导入操作，以确保所有设备的证书与密钥状态一致。

点击此处查看详细分析解答

好的，根据您提供的系统环境（OpenUBMC2512）和问题描述，结合知识库中的信息，对“掉电重启后SSL证书概率性失效”的问题分析如下。

问题核心分析

您遇到的问题，核心在于不保留配置的固件升级流程或系统初始化过程中，SSL证书的密钥（Key）与存储的证书密文不匹配，导致系统启动时无法正确解密证书，从而引发web登录失败。

知识库中一个高度相似的案例（文档 reference_id: "1"）详细描述了此类问题的根本原因：
在“不保留配置升级”或恢复出厂设置后，系统在重新加载密钥文件时，可能加载了旧版本或错误的备份密钥文件，而非与当前证书匹配的正确密钥，最终导致证书解密失败。

根本原因链条

根据您描述的重现步骤（V2升级V3 → 导入证书 → 掉电重启/升级固件 → WEB概率性失效），我们可以将原因分解为以下几点：

  1. 升级过程的配置重置：从V2升级到V3，特别是涉及到BIOS、CPLD等底层固件升级时，通常会伴随BMC系统的“不保留配置升级”或恢复出厂设置。这个过程会重置系统配置，包括与证书加密相关的密钥存储路径和数据库。

  2. 密钥文件路径错乱：根据知识库（reference_id: "1"），在升级流程中，备份密钥文件可能被还原到一个旧的路径（如/data/trust/ksf/datatocheck_bak.dat），而当前版本期望的路径是新的（如/data/backup/ksf/datatocheck_bak.dat）。当系统启动时，key_mgmt组件会同时加载主文件和备份文件进行比对。

  3. 密钥版本不匹配：由于备份文件被还原到了旧路径，而该旧路径下的文件可能是升级前的版本，其密钥更新次数可能更高。系统会错误地选择加载这个旧版本、且不匹配的密钥文件，而不是升级后生成的正确密钥。

  4. 证书解密失败：使用这个不匹配的密钥去解密升级前导入的、并使用新密钥加密的SSL证书，必然会导致解密失败。这正是您日志中可能出现的 Failed to import the public key 或 Failed to import the certificate 错误的根本原因。

  5. 概率性复现：该问题之所以是“概率性”的，是因为密钥文件的加载行为依赖于升级过程中的具体路径还原情况。在大多数情况下，升级流程可能正确执行，但某些边界条件（如存储介质写入延迟、时间竞态）会触发上述的路径错乱问题。

总结与建议

您观察到的“再次导入证书后，再次掉电重启不会出现该问题”，是因为手动导入证书的过程会强制更新系统内的密钥和证书存储，使其建立正确的匹配关系，从而覆盖了之前升级流程中留下的错误状态。

解决方案建议（参考知识库 reference_id: "1" 中的解决方案）：

要根本解决此问题，需要修改BMC固件中的**key_mgmt组件**。在“恢复出厂设置”的回调函数（on_recover）中，增加以下逻辑：

  1. 删除旧路径下的备份密钥文件：/data/trust/ksf/datatocheck_bak.dat
  2. 删除新路径下的备份密钥文件：/data/backup/ksf/datatocheck_bak.dat

这样做的目的是：让BMC根系统初始化时，重新生成一个全新的、同步的密钥文件，而不是加载一个来自旧版本的、不匹配的备份文件。从而确保key_mgmt启动后，加载的密钥一定是最新且与证书匹配的。

临时解决方案：您目前采用的“再次导入证书”是一个有效的临时恢复手段。在进行批量生产时，可以将其作为标准操作流程的一部分，即在所有固件升级完成后，统一执行一次SSL证书的导入操作，以确保所有设备的证书与密钥状态一致。

3

这个问题需要提供下一键收集日志辅助定位，ssl证书是掉电持久化的数据，正常来说只要导入证书后是不会损坏ssl证书的，掉电重启后登录不了web页面，需要排查下web_backend、nsm组件是否正常启动，并且nginx服务被正常拉起

4

请问，这个问题有解决方案吗？