手动修改时间使证书过期，BMC不可用且无法恢复

kunlun-zht · 2026 年2 月 10 日 11:48

【问题背景】
2509版本，导入自定义SSL证书，测试用户修改系统时间到一个100年后的时间后，提示证书过期，等一段时间后BMC自动重启；
【问题现象】
重启起来后可以连接BMC的ssh，可以修改系统时间到正常时间，修改后BMC仍无法正常工作，会反复重启，且很多功能都无法使用，无法恢复环境，无法升级，无法导入新的证书…
【日志】

ubmc_assistant · 2026 年2 月 10 日 11:55

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

结论

本问题的根本原因是人为修改系统时间为未来时间，导致SSL证书被判定为过期，进而引发BMC核心服务初始化失败，系统进入“健康检查失败 → 强制重启”循环。即使时间改回，由于持久化状态未清除，系统无法恢复正常。

最终解决方案是：清除持久化数据库 → 重设时间 → 重新导入证书 → 重启系统，可彻底恢复功能。

相关讨论可参考论坛链接：
关于更新BMC导入证书的问题
 https://discuss.openubmc.cn/t/topic/2489

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

手动修改证书时间导致BMC反复重启且无法恢复的解决方案

问题背景

在 BMC 25.09 版本系统中，用户导入了自定义的 SSL 证书后，为了测试证书过期机制，手动将系统时间设置为100年后的未来时间。这一操作导致：

SSL证书被判定为已过期；
BMC提示证书异常；
随后BMC自动重启；
重启后虽可连接SSH，且能将系统时间调回当前正常时间；
但BMC仍持续反复重启，功能无法正常恢复；
无法升级固件、无法重新导入证书，系统陷入不可用状态。

核心问题分析

从提供的日志信息可以看出，BMC重启后进入了一种“初始化失败 → 强制重启”的循环，关键线索如下：

[certificate]StartupCheck failed, error: intialization is not complete while checking the startup status, status: Starting...
[iam]StartupCheck failed...
[key_mgmt]StartupCheck failed...
["account","certificate","iam","key_mgmt"] —— 异常组件列表

这表明多个核心服务（包括证书、账户管理、密钥管理、身份认证）未能完成初始化。

最终，系统输出：

Force Reset begin
BMC reset type: normal system

说明系统因健康检查失败，触发了强制重启。

同时，用户尝试操作时收到权限错误：

"It's not allowed to operate the specified file because the file owner is different from current user."

这暗示了文件系统权限或用户身份环境异常，可能与证书或系统状态损坏有关。

问题原因总结

证书时间错乱引发信任链崩溃
将系统时间设为未来100年，使现有证书看似“已过期”，BMC的 CertificateService 服务拒绝加载该证书，导致 Nginx、WebUI、Redfish 等依赖安全通信的服务无法启动。
证书服务未正常初始化，触发系统健康检查失败
BMC系统中的 maca（Management Component Assurance Agent）会监控各核心服务的启动状态。certificate 服务未就绪会导致整个系统判定为“未完成初始化”，从而触发自动强制重启。
数据库或持久化数据未清理，旧状态残留
即使时间改回正常，BMC可能仍从持久化数据库（如 /data/trust/persistence/per_poweroff.db）中读取到“证书无效”或“系统异常”的状态标记，导致恢复失败。
文件权限不一致导致操作被拒
提示“文件所有者与当前用户不同”，可能是由于：
- 证书文件由某个特定用户（如 root）上传，当前登录用户权限不足；
- 或文件系统挂载异常，ACL/UID 映射错误；
- 或是在异常关机后，部分服务未正确重置权限模型。

解决方案

方法一：清除持久化数据库并重建安全环境（推荐）

适用场景：系统反复重启、证书服务无法启动、升级/导入失败。

步骤如下：

通过串口或SSH登录BMC系统（使用root权限）

备份并删除持久化数据库

mv /data/trust/persistence/per_poweroff.db /data/trust/persistence/per_poweroff.db.bak

重启BMC核心服务

