免费 SSL 自动部署续签工具横评：Certimate、Certd 与 ACME.sh

免费 SSL 证书并不等于“装一个脚本就结束”。真正的难点通常在续签之后：DNS 验证能否自动完成、证书有没有交给正确的 Nginx/CDN/Ingress、服务是否真的加载了新证书，以及失败后有没有人能及时发现。Certimate、Certd 和 ACME.sh 都能参与这条链路，但它们分别代表了可视化编排、任务化流水线和轻量脚本三种运维方式。

本文不把它们做成简单排名，而是说明每种工具能解决什么、要付出什么代价，并给出可直接改造的示例。文中的免费证书以 Let's Encrypt 等 ACME CA 为例；工具负责申请、部署和续签自动化，证书是否免费由所选 CA 和域名验证条件决定。

一、先定义“自动部署续签”的完成标准

一次成功的 ACME 签发，只证明域名控制权验证通过。可长期运行的证书自动化至少要完成五件事：保存最小权限的 DNS 或云账号凭据，自动完成 DNS-01 或 HTTP-01 质询，按计划续签，复制或推送证书到实际服务入口，以及从外部检查 SNI 握手和有效期。

DNS-01 尤其适合通配符证书和无法被公网直接访问的服务，但它要求 DNS 服务商 API 或受控的委派记录。HTTP-01 更直观，却要求 CA 能访问 /.well-known/acme-challenge/。无论使用哪一款工具，都不要把全局 DNS 密钥写入脚本、镜像或 Git 仓库。

二、三款工具的定位与适用场景

Certimate 是自托管的可视化 ACME 证书管理工具，官方提供二进制和 Docker 方式，强调工作流、通知以及多种 DNS 和部署目标集成。Certd 也是面向可视化操作的开源证书管理平台，重点是把证书申请、部署与续期组织成任务流水线，并覆盖常见国内云厂商、主机、NAS 和面板场景。ACME.sh 则是纯 Shell 实现的 ACME 客户端，适合将签发和部署钩子直接放进主机、CI/CD 或基础设施代码中。

一个实用的判断是：需要让多人看见证书状态、部署记录和失败通知时，先看 Certimate 或 Certd；证书跟随单台服务器或代码仓库发布、且团队已经有监控体系时，ACME.sh 往往更直接。三者可以并存，但同一个域名和私钥不要被多个自动续签器同时管理。

三、Certimate：适合“看得见的”多目标证书编排

Certimate 官方提供二进制与容器部署方式。部署时必须将其本地数据持久化到宿主机，并限制管理端口只允许内网、VPN 或受控反向代理访问；容器重建后，证书任务、账户和配置不应丢失。

一个典型使用示例可以完全在控制台完成：添加 DNS 服务商凭据，选择 ACME CA 与 DNS-01，填写域名或通配符域名，选择 Nginx、Kubernetes、CDN 或负载均衡等部署目标，最后设置续签检查和通知渠道。首次执行后，要确认 TXT 质询记录、目标端证书序列号和 TLS 握手都正确，再启用定时任务。

优点：团队能看到证书与工作流状态；适合把多个云账号、多个域名、多个部署目标收拢到一个控制面。限制：Web 控制台和数据目录本身成为关键资产，必须做访问控制、备份、升级评估与 Token 轮换。它并不会替你降低 DNS API 的风险，只是让任务编排更直观。

四、Certd：将申请、部署、续期组织成任务流水线

Certd 的官方文档将它定位为开源、免费、全自动的 SSL 证书管理工具，强调证书申请、更新、续期和部署流水线。它适合把“域名账号 - 证书申请 - 部署目标 - 定时执行 - 通知”交给一条可追踪任务来完成，尤其适合已经使用阿里云、腾讯云、服务器、群晖或面板服务的中文运维环境。

使用示例可以按任务思路建立：先新建证书任务，选择 ACME 证书申请器与 DNS 验证方式；再录入域名服务商凭据和域名列表；随后添加部署步骤，例如上传到主机的 Nginx、推送到 CDN 或更新云负载均衡；最后配置计划执行和失败通知。上线前先手动执行一次，确认质询记录会被清理、部署目标的证书序列号发生变化、业务域名的 TLS 握手正常，再启用自动运行。

