证书同步需通过Git+CI/CD实现自动化分发与回滚，校验权限、链完整性，生成带时间戳部署包并行推送，各机房Agent原子替换并reload Nginx，保留3版本软链接，嵌入HTTPS健康检查与熔断机制。
证书同步必须绕开人工操作
手动上传证书到每个机房的 Nginx 服务器，不仅耗时长、易出错，还无法满足“分钟级”要求。核心思路是把证书当作可版本化、可自动分发的配置资产，而非静态文件。这意味着证书私钥和公钥需统一纳管，分发过程需与部署流程解耦，且全程不可人工干预。
用 Git + CI/CD 驱动证书分发
将所有地域机房的 Nginx 证书（含 domain.crt、domain.key、fullchain.pem）按机房或集群维度组织进 Git 仓库（如：certs/beijing/、certs/shenzhen/）。每次证书更新（包括 Let’s Encrypt 自动续期后的新证书）都提交 PR → 自动触发 CI 流水线：
- 校验私钥权限（600）、证书链完整性（
openssl verify -CAfile fullchain.pem domain.crt） - 生成带时间戳与 Git SHA 的部署包（tar.gz）
- 并行推送到各目标机房的配置分发节点（如 Salt Master、Ansible Control Node 或自建轻量 Agent）
- 各机房 Agent 校验包签名后，原子替换
/etc/nginx/certs/下对应文件，并 reload Nginx
回滚要靠版本快照 + 状态隔离
每次成功部署均自动记录：机房标识、证书哈希、Nginx 配置 MD5、reload 时间戳、Git commit ID。回滚不是“重新上传旧文件”，而是调用幂等回滚指令：
- 执行
rollback --site=shenzhen --to=20240520-abc123 - Agent 拉取对应快照包，校验无误后还原证书+配置，再 reload
- 关键点：各机房证书目录保留最近 3 个版本（软链接
current/previous/backup），不依赖外部存储
健康检查与熔断必须嵌入分发链路
同步完成后不能只看 Nginx reload 是否成功，还需验证 HTTPS 实际可用性：
- 每台 Nginx 节点本地执行
curl -I --insecure https://$HOSTNAME --connect-timeout 3 - 任一节点 TLS 握手失败或返回非 2xx，则自动触发该机房暂停后续步骤，并告警
- 支持人工审批开关：若仅个别节点异常，可标记跳过，其余继续；全量失败则整批回滚
