acme.sh 上手：把 TLS 证书自动化做成可审计的 Shell 运维流程

acme.sh 的价值不在“又一个申请 Let’s Encrypt 证书的脚本”，而在它把 TLS 证书自动化压到了一条足够小、足够可审计的 Unix shell 工具链里。对自托管、小型云主机、OpenWRT、NAS、Proxmox、pfsense 和各种边缘节点来说，这种形态比一套重型后台服务更容易长期维护。

官方仓库把它定义为纯 Unix shell 写成的 ACME 协议客户端，当前主分支仍在活跃更新，最新 release 为 3.1.3。项目支持 ZeroSSL、Let’s Encrypt、Google Public CA、SSL.com、Actalis 以及符合 RFC 8555 的 ACME CA；也支持 webroot、standalone、tls-alpn、Apache、Nginx、DNS、DNS alias、stateless 和 DNS persist 等验证方式。

为什么“纯 Shell”在证书自动化里仍然有意义

证书续期最怕依赖链漂移。Python、Node、系统包、容器镜像、后台服务、插件版本，任何一个环节变化都可能让 90 天一次的续期在凌晨失败。acme.sh 的设计选择是尽量依赖系统已经有的 shell、curl、openssl 和 cron，把运行面收窄。

这不是说 shell 天然更安全，而是它更容易被服务器管理员看懂：安装在哪里、cron 怎么跑、证书放在哪里、续期失败怎么通知、部署 hook 改了什么，都能在文件和命令层面审计。

最小可用流程：签发、安装、续期分开看

官方 README 的基础路径很清楚：安装脚本会把 acme.sh 放进用户 home 下的 ~/.acme.sh/，创建别名，并加入每日 cron。签发证书可以从 webroot 开始：

acme.sh --issue -d example.com -w /var/www/html

但生产上不要把“签发成功”误解成“服务已经安全上线”。证书签发后还要通过 --install-cert 把 cert、key、fullchain 安装到 Web 服务器实际读取的位置，并在 reloadcmd 里重载 Nginx、Apache、HAProxy 或其他服务。签发目录是 acme.sh 的管理目录，服务运行目录应该单独规划。

DNS API 是通配符证书的关键，也是最大风险面

acme.sh 最强的能力之一是 DNS 模式。仓库的 dnsapi 目录里有大量 DNS 服务商适配脚本，从 Cloudflare、AWS、Azure、Google Cloud，到阿里云、腾讯云、华为云、GoDaddy、DuckDNS、Gandi 等。它让通配符证书和内网服务证书自动化变得很顺。

风险也在这里：DNS API token 通常能改域名解析。生产环境应该给 acme.sh 单独创建最小权限 token，限制 zone、记录类型和有效期；不要把主账号 API key 放进全局 shell 环境，更不要把凭证写进仓库、镜像或日志。

部署 hook 决定它能不能进长期运维

证书续期只解决一半问题，另一半是把新证书送到实际使用它的地方。acme.sh 的 deploy 目录覆盖 nginx、apache、haproxy、opensshd、proxmox、synology、truenas、routeros、unifi、docker、ssh、vault、mailcow 等场景。对多台机器或多服务部署，deploy hook 比手写 scp 更可维护。

建议把部署动作做成幂等脚本：复制证书、校验权限、测试配置、reload 服务、失败时保留旧证书。不要在 hook 里写不可逆的大动作。证书自动化应该像巡检任务，而不是一次“能跑就行”的安装笔记。

采用清单

• 先用 staging 或测试域名跑通签发与续期，不要直接在生产域名上反复试错。
• 优先选择 webroot 或 DNS-01；standalone 会占用 80/443，需要确认不会和现有服务冲突。
• DNS token 最小权限化，独立保存，避免进入 shell history、CI 日志和容器镜像。
• 把 --install-cert 和 deploy hook 当成正式变更脚本管理，保留 reload 与回滚路径。
• 监控 cron 输出或使用 notify 集成，别等证书过期后才发现续期失败。

结论

acme.sh 适合的是想把 TLS 证书纳入日常运维纪律的人。它轻，但不简陋；灵活，但需要你认真处理 DNS 凭证、部署 hook 和续期监控。证书自动化的目标不是“申请一次成功”，而是未来每一次续期都安静、可追踪、可恢复。