SSL 证书管理的难点并不在某一次申请或部署，而在整个生命周期的持续维护。证书数量增加以后，到期时间、域名控制权验证、证书签发、CDN 部署和公网生效验证分散在不同系统中；任何一个环节出现遗漏，都可能直接造成 HTTPS 访问失败。

墨天轮维护着多个需要独立轮换证书的域名。阿里云当前的个人测试证书免费版有效期为 90 天，个人测试证书 Pro 的服务周期为 6 个月。综合域名数量与长期成本后，我仍然选择使用免费证书，但也因此需要承担更高频的轮换任务；目前仅墨天轮就维护着约 10 张 SSL 证书。

Opsx 资产中记录的证书提供商与到期时间

免费证书降低了采购成本，却把压力转移到了运维环节。90 天有效期意味着每个月都可能有不同域名进入更换窗口；依赖日历提醒和个人记忆，无法形成稳定的长期机制。

过去确实发生过几次证书到期导致网站无法正常访问的情况。其中一次发生在通勤途中，我只能临时在地铁站处理证书更换。这次紧急处置暴露的问题并非缺少某一条操作命令，而是从申请、验证、签发到部署和公网验收的完整流程仍需由人跨平台串联。

这些步骤包含多个异步状态。证书审核和签发有时需要等待 3～5 分钟，DNS 记录需要等待解析生效，CDN 下发也需要等待边缘节点更新。人工操作不仅要完成每个动作，还要反复返回不同平台确认上一阶段是否成功。流程越长，遗漏和误操作的风险越高。

因此，这次实践的目标不是临时完成一张证书的更换，而是用 Opsx + AI + 阿里云 CLI 管理完整的 SSL 证书轮换过程：提前确定目标 Asset、执行 Runtime 和操作步骤，在计划时间自动唤醒同一个 Issue、启动已经保存的执行 payload，并以公网 TLS 端点的实际结果作为最终验收依据。

证书规模扩大后，运维成本来自流程协同

人工更换一张证书，通常需要依次完成以下步骤。不同证书类型和部署平台会省略其中部分环节，但整体状态依赖基本一致：

发现即将到期
  → 确认域名、当前证书和实际部署平台
  → 购买或创建证书
  → 等待平台受理
  → 提交证书申请并绑定域名
  → 直接申请，或提交包含目标域名与 SAN 信息的 CSR
  → 完成域名控制权验证
      └── 域名在其他平台时，通常需要增加 DNS TXT 记录
  → 等待审核与签发（可能需要 3～5 分钟或更长）
  → 选择直接创建云端部署任务
     或下载证书与私钥，再上传到目标平台
  → CDN 下发，或重新加载配置 / 重启应用
  → 等待边缘节点或应用生效
  → 从公网验证证书链和有效期
  → 记录下一次到期时间

单个步骤本身并不复杂，但只有上一阶段进入正确状态以后，下一阶段才能继续。证书数量增加后，人工维护的问题会被进一步放大：

  • 到期时间分散，依赖人工提醒存在遗漏风险；
  • 同一个域名可能关联 CDN、OSS 或其他云资源；
  • 控制台中存在大量证书 ID 和资源 ID，选错对象的风险高；
  • DNS 验证、签发和 CDN 部署是异步过程，需要反复等待和检查；
  • 云端显示部署成功，不代表公网边缘已经加载新证书；
  • 操作经验通常只在维护者个人记忆中，下次还要重新查一遍。

传统工具分别解决提醒、云端操作和到期告警，却没有持续持有资产关系、执行状态和验证结果的统一中枢，跨系统衔接仍然依赖人工完成。

Opsx 不替代阿里云提供证书和 CDN 能力，而是把云资源、执行工具、人工 Gate 与未来任务组织到同一套资产关联的运维状态中。

Opsx 先确定要换哪一张、部署到哪里

2026 年 7 月 22 日，Opsx 通过阿里云 CAS 检查证书，发现 js-cdn.modb.cc 当前证书将在 8 月 1 日到期。

如果输入仅有“更换 CDN 证书”这一自然语言目标，LLM 仍需自行推断云账号、域名、资源和执行环境。这类推断不能直接进入生产操作。

在 Opsx 中，issue_84 明确绑定生产 CDN Asset cdn-js-modb-cc。Asset 保存域名、HTTPS 状态和云资源身份，并关联可以执行云操作的 Runtime；mes-agent-01 已经具备阿里云 CLI 能力和受控 profile。

