用 Opsx + AI + 阿里云 CLI 完成 SSL 证书定时自动轮换
SSL 证书管理的难点并不在某一次申请或部署，而在整个生命周期的持续维护。证书数量增加以后，到期时间、域名控制权验证、证书签发、CDN 部署和公网生效验证分散在不同系统中；任何一个环节出现遗漏，都可能直接造成 HTTPS 访问失败。 墨天轮维护着多个需要独立轮换证书的域名。阿里云当前的个人测试证书免费版有效期为 90 天，个人测试证书 Pro 的服务周期为 6 个月。综合域名数量与长期成本后，我仍然选择使用免费证书，但也因此需要承担更高频的轮换任务；目前仅墨天轮就维护着约 10 张 SSL 证书。 免费证书降低了采购成本，却把压力转移到了运维环节。90 天有效期意味着每个月都可能有不同域名进入更换窗口；依赖日历提醒和个人记忆，无法形成稳定的长期机制。 过去确实发生过几次证书到期导致网站无法正常访问的情况。其中一次发生在通勤途中，我只能临时在地铁站处理证书更换。这次紧急处置暴露的问题并非缺少某一条操作命令，而是从申请、验证、签发到部署和公网验收的完整流程仍需由人跨平台串联。 这些步骤包含多个异步状态。证书审核和签发有时需要等待 3～5 分钟，DNS 记录需要等待解析生效，CDN 下发也需要等待边缘节点更新。人工操作不仅要完成每个动作，还要反复返回不同平台确认上一阶段是否成功。流程越长，遗漏和误操作的风险越高。 因此，这次实践的目标不是临时完成一张证书的更换，而是用 Opsx + AI + 阿里云 CLI 管理完整的 SSL 证书轮换过程：提前确定目标 Asset、执行 Runtime 和操作步骤，在计划时间自动唤醒同一个 Issue、启动已经保存的执行 payload，并以公网 TLS 端点的实际结果作为最终验收依据。 证书规模扩大后，运维成本来自流程协同 人工更换一张证书，通常需要依次完成以下步骤。不同证书类型和部署平台会省略其中部分环节，但整体状态依赖基本一致： 发现即将到期 → 确认域名、当前证书和实际部署平台 → 购买或创建证书 → 等待平台受理 → 提交证书申请并绑定域名 → 直接申请，或提交包含目标域名与 SAN 信息的 CSR → 完成域名控制权验证 └── 域名在其他平台时，通常需要增加 DNS TXT 记录 → 等待审核与签发（可能需要 3～5 分钟或更长） → 选择直接创建云端部署任务 或下载证书与私钥，再上传到目标平台 → CDN 下发，或重新加载配置 / 重启应用 → 等待边缘节点或应用生效 → 从公网验证证书链和有效期 → 记录下一次到期时间 单个步骤本身并不复杂，但只有上一阶段进入正确状态以后，下一阶段才能继续。证书数量增加后，人工维护的问题会被进一步放大： ...