优点：把分散的证书动作变成可复查任务，适合团队协作和多类目标。限制：凭据连接、任务日志和持久化数据库同样需要备份与权限治理；不要因为有 UI 就省略 DNS Token 的最小授权和部署后验收。

五、ACME.sh：把自动化留在主机与代码中

ACME.sh 是纯 Shell 的 ACME 协议客户端，支持 SAN、通配符、ECC 证书、DNS API、部署钩子和 cron 自动续签。它不依赖 Python，也不要求先安装一个完整的管理后台，适合已经用配置管理或 CI/CD 管理服务器的团队。

下面以 Cloudflare DNS API 和 Nginx 为例。真实 Token 应保存在 root 可读的凭据文件或密钥系统中，示例中的值不能直接使用：

# 已完成 ACME.sh 安装后，注入仅授予目标 Zone DNS 编辑权的 API Token
export CF_Token='REDACTED_DNS_API_TOKEN'
export CF_Account_ID='REDACTED_ACCOUNT_ID'

# DNS-01 签发主域名与通配符证书
acme.sh --issue --dns dns_cf \
  -d example.com -d '*.example.com' \
  --keylength ec-256 --server letsencrypt

# 安装到 Nginx 实际读取的位置；续签成功后才会执行 reload
acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.fullchain.pem \
  --reloadcmd "nginx -t && systemctl reload nginx"

ACME.sh 安装时会创建定时续签任务。不要让 Nginx 直接引用 ~/.acme.sh/ 里的内部文件；应使用 --install-cert 将证书复制到服务配置指定路径，并配置 reload 钩子。若部署到多台机器，可在钩子中调用受控的 Ansible、rsync、Vault 或 Kubernetes Secret 更新流程。

优点：脚本小、依赖少、适合 GitOps 与命令行排障。限制：证书清单、审批、通知和多节点部署不会自动变成统一平台，需要你结合现有监控与自动化体系补齐。

六、三种工具共享的续签闭环

换工具不能替代验证。无论选择 UI、任务还是 Shell，都应该对照下图检查完整链路。只要其中一环没有自动化，所谓“自动续签”就会在到期前后暴露问题。

1. 凭据：DNS Token 仅允许目标 Zone 的 DNS 编辑，云端部署凭据仅允许所需资源。

2. 挑战：通配符优先 DNS-01；HTTP-01 需要公网挑战路径可达。

3. 部署：续签后写到应用真实使用的文件、Secret 或云资源，并先执行配置检查。

4. 校验：用实际域名的 SNI 握手检查证书，而不是只看工具任务显示“成功”。

5. 告警：监控执行失败、证书剩余天数和 TLS 探针异常，确保告警能到负责人。

七、上线检查与常见误区

首次上线时，建议先手动执行任务，再从客户端确认返回的确实是新证书。对于内部地址测试，可以使用 curl --resolve 指定域名、私有 IP 和 SNI；对于公开服务，可直接检查到期时间：

openssl s_client -connect example.com:443 \
  -servername example.com < /dev/null 2> /dev/null \
  | openssl x509 -noout -subject -issuer -dates

curl --resolve example.com:443:203.0.113.10 \
  --fail --silent --show-error https://example.com/healthz

常见误区包括：用 DNS 手工模式却期待无人续签；把证书签发成功当成服务已更新；给 Token 过大的账户权限；多个工具同时续签同一域名；只在控制台里看任务成功、不检查线上 TLS 握手。解决这些问题的关键不是多装一个工具，而是明确“谁持有凭据、谁负责部署、谁接收告警、谁验证结果”。

八、结论：按运维边界选工具

Certimate 更适合追求轻量自托管控制台、工作流和多种部署目标的团队；Certd 适合希望用中文任务流水线管理云厂商和设备部署的环境；ACME.sh 则适合把一切放进 Shell、CI/CD 与基础设施代码的场景。它们的共同底座仍是 ACME 与安全的凭据管理。

最稳妥的起点通常是：单机 Nginx 从 ACME.sh 的 DNS-01 与部署钩子开始；当证书、账号和目标增多，再迁移到 Certimate 或 Certd 这类统一任务平台。无论哪种方案，都应将最小权限、持久化备份、部署后 TLS 校验和到期告警作为上线条件。

参考：Certimate 官方仓库、Certd 官方文档、ACME.sh 官方仓库。