Issue：未来更换 js-cdn.modb.cc 证书
  │
  └── Asset：cdn-js-modb-cc
        ├── 环境：production
        ├── 类型：CDN cloud resource
        ├── HTTPS 与证书状态
        └── Runtime：mes-agent-01
              └── aliyun CLI / CAS / CDN

Opsx 先解析准确 Asset，再根据 Asset-to-Runtime mapping 路由执行，避免由 LLM 推断哪台主机具备云账号访问能力。Issue 则保存当前证书事实、目标、计划时间、执行过程和最终结论。

这体现了 Landing Page 所说的 Asset-Grounded：只有资产身份、关系、环境和 Runtime 都明确以后，一句自然语言需求才会变成可执行任务。

用 AI 完成首次云端流程探索

首次建立这条链路时，核心复杂性来自阿里云 CAS、证书申请和 CDN 部署之间的接口关系。

Claude Code 通过 Opsx 在正确 Runtime 上读取阿里云 CLI 帮助并进行只读查询，逐步确认：

  • 当前证书的状态和到期时间；
  • 免费 DV 证书对应的申请接口；
  • 单域名直接申请与 CSR 申请两条路径的差异；
  • 域名验证应该自动完成，还是返回 DNS TXT 记录等待确认；
  • 证书签发状态的查询方式；
  • CAS 如何创建面向 CDN 的 deployment job；
  • CDN 域名对应的实际云资源；
  • 部署任务如何启动、轮询和判断成功。

这类探索性工作适合由 Agent + LLM 承担：读取命令帮助，理解多个 API 的前后依赖，并根据真实返回持续修正执行计划。完全依赖人工时，需要反复在文档、控制台和终端之间切换。

AI 得出的流程不能只保留在一次对话中。Opsx 将每一步的输入、返回和判断保存在 Issue；确认后的动作再整理为 Shell，使后续执行不依赖当时使用的 Claude Code 或特定 LLM。

域名验证是申请阶段需要按环境分支的步骤之一。域名与证书服务位于同一云平台、并且 Runtime 具备相应权限时，可以直接完成自动验证；域名托管在其他云平台时，CAS 会返回需要添加的 DNS TXT 记录。维护者完成记录添加后，Opsx 即可继续查询验证和签发状态，后续部署与公网验收仍沿同一个 Issue 推进。

Asset 确定证书、域名、CDN 资源和 Runtime
  → 阿里云 CLI 创建并提交证书申请
  → 验证域名控制权
      ├── 同一云平台：自动验证
      └── 其他云平台：添加 DNS TXT 记录后继续
  → Shell 轮询审核与签发状态
  → 创建并启动 CDN deployment job
  → 轮询部署结果
  → 从公网验证实际证书
  → 将结果写回 Issue，并沉淀为 Playbook

Agent 负责处理复杂的探索任务，LLM 提供推理能力；Opsx 持有资产、上下文、证据和状态。即使更换 Agent 或模型，已经验证的证书维护流程仍可继续复用。

阿里云 CLI 将云端变更转化为确定性步骤

阿里云 CLI 为这条链路提供了可自动执行的云端操作接口。

如果只使用网页控制台，实际操作仍然依赖人的在线会话，而且页面变化会影响操作步骤，难以将执行过程可靠地交给未来任务。

CLI 把云端操作变成有明确输入和输出的步骤：

set -eu

: "${CERT_ID:?missing CERT_ID}"
: "${CDN_RESOURCE_ID:?missing CDN_RESOURCE_ID}"
: "${CONTACT_ID:?missing CONTACT_ID}"

JOB_JSON=$(
  "$ALIYUN" cas create-deployment-job \
    --job-type user \
    --cert-ids "$CERT_ID" \
    --resource-ids "$CDN_RESOURCE_ID" \
    --contact-ids "$CONTACT_ID" \
    --profile "$ALIYUN_PROFILE"
)

JOB_ID=$(printf '%s' "$JOB_JSON" | jq -r '.JobId')
test -n "$JOB_ID" && test "$JOB_ID" != "null"

"$ALIYUN" cas update-deployment-job-status \
  --job-id "$JOB_ID" \
  --status scheduling \
  --profile "$ALIYUN_PROFILE"