killall skynet
# 或执行完整重启
reboot

系统重启后，重新配置IP与时间

设置当前正确时间（防止证书校验再次失败）：
```
date -s "2025-04-05 10:00:00"
```

重新导入SSL证书
将证书（如 SSL.p12）上传至 /tmp 目录，然后执行导入命令：

busctl --user call bmc.kepler.trust \
  /bmc/kepler/CertificateService \
  bmc.kepler.CertificateService.ImportCertWithKey \
  a{ss}sss 3 Interface Busctl UserName Administrator ClientAddr 127.0.0.1 \
  URI /tmp/SSL.p12 'your_password'

重启BMC以激活配置
```
reboot
```

参考依据：根据知识库中的《openUBMC300 V3问题定位分享》文档，删除数据库可恢复因证书丢失或损坏导致的BMC不可用状态。

方法二：尝试修复文件权限后重新导入证书

适用前提：系统可登录，但提示“文件所有者与当前用户不同”。

步骤如下：

检查当前用户和文件属性：
```
whoami
ls -l /tmp/SSL.p12
```
修改文件所有者为当前用户（通常是 root 或 Administrator）：
```
chown root:root /tmp/SSL.p12
chmod 600 /tmp/SSL.p12
```

再次尝试导入证书：

busctl --user call bmc.kepler.trust \
  /bmc/kepler/CertificateService \
  bmc.kepler.CertificateService.ImportCertWithKey \
  a{ss}sss 3 Interface Busctl UserName Administrator ClientAddr 127.0.0.1 \
  URI /tmp/SSL.p12 ''

若此方法失败，仍建议采用方法一进行彻底清理。

方法三：使用默认恢复机制重置BMC状态

如果上述方法仍无效，可尝试：

删除升级环境密钥（可能影响权限上下文）：

rm /data/opt/bmc/upgrade/profile_en
rm /data/opt/bmc/upgrade/profile_en.bak

重启 bmc_core 服务：
```
systemctl restart bmc_core
```

参考自《升级常见问题指南》中关于升级失败与服务异常的处理方式。

预防措施建议

措施	说明
禁止随意修改系统时间	尤其避免大幅跳变（±数年以上），会破坏证书、日志、审计链
测试证书过期应使用短有效期证书	而非修改系统时间，例如签发有效期仅5分钟的测试证书
升级前备份证书与数据库	可快速回滚至正常状态
确保导入证书前时间正确	建议在导入证书前执行时间同步或手动校准

结论

本问题的根本原因是人为修改系统时间为未来时间，导致SSL证书被判定为过期，进而引发BMC核心服务初始化失败，系统进入“健康检查失败 → 强制重启”循环。即使时间改回，由于持久化状态未清除，系统无法恢复正常。

最终解决方案是：清除持久化数据库 → 重设时间 → 重新导入证书 → 重启系统，可彻底恢复功能。

相关讨论可参考论坛链接：
关于更新BMC导入证书的问题
 https://discuss.openubmc.cn/t/topic/2489

话题		回复	浏览量
社区版本BMC导入SSL证书失败交流互助区提问求助	10	272	2026 年1 月 14 日
UBMC无法再次更新固件交流互助区提问求助	8	77	2026 年3 月 23 日
h5 kvm打不开，报设置信任证书超时，无法开启kvm 交流互助区提问求助	12	88	2026 年3 月 27 日
关于更新BMC导入证书的问题交流互助区提问求助	12	202	2025 年6 月 19 日
自签名的openubmc版本不保留配置升级后，web页面提示拒绝连接交流互助区提问求助	9	146	2025 年11 月 18 日

手动修改时间使证书过期，BMC不可用且无法恢复

结论

手动修改证书时间导致BMC反复重启且无法恢复的解决方案

问题背景

核心问题分析

问题原因总结

解决方案

方法一：清除持久化数据库并重建安全环境（推荐）

步骤如下：

方法二：尝试修复文件权限后重新导入证书

步骤如下：

方法三：使用默认恢复机制重置BMC状态

预防措施建议

结论

相关话题