CloudOS 的master.server.crt过期怎么替换

CloudOS E5132 master.server.crt 过期完整替换 / 续期方案
CloudOS E5132 底层基于 OpenShift，证书路径统一为/etc/origin/master/master.server.crt/master.server.key，分官方一键自动续期（推荐）、手动替换自有 CA 证书两套方案，集群所有 Master 节点均需操作。
前置检查（先确认过期状态）
bash
运行
# 查看证书过期时间
openssl x509 -in /etc/origin/master/master.server.crt -noout -dates
# 查看证书续期日志
cat /var/log/cert-renewal.log
方案一：官方内置脚本一键续期（优先，自动生成 5 年新证书，适配原生集群）
步骤 1：所有 Master 节点执行备份（必做）
bash
运行
cp -r /etc/origin/master /etc/origin/master_bak_$(date +%Y%m%d)
步骤 2：执行系统自带证书续期工具（所有 Master）
bash
运行
/usr/local/bin/cert-renewal
脚本会自动：
生成新的master.server.crt/master.server.key替换过期文件
更新 apiserver、controller、aggregator 代理全套配套证书
输出成功无报错即证书文件替换完成
步骤 3：重启 OpenShift 核心服务生效（所有 Master）
bash
运行
systemctl restart atomic-openshift-master-api
systemctl restart atomic-openshift-master-controllers
# 校验服务正常running
systemctl status atomic-openshift-master-api
systemctl status atomic-openshift-master-controllers
步骤 4：验证新证书有效期
bash
运行
openssl x509 -in /etc/origin/master/master.server.crt -noout -dates
# notAfter 自动延长5年，代表续期成功
步骤 5：配置自动定时续期（预防再次过期）
bash
运行
# 启用每月自动续期定时器
cat > /etc/systemd/system/cert-renewal.timer <<EOF
[Unit]
Description=Monthly CloudOS cert renew timer
[Timer]
OnCalendar=*-*-01 02:00:00
Persistent=true
[Install]
WantedBy=timers.target
EOF
systemctl daemon-reload
systemctl enable --now cert-renewal.timer
# 查看定时任务
systemctl list-timers | grep cert-renewal
方案二：手动替换企业自有 CA 颁发证书（客户自建根证书场景）
适用于需要统一企业 CA、不使用系统自签证书场景：
1、上传新证书到所有 Master
新文件命名必须严格匹配：
公钥证书：master.server.crt
私钥：master.server.key
上传至/etc/origin/master/目录，修复权限
bash
运行
# 权限必须匹配系统要求
chmod 600 /etc/origin/master/master.server.*
chown root:root /etc/origin/master/master.server.*
2、重启核心服务（同方案一）
bash
运行
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
3、全节点同步证书（集群多 master 场景）
证书替换后需同步到所有计算 / 存储节点/etc/origin/node/相关客户端证书，否则节点无法接入集群。
三、故障排查（续期失败常见问题）
执行 cert-renewal 报错权限不足
全程使用 root 用户操作，禁止普通账号执行。
续期后页面依旧提示证书过期
浏览器清除缓存、清空浏览器证书缓存；或重启前端 tomcat 服务：
bash
运行
oscctl service restart tomcat
服务启动失败，证书校验异常
回滚备份目录恢复旧证书：
bash
运行
rm -rf /etc/origin/master
mv /etc/origin/master_bak_$(date +%Y%m%d) /etc/origin/master
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
集群节点离线、无法通信
所有 Master 必须同步完成证书替换，单节点更新会导致节点间 TLS 握手失败。
极简操作总结
集群所有 Master 先备份证书目录；
优先执行/usr/local/bin/cert-renewal一键续期原生证书；
重启atomic-openshift-master-api/controller服务加载新证书；
验证证书有效期，配置每月自动续期避免再次过期；
自有企业 CA 证书需手动上传同名 crt/key，严格修复文件权限。

针对 CloudOS E5132 版本 master.server.crt 证书过期的问题，因为该版本默认不支持自动续签，所以需要手动操作。

根据官方社区的经验，证书替换是一个高风险操作，务必谨慎。以下是整理的完整手动续签步骤。

⚠️ 操作前的重要准备

在开始任何操作前，务必备份，这是失败后唯一能回滚的方式。

1. 创建虚拟机快照：为所有 Master 节点虚拟机创建快照。

2. 备份证书目录：在所有 Master 节点上执行，备份整个证书目录。

   bash

   cp -r /etc/origin/ /etc/origin_backup_$(date +%Y%m%d) cp -r /var/lib/origin/ /var/lib/origin_backup_$(date +%Y%m%d)

3. 备份 etcd 数据：证书续签依赖 etcd，这是核心步骤。

   bash

   etcdctl backup -->$(date +%Y%m%d)

📝 手动续签操作步骤

请在所有 Master 节点上依次执行以下步骤。

1. 执行证书续签命令

使用 CloudOS 自带的专用脚本续签所有即将过期的 Master 证书。

2. 检查续签日志

执行后，必须检查日志，确认续签是否成功。

当日志中出现 All certificates renewed successfully 字样，才表示续签成功。

3. 重启所有相关服务

证书续签后，需要重启所有依赖这些证书的服务，才能使新证书生效。

如果操作后 Web 界面仍无法访问，可以尝试重启 master-api 和 master-controllers 服务。

4. 验证新证书有效期

确认输出的 notAfter 时间已经更新为未来时间。

🚨 操作风险与最终建议

证书更新涉及整个集群的多个组件，如果操作不当，可能导致平台无法访问。

• 风险评估：此操作存在较高风险，尤其是之前未进行过证书续签的集群，可能出现预期外的问题。

• 官方支持：鉴于操作的高风险性，最稳妥的方式是优先联系 H3C 技术支持（400热线或客户代表）。他们拥有标准操作流程（SOP）和应急处理经验，能最大程度保障业务安全。

• 终极回滚：如果手动续签失败且无法恢复，唯一可靠的回滚方式是恢复之前创建的虚拟机快照