脚本可以检查每个状态：没有证书 ID 就不创建部署任务，没有 Job ID 就不启动，部署任务失败就停止，成功以后再进入公网验证。创建 deployment job 后还必须显式把状态切换到 scheduling，否则任务可能停留在编辑态。相同输入按相同规则执行，比在计划时间临时调用 LLM 操作控制台更可预测，也不消耗推理 Token。

另一个安全边界来自 CAS 返回值：describe-certificate-state 的完整响应可能包含证书和私钥，正式流程只解析状态与 CertId，不能把原始响应打印进 Issue、Execution 或 Knowledge。

云凭据、联系人和资源 ID 不应该直接写在文章或公开脚本里。它们由 Runtime Secret、环境变量或受控 CLI profile 提供，执行范围由 Workspace、Asset 和 Runtime 共同约束。

阿里云 CLI 使 Opsx 能够同时触达 CAS 与 CDN，消除两个云产品之间的人工操作断点。它不是附属工具，而是 Agent 与 Shell 操作真实云资产的确定性执行接口。

issue_84：先验证一次定时启动的半自动轮换

发现证书还有十天到期时，我没有立即更换，也没有只在手机日历里增加一个提醒。我直接在 Opsx 创建了 issue_84，把执行时间设为 2026 年 7 月 31 日 11:00（Asia/Shanghai）。

为了解决这类“现在规划、未来变更”的任务，Opsx 的 Issue 支持保存 scheduled_at 和 scheduled_execute_payload：不仅记录未来时间，还同时保存计划触发后使用的 Runner、目标 Asset、命令和超时边界。

7 月 22 日
  → 发现证书即将到期
  → 确认 CDN Asset 和 Runtime
  → AI 调查并准备完整流程
  → 创建带执行 payload 的定时 Issue

7 月 31 日 11:00
  → Opsx 自动唤醒同一个 Issue
  → 自动向 mes-agent-01 派发 Shell
  → 完成域名验证后继续轮询签发状态
  → CDN 部署及公网验证完成后关闭 Issue

实际事件验证了这条调度链：2026 年 7 月 31 日 11:00:00，Opsx 按计划唤醒 issue_84，并自动把保存的 Shell payload 派发到 mes-agent-01。证书最终完成签发和 CDN 部署，Issue 在当天 12:16 完成并关闭，公网边缘返回的新证书有效期至 2026 年 10 月 28 日。

issue_84 验证了未来时间、目标 Asset、Runtime 和 payload 能够被平台保存并准时启动，但本次域名托管在其他平台，仍需人工增加 DNS TXT 记录。因此它属于半自动实践：Opsx 接管资产定位、定时触发、状态查询、CDN 部署和公网验收，人在域名验证处完成一次确认。更重要的是，这次执行验证了每个云端步骤、状态判断和验收标准，为后续全自动轮换提供了确定性流程。

这与周期 Schedule 也不同。证书更换发生在一个明确日期，是一次有状态的变更；日常证书到期巡检才更适合周期 Schedule。本案例已经验证定时 Issue 在计划窗口启动具体更换，持续发现即将到期证书的周期 Schedule 仍是下一阶段工作。

issue_84 定时启动后的证书签发与部署记录

以公网 TLS 端点作为最终验收对象

证书签发和 CDN deployment job 成功，不代表用户访问一定已经恢复。资源绑定错误、边缘下发延迟或缓存，都可能造成云端状态与公网结果不一致。

因此，Shell 最后直接从公网连接目标域名。curl 使用系统信任库验证证书链和主机名，openssl 读取 CDN 边缘返回的叶子证书并检查 SAN、序列号和有效期：

set -eu

# curl 默认校验证书链和请求域名；TLS 校验失败时命令返回非零
curl --silent --show-error --head --output /dev/null \
  "https://${DOMAIN}/"

# 读取 CDN 边缘实际返回的叶子证书
CERT_PEM=$(
  echo \
    | openssl s_client \
        -servername "$DOMAIN" \
        -connect "$DOMAIN:443" 2>/dev/null \
    | sed -ne '/BEGIN CERTIFICATE/,/END CERTIFICATE/p'
)

test -n "$CERT_PEM"

printf '%s\n' "$CERT_PEM" \
  | openssl x509 -noout \
      -subject -issuer -serial -dates

printf '%s\n' "$CERT_PEM" \
  | openssl x509 -noout -text \
  | grep -A1 'Subject Alternative Name'

