Caddy在Ubuntu上无法自动续订SSL证书

Question

Caddy在Ubuntu上无法自动续订SSL证书的常见问题之一是systemd服务配置不当。由于Caddy依赖定时任务（通过内置的自动化机制）在证书到期前发起续订请求，若其systemd服务单元未正确设置Restart策略或执行环境受限（如网络延迟启动、防火墙拦截443/80端口），可能导致续订流程中断。此外，acme.json权限错误或被意外修改也会阻止Caddy写入新证书。用户常忽略日志排查，导致难以定位“context deadline exceeded”或“rate limiting”等关键错误。确保Caddy以正确用户运行、acme目录可写，并开放HTTP-01验证所需端口，是保障自动续订的关键。

Answer 1

1. Caddy自动续订SSL证书的机制概述

Caddy作为现代化的Web服务器，内置了ACME协议支持，能够自动为配置的域名申请和续订SSL/TLS证书。其核心依赖于Let's Encrypt等CA机构提供的HTTP-01或TLS-ALPN-01验证方式，在证书到期前30天左右自动触发续订流程。

该过程由Caddy内部调度器驱动，无需外部cron任务。然而，这一自动化机制高度依赖运行环境的稳定性与权限配置，尤其在Ubuntu系统中，systemd服务管理模型直接影响Caddy能否正常执行续订操作。

2. 常见问题分类：从表象到根源

• systemd服务未设置自动重启策略：导致Caddy异常退出后无法恢复，错过续订窗口。
• 网络延迟或接口未就绪：Ubuntu启动过程中网络服务晚于Caddy启动，造成连接超时。
• 防火墙阻断80/443端口：HTTP-01验证需监听80端口，若被ufw或iptables拦截则失败。
• acme.json文件权限错误：非root用户运行Caddy但目录不可写，导致无法保存新证书。
• 日志未被监控：忽略context deadline exceeded或rate limiting等关键错误提示。
• DNS解析问题：目标域名无法解析至当前主机IP，验证请求无法到达。
• 时间同步偏差：系统时间不准确可能误判证书有效期。
• 资源限制（OOM、CPU）：容器或低配VPS中Caddy因资源不足被终止。
• 多实例冲突：多个Caddy进程竞争acme.json读写锁。
• Let's Encrypt速率限制触发：频繁重试导致临时封禁。

3. 分析路径：如何定位续订失败原因

现象	可能原因	排查命令
证书即将过期但无更新	服务未运行或未触发续订	sudo systemctl status caddy
日志显示“context deadline exceeded”	网络延迟、DNS问题或端口阻塞	journalctl -u caddy -f
“permission denied” on acme.json	文件属主错误或SELinux/AppArmor限制	ls -l /var/lib/caddy/.local/share/caddy/acme.json
HTTP-01 challenge failed	80端口被占用或防火墙拦截	sudo ss -tulnp | grep :80
“too many failed authorizations”	Let's Encrypt速率限制	grep "rate limiting" /var/log/syslog

4. systemd服务配置优化实践

确保Caddy服务具备高可用性是保障续订的基础。以下是推荐的/etc/systemd/system/caddy.service关键配置段：

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

# 关键重启策略
Restart=always
RestartSec=5s

# 等待网络就绪
After=network.target network-online.target
Wants=network-online.target

其中Restart=always确保崩溃后自动重启，After=network.target避免网络未通即启动服务。

5. 权限与存储路径管理

Caddy默认将ACME相关数据存储在/var/lib/caddy/.local/share/caddy目录下，必须保证该路径对运行用户可写：

sudo chown -R caddy:caddy /var/lib/caddy/.local/share/caddy
sudo chmod 700 /var/lib/caddy/.local/share/caddy

同时检查acme.json是否存在且权限正确：

sudo ls -l /var/lib/caddy/.local/share/caddy/acme.json
# 正确输出应类似：
# -rw------- 1 caddy caddy 12345 Jun 10 10:00 acme.json

6. 防火墙与端口开放策略

使用ufw确保80和443端口开放：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw reload

也可通过tcpdump抓包验证外部请求是否抵达：

sudo tcpdump -i any -n port 80 and host letsencrypt.org

7. 日志分析与错误模式识别

启用实时日志跟踪：

journalctl -u caddy -f --since "1 hour ago"

常见错误模式包括：

1. context deadline exceeded：通常表示网络不通或响应慢。
2. failed to get certificate: acme: error：可能是账户受限或域名验证失败。
3. permission denied while locking acme.json：多进程竞争或权限不足。
4. could not validate certificate：反向代理链路中断或SNI配置错误。

8. 自动化健康检查流程图

graph TD
    A[检查证书剩余有效期] --> B{是否小于30天?}
    B -- 是 --> C[尝试触发续订]
    B -- 否 --> D[等待下次检查]
    C --> E[调用HTTP-01挑战]
    E --> F{80端口可达?}
    F -- 否 --> G[记录错误: 端口阻塞]
    F -- 是 --> H[接收来自Let's Encrypt的验证请求]
    H --> I{挑战成功?}
    I -- 否 --> J[重试机制启动]
    I -- 是 --> K[下载新证书并写入acme.json]
    K --> L[重启服务或热加载配置]
    L --> M[发送通知: 续订成功]

9. 运维建议与最佳实践

• 定期审计systemd服务状态：systemctl list-units --type=service | grep caddy
• 设置外部监控告警，如Prometheus + Blackbox Exporter检测HTTPS可用性。
• 使用caddy validate命令预检Caddyfile语法。
• 避免手动修改acme.json，应通过API或reload机制更新。
• 在生产环境中启用--watch模式仅用于开发调试。
• 考虑使用DNS-01验证替代HTTP-01以绕过80端口依赖。
• 部署时集成Ansible/Puppet脚本统一配置权限和服务单元。
• 启用NTP服务确保系统时间精确：timedatectl status
• 限制Caddy日志轮转大小，防止磁盘占满影响运行。
• 对关键域名实施双因素验证通知机制。