富阳说：做 1000 个 AI 工具，让每个人享受 AI 便利。
HTTPS 证书续期不是一个复杂问题，但它经常变成线上事故。
原因也很简单：它低频、高风险、强依赖人的记忆。证书平时安静地工作，直到某一天过期，浏览器开始拦截访问，CDN 回源异常，用户看到安全警告，团队才想起来还有一张证书没有更新。
这类问题不应该靠“记得去控制台点一下”解决。更合理的方式，是把证书生命周期变成一条可审计、可重试、可告警的自动化流水线。
本文以开源项目 cert-auto 为例，分析如何利用 AI 配合 CI/CD，实现 HTTPS 证书的自动化签发、续期、上传和失败告警。
为什么证书续期适合自动化
证书续期具备几个典型特征：
这些特征说明，证书续期不适合依赖人工操作，但非常适合交给自动化系统。
人工处理时，流程通常是这样的：
一旦流程固定，就应该把它沉淀为代码；一旦需要定期执行，就应该交给 CI/CD。
cert-auto 的整体设计
cert-auto 是一个轻量级证书自动化项目。它没有复杂的后台服务，而是把证书管理拆成几个清晰部分：
它背后的核心思路是：
GitHub Actions 定时触发
|
v
安装 acme.sh 和 aic CLI
|
v
读取 GitHub Secrets 中的云服务配置
|
v
检查证书是否即将过期
|
v
执行 ACME DNS-01 续期
|
v
更新 CDN / CAS 证书
|
v
失败时发送微信告警
其中 aic CLI 负责封装 DNS、证书服务、CDN 等云平台 API；GitHub Actions 负责任务调度、运行环境和审计日志；AI 则适合辅助分析、生成配置、排查失败和维护文档。
CI/CD 如何完成自动化证书更新
在这个项目里，CI/CD 的作用不是简单“跑一个脚本”，而是把证书续期变成一个稳定的工程流程。
1. 定时触发
GitHub Actions 通过 schedule 定时运行续期任务，也支持 workflow_dispatch 手动触发。
这解决了证书续期最大的问题：不再依赖某个人记得去操作。
2. 并发控制
流水线配置了 concurrency，避免多个续期任务同时运行。
证书续期涉及 DNS 记录写入、ACME 验证、证书上传和绑定。如果多个任务并发执行，可能造成重复申请、覆盖上传或状态混乱。并发控制是这类自动化任务里很容易被忽视、但很重要的细节。
3. Secret 注入
项目使用 GitHub Secrets 保存 aic 配置，并在流水线中写入 ~/.config/aic/config.toml。
这样做的好处是：
证书自动化的第一原则是：不要为了自动化，把私钥和云服务凭据硬编码进仓库。
4. 先 dry-run，再正式执行
流水线先执行：
aic cert:renew --days 30 --dry-run
然后再执行正式续期：
aic cert:renew --days 30
这个设计值得保留。证书续期不是越频繁越好，而是应该在接近过期窗口时执行。dry-run 让流水线先判断“哪些证书需要更新”，再进入真正的变更步骤。
这也是自动化系统的重要原则：先观察，再修改。
5. 失败告警
自动化最怕的是“失败了但没人知道”。
项目在 GitHub Actions 失败时调用 aic notify:send 发送微信通知，把仓库、运行 ID 和 Actions URL 发给负责人。
这让证书续期形成闭环：
定时检查 -> 自动续期 -> 成功无需打扰 -> 失败立即告警 -> 人工介入修复
这比“定时跑脚本但没人看日志”可靠得多。
AI 在这里到底能做什么
AI 不应该直接替代 CI/CD，也不应该绕过权限系统去操作证书。更合理的定位是：AI 是自动化工程助手，CI/CD 是可靠执行器。
两者分工如下：
以 cert-auto 这类项目为例，AI 可以发挥很实际的作用。
例如，AI 可以检查脚本和配置是否一致。配置模板里可能使用 CERT_DOMAIN，脚本里却读取 DOMAIN。这类问题人工 review 容易忽略，但 AI 很适合做跨文件一致性检查。
再比如，README 里描述的是 Aliyun CAS 签发上传流程，而 GitHub Actions 当前主要执行 Qiniu CDN 证书续期。随着项目演进，文档和实现发生漂移很常见。AI 可以定期对比文档、脚本和 workflow，提醒维护者更新说明。
还有更典型的场景是失败日志诊断。ACME DNS-01 失败时，日志可能包含 DNS 传播延迟、TXT 记录未生效、API 权限不足、域名托管账号不匹配等原因。AI 可以把冗长日志总结成一句人能看懂的问题描述，再给出排查路径。
例如：
AI 的价值不是“自动点按钮”，而是把排查成本降下来，把工程一致性提上去。
安全边界：自动化不是放大权限
证书自动化处理的是敏感资产。这里既有云服务 API 凭据，也有证书私钥。如果设计不好，自动化系统会从“降低风险”变成“放大风险”。
建议遵守几条原则：
AI 可以帮助发现风险，但不能替代权限治理。真正可靠的系统，应该让 AI 提建议，让 CI/CD 执行经过审核的流程，让人负责边界和授权。
从自动化到智能化的演进路线
证书管理可以逐步演进，不需要一开始就做成复杂平台。
cert-auto 当前已经具备 L2 到 L4 的核心能力：定时运行、状态检查、自动续期和失败告警。下一步可以加入 AI 日志摘要、配置一致性检查和自动文档同步。
可以继续增强的方向
围绕当前项目，后续可以做几类增强：
其中，最值得优先做的是资产清单和 AI 日志摘要。
资产清单可以让所有证书目标结构化：
certificates:
- domain: static.example.com
provider: qiniu
dnsProfile: personal
renewBeforeDays: 30
owner: ops
有了结构化数据，CI/CD 可以按清单执行，AI 可以按清单分析风险，文档也可以自动生成。
总结
证书续期不应该是一次靠记忆完成的人工操作，而应该是一套持续运行的基础设施能力。
在这个过程中，AI 和 CI/CD 的关系不是替代，而是协作：
当证书签发、续期、上传和告警都进入流水线后，证书过期就不再是“某个人忘了”的事故，而是一个可以被系统提前发现、自动处理、失败告警的工程问题。
这才是 AI 配合 CI/CD 的正确姿势：AI 负责提升理解和修复效率，CI/CD 负责稳定执行，最终把低频高风险的运维任务变成可审计、可复现、可持续改进的自动化流程。
开源项目地址
本文示例项目 cert-auto 默认采用 MIT License 开源，代码地址如下：
https://github.com/daifuyang/cert-auto
项目用于演示如何通过 AI 辅助分析、CI/CD 定时执行、ACME DNS-01 签发和云服务 API 上传，实现 HTTPS 证书的自动化续期与告警闭环。