本次最终验证确认：

  • Subject 与目标域名一致；
  • SAN 覆盖预期域名；
  • 主机名与证书链验证通过；
  • CDN 边缘已经返回新证书；
  • 新证书有效期到 2026 年 10 月 28 日。

Opsx 不以某条命令的退出码作为完成依据，而是验证最终消费者——浏览器实际连接的公网 TLS 端点——已经获得正确证书。

执行产生的证据继续保存在 Issue 中。以后出现问题，不需要依赖某个人回忆“那天控制台显示过什么”，可以沿着申请、签发、部署、轮询和公网验证逐段检查。

这次成功过程随后沉淀为已启用的 kw_157——“阿里云 CAS 部署 CDN SSL 证书轮换 Playbook”。它不只是记录几条命令，还固定了下一次执行必须遵守的输入、人工确认和完成标准：资源与联系人 ID 每次动态查询；部署前记录旧证书；CAS 任务必须进入 success；公网证书的域名、序列号、证书链和 notAfter 必须同时验证；旧证书在新证书通过验收前继续保留为回滚路径。

issue_92：从一次半自动验证升级为全自动批量轮换

issue_84 完成后，Opsx 又识别出 5 张将在 2026 年 8 月 31 日到期的证书，并创建 issue_92，计划在 8 月 30 日 11:00 统一处理。这一次的目标不再是让人收到提醒后继续操作，而是让平台在预定时间自动启动已经准备好的批量轮换流程。

scheduled_at 正是为这类场景开发的能力。普通日历提醒只保存一个时间点，真正执行时仍需要人重新寻找证书、域名、云资源、脚本和运行环境；Opsx 的定时 Issue 则把未来时间与完整运维上下文保存在一起：

issue_92
  ├── scheduled_at：2026-08-30 11:00（Asia/Shanghai）
  ├── 目标：8 月 31 日到期的 5 张 SSL 证书
  ├── Asset：各证书对应的域名与云资源
  ├── Runtime：具备阿里云 CLI 能力的 mes-agent-01
  ├── 执行方法：kw_157 + 确定性 Shell
  └── 验收标准：CAS success + 公网 TLS 结果

到达 scheduled_at 后，Opsx 会唤醒原 Issue，将保存的执行任务派发到对应 Runtime。Shell 依次创建或申请证书、完成同平台域名的自动验证、轮询审核与签发状态、部署到正确的 CDN 资源，再通过公网 TLS 端点确认域名、证书链和有效期。整个过程使用已经验证的 CLI 与状态机，不依赖 LLM 临场生成命令，也不需要人在执行时间守着控制台。

计划在 8 月 30 日自动执行的批量 SSL 证书轮换 Issue

图：issue_92 已进入 Scheduled 状态。与周期 Schedule 不同，它是一项绑定明确 Asset、执行上下文和未来时间的一次性生产变更。

长期收益：降低证书轮换对人的持续占用

继续使用免费证书，是一个成本选择；让 90 天证书变得可持续维护，则需要平台持续保存上下文、权限、执行时间和证据，而不是让这些信息停留在某次 Agent 对话中。

Opsx 把这件事拆成了长期存在的平台能力：

Asset
  保存证书、域名、CDN 资源和 Runtime 的确定关系

Issue
  保存一次具体更换的背景、未来时间、执行和验证

Agent + LLM
  第一次探索云 API、处理差异并设计流程

Aliyun CLI + Shell
  确定性申请、部署、轮询和验证

Scheduled Issue
  在计划时间唤醒具体证书的更换任务

Knowledge / Playbook
  保存已经验证的方法、Gate、失败边界和回退步骤

这正契合 Opsx 的核心设计：识别资产，复用已经学到的经验，再通过合适的 Runtime、Agent 或 Shell 行动；执行工具可以更换，但平台持续持有运维状态和知识。

issue_84 验证真实云端流程，kw_157 保存经过验证的方法，issue_92 再通过 scheduled_at 承接 5 张证书的未来轮换。Opsx 在计划时间唤醒原 Issue、按已保存的 payload 启动执行，并将人工 Gate、云端状态和公网结果保存在同一份运维记录中。

这套机制最终要降低的，不只是单次证书更换的操作成本，更是证书临期后依赖个人记忆、甚至必须在通勤途中紧急处置的生产风险。