cloudos5 证书过期如何更新
- 0关注
- 0收藏，33浏览
你遇到的 CloudOS E5103 证书过期导致平台无法登录，是一个已知的系统限制。在 E5131 之前的版本中，部分证书（包括可能长达5年的证书）到期后不会自动续期。
这导致在集群内部用于安全通信的关键证书失效，特别是 Harbor 镜像仓库的 CA 证书。该证书一旦过期，Kubernetes 节点将无法拉取管理 Pod 所需的容器镜像，从而使得 Web 管理界面也无法访问。
针对这个问题，证书的更新替换操作非常复杂且风险高，官方渠道明确建议联系技术支持处理。以下是一些初步的验证排查步骤和准备工作，在联系官方寻求解决方案前，可以作为参考。
🔍 第一步：应急验证与排查
紧急绕过（极度不推荐，仅作验证）
可以尝试将所有相关服务器的系统时间调回到证书过期前的日期。请注意，这只是权宜之计，用于快速验证问题，绝不能作为长期方案使用，且可能导致数据记录混乱。后台登录与日志检查
通过 SSH 登录到 CloudOS 的控制节点（Master 节点），检查系统日志以确认证书过期的详细信息。检查 Harbor 证书：执行
openssl x509 -in /etc/docker/certs.d/os-harbor-svc.default.svc:443/ca.crt -noout -dates，查看输出中的notAfter字段是否已过期。检查系统时间：执行
date命令，或使用chronyc sources或ntpq -p检查 NTP 同步状态，排除因系统时间错误导致的“假性”过期。
准备环境信息
为方便技术专家快速介入，可以提前收集好以下信息：集群详情：集群的节点数量、IP 地址等信息。
环境检查：确认在证书过期前，所有组件（尤其是 Harbor 镜像仓库）是否都运行正常。
🛠️ 第二步：证书更新操作步骤（高风险）
证书更新涉及整个集群的多个组件，任何操作失误都可能导致平台进一步受损。如果经过评估决定自行尝试，可以按以下高风险步骤操作：
备份与准备工作
备份所有节点：务必为所有涉及的 Master 和 Node 节点创建完整的系统快照或进行全量文件系统备份。这是操作失败后唯一能回滚的方式。
寻找有效新证书：在 Master 节点上，检查 Harbor 的持久化目录或 Kubernetes 的 Secret 资源中，是否存在新的、有效的证书文件。
证书替换与分发
手动替换证书：找到有效的新证书文件（如
new_ca.crt）后，将其复制并覆盖到报错路径下。操作前务必备份旧证书。分发至所有节点：更新后的证书必须分发到集群内所有节点的相同路径下，确保所有节点的 Docker 守护进程都能信任该证书。
重启 Docker 服务
在所有节点上执行systemctl restart docker命令，使新的证书配置生效。验证与确认
重启后，检查相关 Pod 是否恢复正常状态，并尝试再次访问 Web 管理界面，确认平台功能恢复。
暂无评论
一、前提与风险说明
- CloudOS 5.0 底层为 OpenShift/Kubernetes 容器平台，证书存于
/etc/origin/master/。 - 默认内置证书有效期 5 年，到期后所有 HTTPS 接口、API、Web UI 全部失效，无法登录。
- 必须在所有控制节点（Master 节点）执行，计算节点（Node）一般无需操作。
- 操作会重启平台核心服务，业务会中断，请在维护窗口执行。
二、准备工作（必做）
1. 登录所有 Master 节点
- 用 root 账号通过 SSH/Console 登录每台 Master。
- 确认角色：bash运行
hostname # 查看是否为 master 节点（通常带 -master、-m 后缀）
2. 备份旧证书（所有 Master 执行）
# 备份整个证书目录
cp -r /etc/origin/master/ /etc/origin/master_backup_$(date +%Y%m%d)
# 验证备份
ls -ld /etc/origin/master_backup*
3. 查看当前证书有效期（确认过期）
openssl x509 -in /etc/origin/master/master.server.crt -noout -dates
# 输出示例：
# notBefore=...
# notAfter=Apr 17 12:00:00 2021 GMT （已过期）
三、一键自动续期（官方标准方案，推荐）
1. 执行证书续期脚本（所有 Master 节点）
# CloudOS5 专用证书续期工具
/usr/local/bin/cert-renewal
- 执行成功无报错，日志默认写
/var/log/cert-renewal.log。
2. 重启 OpenShift Master 服务（所有 Master）
systemctl restart atomic-openshift-master-api
systemctl restart atomic-openshift-master-controllers
# 检查服务状态（确保active）
systemctl status atomic-openshift-master-api
systemctl status atomic-openshift-master-controllers
3. 验证新证书有效期
openssl x509 -in /etc/origin/master/master.server.crt -noout -dates
# notAfter 应变为 **当前时间 +5年**
4. 重启 CloudOS 所有服务（单台 Master 执行）
# 进入CloudOS运维工具目录
cd /opt/cloudos/osmanage/tools/
# 一键重启所有服务（耐心等待5~10分钟）
sh restart_all_service.sh
5. 验证 Web UI 登录
- 浏览器访问
https://CloudOS-IP - 清除浏览器缓存 / 无痕模式，正常登录即成功。
四、手动生成替换（自动脚本失败时备选）
1. 生成新证书（单台 Master）
# 进入证书目录
cd /etc/origin/master/
# 生成新密钥与CA（CloudOS5内置脚本）
oc adm ca create-master-certs \
--hostnames=CloudOS-IP,localhost,*.local \
--master-dir=/etc/origin/master/ \
--overwrite
2. 同步证书到所有 Master
# 把 /etc/origin/master/ 下所有 .crt/.key 拷贝到其他Master
scp -r /etc/origin/master/* root@其他Master-IP:/etc/origin/master/
3. 重复 “三、2~5” 重启服务并验证
五、常见问题与排错
1. 找不到 cert-renewal
- E5103 早期版本可能路径不同：bash运行
find / -name "cert-renewal" -type f # 可能在 /opt/xxx/bin/ 或 /usr/bin/ - 找不到则用手动生成方案。
2. 重启后仍无法登录
- 清除浏览器缓存、换浏览器、用无痕模式。
- 检查防火墙 / 安全组放通 443、8443 端口。
- 查看日志：bash运行
journalctl -u atomic-openshift-master-api -f
3. 提示证书不匹配
- 确保所有 Master 节点证书已同步，时间一致（NTP）。
六、一句话总结
/usr/local/bin/cert-renewal → 重启 Master 服务 → 重启 CloudOS 服务 → 即可恢复登录。暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论