Let's Encrypt免费SSL证书实战：从Nginx到群晖NAS的自动续期指南

我在给个人网站配 HTTPS 的那几年，最烦的从来不是 Nginx 配置，而是每年一到证书到期就得登录主机商后台，把输入法切到英文，贴一遍 CSR，再等一个工作日的审核邮件。更难受的是账单：一张只做域名验证（DV）的证书，一年几百块算是入门价，想省点只买一年，第二年忘了续费，浏览器里那个红色警告能吓跑一半访客。

后来我把证书全部换成了 Let's Encrypt——一个能自动签发、自动续期、完全免费的开源证书项目。换了之后，我几乎再也没为 SSL 证书这件事操过心。这篇文章不打算讲那种"高大上"的理论，就围绕一个很务实的问题展开：你手头那些收费证书的钱，到底有没有必要继续花？我会用自己实际部署过的例子，把 Let's Encrypt 的申请、续期、在群晖 NAS 和 Tomcat 等场景里的具体用法，连同我踩过的坑一起写清楚，也算给同样被证书问题折磨过的人一个参考。

1. 一张收费证书的账单，让我开始认真看 Let's Encrypt

1.1 我当初的证书开销到底花在了哪里

先算一笔旧账。早几年前，我帮朋友维护一个小型企业官网，域名是 .com，托管在常规虚拟主机上。为了显得专业，我直接上官方面板买了一张 DV 证书，一年折合人民币大概六百多。这还不是大头，麻烦的是第二年续费时对方告诉我"老用户优惠过期"，新价格直接涨了一截。我后来一查才知道，很多证书商第一年引流价特别低，续费才是利润来源。如果你买的是泛域名证书，或者想上 EV（扩展验证）证书，一年几千块都很正常，而且 EV 还要求你准备营业执照、打验证电话、等人工审核。

在我的记忆里，最消耗耐心的是申请流程：生成 CSR、复制粘贴、等待邮件、上传回执、甚至还要对着 PDF 操作。一套流程下来，一张证书从下单到真正装上，运气好要半天，运气不好能拖两三天。中间如果域名解析变过、服务器换了 IP，还得重新验证。

还有一类开销容易被忽略：隐形成本。证书到期忘了续，网站挂掉的直接经济损失、客户投诉、搜索引擎降权，这些都不是小数目。所以当我第一次接触 Let's Encrypt 时，最大的感受不是"居然不要钱"，而是"原来证书这件事，可以做到不用人管"。

1.2 Let's Encrypt 是个什么样的项目

Let's Encrypt 是由一家非营利机构运营的免费证书颁发机构（CA），成立初衷很朴素：现在互联网还有大量网站没有走 HTTPS，主要原因是证书太贵、配置太复杂，那就做一个免费、自动化、人人都能用的 CA，把 HTTPS 的门槛降下来。这个项目由一个专注于互联网安全普及的非营利团队在运营，不过作为普通用户，你只需要记住三个关键词：免费、自动、可信。

"免费"不用多说，申请一张 DV 证书不需要付任何费用。"自动"是它和传统证书最大的区别，它基于 ACME 协议，让服务器能够自己完成验证、签发、续期这一整套动作，不需要人工介入。"可信"指的是它不是野鸡 CA，它的根证书被 Windows、macOS、iOS、Android 以及各家浏览器内置信任，也就是说你装上之后访问，浏览器地址栏不会出现任何异常警告。

这里有一点值得提：Let's Encrypt 默认签发的证书有效期是 90 天。很多人一听到有效期只有三个月，下意识觉得麻烦，其实恰恰相反，90 天换一次的设计是在倒逼运维做自动化。有效期越短，万一私钥泄露造成的损失窗口就越小；而自动化续期一旦配好，你实际感受反而是"永远不用操心到期"。

1.3 免费证书到底帮我省了多少

我整理了一个对比表，方便你直观感受：

当然也要说句公道话，收费证书并不是一无是处。企业级客户如果要求 OV（组织验证）或 EV（扩展验证），浏览器地址栏能显示企业名称，这类需求 Let's Encrypt 暂时替代不了。但对于个人网站、中小型企业官网、API 服务、测试环境、NAS 这类场景，DV 证书就够用了，而 Let's Encrypt 在 DV 这个档位上，成本归零，体验还更好。这些年我看过不少公司，项目本身很小，却在证书上花着大几千的预算，唯一原因就是没人愿意去尝试新方案。

2. 证书免费不等于"白拿"：先弄懂 SSL 的信任机制

2.1 HTTPS 握手时证书到底在证明什么

想省钱，前提是得搞清楚你用的是个什么东西。HTTPS 之所以安全，是因为它同时用到了对称加密和非对称加密：每个浏览器和服务器建立连接时，先通过非对称加密协商出一个临时会话密钥，之后的数据传输都使用这个会话密钥做对称加密。非对称加密里最关键的一环，就是服务器必须拿出一份"能证明自己身份"的材料——这就是 SSL 证书。

证书本质上是一个数字签名文件，它把"域名"和"公钥"绑定在一起，上面还有 CA 对这个绑定关系的签名。你可以把它理解成一张带防伪标识的身份证：公钥是证件照，域名是姓名，CA 的签名是发证机关盖章。浏览器收到证书后，会先验证"盖章"是否真实，确认真实之后，才愿意用证书里的公钥去做下一步加密协商。

如果去掉这一步会怎样？完全可以自己生成一个证书，甚至自己给自己签发，但浏览器一查盖章，发现不是它信任的机构签的，立刻弹警告"您的连接不是私密连接"。所以核心问题从来不是"有没有证书"，而是"证书是谁签的，浏览器信不信这个签发者"。

2.2 浏览器凭什么信任 Let's Encrypt

浏览器的信任，来源于操作系统的信任库。Windows、macOS、iOS、Android 的根证书存储区里，预置了一堆根证书。只要某张证书的签名链路，最终能往上追溯到其中某个根证书，浏览器就认为它是可信的。Let's Encrypt 这些年做的事情，就是让自己的根证书进入这些信任库。

有一点容易被忽略：服务器发给浏览器的不是一张孤零零的叶子证书，而是一条证书链。以 Let's Encrypt 为例，它的链大致是"叶子证书（也就是你域名的那张）"→"中间证书（R3、R10 等）"→"根证书（ISRG Root X1）"。客户端只预置根证书，中间证书和叶子证书都需要服务器在 TLS 握手时主动发送。很多配置错误，比如只填了 cert.pem 忘了把 chain.pem 拼接进去，就会导致客户端校验链不完整，报错"证书链不完整"或者"缺少中间证书"。

这也是为什么我建议你配置 Nginx 的时候直接用 fullchain.pem，而不是自己手动去拼。fullchain.pem 本身就是叶子证书加中间证书的合并文件，少一步出错的可能。群晖和 Tomcat 的场景也类似，导入证书时一定要区分"只要公钥"还是"公钥加完整链"。

2.3 域名验证的三种方式：为什么 Let's Encrypt 敢免费发证书

Let's Encrypt 只发 DV 证书，也就是"域名验证"证书。它的含义是：CA 只证明"申请者控制了某个域名"，但不去核实申请者背后是个人还是公司。所以它敢把签发过程做得全自动，因为验证"是否控制域名"这件事，是可以通过一系列技术手段自动完成的。

最常见的三种验证方式：

• HTTP-01：CA 给你一个随机 token，要求你把 token 放到 http://你的域名/.well-known/acme-challenge/ 路径下，然后 CA 从公网访问这个地址，能访问到就算通过。实现最简单，绝大多数客户端都优先用它。
• DNS-01：CA 要求你在域名的 TXT 记录里放一段随机值。你改完 DNS 后，CA 再去解析验证。它不依赖 80/443 端口，所以可以做泛域名证书（*.example.com）。缺点是得能调域名 DNS 解析商的 API 来自动改记录。
• TLS-ALPN-01：通过 443 端口的一种特殊 TLS 协商完成验证。用得相对少。

透过这些验证方式，你就能明白：免费证书的核心逻辑是"用自动化技术，把传统 CA 的人工审核降级成机器验证"。这既是它能免费的原因，也是它只适合 DV 场景的原因。

3. 动手签发：Certbot 从安装到拿到第一张证书的完整路径

3.1 ACME 客户端怎么选

ACME 协议是让 Let's Encrypt 真正"自动化"的基础协议，只要遵守这个协议，任何客户端都能申请证书。就我自己的使用经验，给你几个参考选项：

对第一次上手的人，我的建议是无脑选 Certbot。它的文档最全，遇到问题搜一下到处都是解决方案，而且默认安装完就会帮你配好 systemd 定时续期任务，不需要额外操心。acme.sh 适合那些对"依赖 Python"有顾虑的人，或者要批量申请泛域名证书的场景。Caddy 是另外一种思路，你根本不需要考虑证书文件放在哪、续期怎么做，它对托管目录里的站点自动签证书，不过这套逻辑和传统 Nginx 配置的思维方式不太一样，适合新项目。

3.2 用 Certbot 给 Nginx 签发一张证书

我以 Ubuntu 22.04 + Nginx 为例，完整走一遍。前提是你有一个公网可访问的域名，并且解析已经指向本机，80 端口能被外部访问到（HTTP-01 验证需要）。

先在服务器上安装 Certbot 和 Nginx 插件：

bash复制sudo apt update
sudo apt install -y certbot python3-certbot-nginx

如果你用的是 CentOS，对应命令是 sudo yum install -y certbot python3-certbot-nginx；不同发行版的包名略有差异，但逻辑一样。

安装完成后，执行签发命令：

bash复制sudo certbot certonly --nginx -d example.com -d www.example.com -m you@example.com --agree-tos

这条命令的意思是：用 nginx 插件的方式验证域名，同时对 example.com 和 www.example.com 两个域名申请 SAN 证书（就是一张证书带两个域名），并带上你的邮箱用于接收到期提醒，同时表示同意服务条款。执行过程中 Certbot 会自动修改一段临时 Nginx 配置、完成 HTTP-01 验证、再还原配置。

命令跑完，证书文件会生成在 /etc/letsencrypt/live/example.com/ 目录下，里面有四个文件：

• cert.pem：叶子证书，也就是你域名自己的证书。
• chain.pem：中间证书。
• fullchain.pem：叶子证书 + 中间证书的合并文件，Nginx 配置时用这个。
• privkey.pem：私钥，一定注意权限，不要泄露。

如果 Nginx 配置还不太完整，也可以直接用 certbot --nginx 自动配置证书，它会自动把证书写进对应的 server 块，但生产环境我更推荐 certonly 方式：先拿到证书文件，再在 Nginx 配置里手动引用，这样你对最终配置有完全的控制权。

3.3 配置 Nginx 并验证整条链路

拿到证书之后，配置 Nginx。打开站点配置文件，加入或修改 443 端口的 server 块：

nginx复制server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # 其余站点配置保持不变
}

另外再加一个 80 端口的跳转，把明文请求统一转到 HTTPS：

nginx复制server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

改完后，先检查配置语法再重载：

bash复制sudo nginx -t
sudo systemctl reload nginx

然后从本机和外部验证：

bash复制curl https://example.com -I

如果返回 200，且没有任何证书警告，基本就算成了。想看证书是否连了一条完整的链，可以用：

bash复制echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | grep -E "subject=|issuer="

看到证书的 issuer 是 Let's Encrypt 相关的中间证书，就说明链路没问题。

这里我特别提醒一个新手容易犯的错：千万不要把 cert.pem 当成 fullchain.pem 用。省掉中间证书之后，绝大多数现代浏览器都能自动补链，但老版本客户端、一些移动端 App、还有很多企业防火墙会直接认为站点证书不可信。报错形式五花八门，但根子都是链路不全。

4. 90天自动续期：把免费证书的成本压到接近于零

4.1 有效期短不是缺点，是设计

第一次看到 90 天有效期，很多人第一反应是"这谁敢用啊，三个月就得换一次"。我一开始也这么想。直到我真正配完自动续期，才意识到这个设计的高明之处。

先说安全层面：证书对应私钥，私钥一旦泄露，攻击者就能冒充你的服务器。证书有效期越短，私钥被利用的窗口越小。就算真泄露了，最多三个月内的影响。这和"密码定期更换"是一个道理，运维风险被主动压缩了。

再说运维层面：90 天意味着你必须把续期做成自动化，否则靠人肉根本记不住。而自动化本身是有好处的——它强迫你规范服务器配置、配置监控、处理异常。一旦这套机制跑通，你反而比那些每年手动续费的人更省心，因为你永远不用"惦记"证书。我见过不少用收费证书的人，每年到了续费季都会临时抱佛脚：找发票、走审批、填工单、等审核，最后还要挑凌晨重启服务。对比之下，Let's Encrypt 的续期是半夜静默完成的，你要是不看日志甚至不知道发生过。

4.2 systemd timer 和 cron 两套续期方案

Certbot 在 Debian/Ubuntu 上装好的时候，会自动启用一个名为 certbot.timer 的系统定时器。它的机制是每天随机触发一次，检查距离证书过期还剩多少天，只要少于 30 天就发起续期。你不需要自己写定时任务，但要学会检查它是否活着：

bash复制systemctl status certbot.timer
systemctl list-timers | grep certbot

确认定时器存在且状态为 active，就说明续期有保障。真正签发之前，强烈建议先跑一次模拟续期，验证一切就绪：

bash复制sudo certbot renew --dry-run

这条命令会连上 Let's Encrypt 的服务器，走一遍续期验证流程，但不会真的替换证书。如果这里报错，说明你的验证方式、端口、DNS 有问题，要趁现在解决，而不是等到证书真到期了才发现。

如果你习惯用 cron，或者你的系统没有 systemd，可以自己写一行：

bash复制17 3 * * * root certbot renew --quiet --deploy-hook "systemctl reload nginx"

凌晨 3 点 17 分执行续期，成功后触发 nginx reload。注意 --deploy-hook 和 --quiet 很重要：没有 --deploy-hook，证书即使换了，Nginx 还在用旧证书，必须重载进程才会加载新证书文件；没有 --quiet，日志会被任务输出塞满。

4.3 续期失败时怎么下手排查

自动续期也会失败，但不用慌，绝大多数问题都有规律可循。先看日志，/var/log/letsencrypt/letsencrypt.log 和 renew.log 记录的是同一个过程的不同侧面，里面的 ERROR 行会直接指出验证失败的域名和失败原因。

常见的几类失败：

• 80 端口被防火墙或云安全组拦截，HTTP-01 验证请求进不来。排查方法：确认安全组放行了 80，或者改用 DNS-01。
• DNS 解析漂移。比如你做了 CDN 接入，验证服务器访问到的 IP 和真正源站不一致，token 文件拿不到。这种情况要么让 CDN 临时直通，要么换 DNS-01。
• 服务器本地存在另一个程序占用 80 端口，Certbot 的内置临时 Web 服务起不来。可以先停掉占用服务，或者用 --webroot 方式让 Nginx 代管验证文件。
• 续期时私钥权限变了。比如你手动把 /etc/letsencrypt 目录权限改成了 700，导致 Certbot 无法读写。规范的做法是保持 Let's Encrypt 目录的可读性，ls -l /etc/letsencrypt/live/ 看一眼软链接是否正常。

只要不是连续多天失败，其实不容易造成事故，因为 Certbot 会在到期前 30 天窗口内反复尝试。真正危险的场景是：你手动把证书删了，或者把系统时间改乱了，然后才发现定时任务从来没跑成。所以我建议你在配完证书之后，至少做一次 renew --dry-run 验证，别等它真正需要续期的那天。

5. 群晖 NAS 换证书的坑：从阿里云免费证书切到 Let's Encrypt

5.1 群晖 DSM 里自带的 Let's Encrypt 入口

很多群晖用户之前用的是云厂商免费证书，常见流程是：在云控制台申请一张免费 DV 证书，下载压缩包，解压出 cer/key，再手动上传到群晖的"控制面板 → 安全性 → 证书"里。这个流程本身不复杂，但有个致命弱点：免费证书有效期一般只有 3 个月或 1 年，到期后你必须重新申请、重新上传、重新绑定，而且云厂商的免费证书大多不能自动续期，全靠人工。这就是"阿里云 SSL 证书免费续期"这个搜索词背后的真实痛点——它说的"续期"不是点击一下那么省事，你需要走一遍完整的替换流程。

群晖其实早就内置了 Let's Encrypt 支持。在 DSM 的"控制面板 → 安全性 → 证书"里，点击"新增"，选择"添加新证书"，签发机构选"Let's Encrypt"，然后填写你的域名和管理员邮箱。这里有一个前提：你的域名必须能正常解析到这个 NAS 的公网 IP，并且 DSM 的"外部访问"里已经配置好了 DDNS，否则 Let's Encrypt 服务器验证不到你的域名。

群晖默认会通过 HTTP-01 方式做验证，整个申请过程在界面上完成，不需要登录任何 SSH 终端。申请成功之后，这张证书会出现在证书列表里，记得在"设置"里把它指派给 DSM、Web Station、邮件服务等需要用 HTTPS 的服务。之后 DSM 自己会在后台续期，续的是 Let's Encrypt 证书本身，不需要你每月登录后台。

5.2 "抱歉，您所指定的页面不存在"到底怎么定位

这应该是很多群晖用户换证书时都撞到过的问题：证书明明已经导入成功，列表里也显示正常，但打开 DSM 的某个套件页面或者控制台，却提示"抱歉，您所指定的页面不存在"。

我实际排查下来，这类报错绝大多数不是证书文件的问题，而是 TLS 层和应用层之间的错位。常见的诱因有三种：

第一种，证书并没有真正绑定到出问题的服务。群晖的证书机制是把一张证书绑定给多个服务，如果你在新证书导入后没有去"设置"里重新指派，某些服务可能还绑在旧证书上。而旧证书可能因为你手动删除、被覆盖，已经失效。客户端访问时服务端发给浏览器的证书和域名请求又不一致，浏览器拒绝建立连接，应用层就显示"页面不存在"。

第二种，DSM 的 Web 服务没有及时重载证书。群晖某些套件（比如 Web Station、Synology Drive）有独立的证书配置缓存，替换证书后不会立刻生效。最粗暴但有效的解决办法是重启一次"Web Station"或者干脆重启 NAS。

第三种，浏览器侧缓存。群晖的 DSM 通过 5000/5001 端口访问，很多人在浏览器里访问的是 http://IP:5000，证书变化后，浏览器还保留了旧的 TLS 会话状态，导致页面异常。换一个无痕窗口、清掉缓存再访问，往往就好了。

排查顺序我建议这样：先确认证书列表里当前使用的证书状态是"有效"；再到"证书 → 设置"里检查各个服务是否都指派了这张证书；然后重启 Web Station；最后用无痕模式访问。如果问题只出现在某一个套件上，单独看那个套件的设置里是否有独立的证书选项。这套流程走完，大概率能解决。

5.3 阿里云免费证书和 Let's Encrypt 怎么取舍

既然已经把群晖的场景写到这里，顺带把云厂商免费证书和 Let's Encrypt 的对比说透。

云厂商免费证书的优势是"中文界面、操作直观"，而且在云服务器场景下，有些厂商支持一键部署到负载均衡器和云主机。但从证书管理的角度看，它有明显短板：

• 有效期短且不固定。早年还有一年期的免费证书，现在很多已经收短到 3 个月。
• 免费版一般只支持单域名，泛域名和多域名的组合需要额外收费。
• 续期基本靠人工，申请成功后要重新下载、重新导入、重新绑定服务。
• 有的厂商免费证书不提供 API 或 CLI，自动化难度大。

反观 Let's Encrypt，在 NAS 这种"有固定域名、长期在线"的场景下，好处几乎是对称的：自动签发、自动续期、支持多域名和泛域名、社区资料丰富。唯一需要你多花一点精力的，就是第一次把域名解析和 DDNS 配好，后面基本一劳永逸。

当然，如果你用的是某云负载均衡这种托管服务，而它又只支持平台侧证书，那该买平台证书还得买，这种属于"省事优先于省钱"。但如果你有权限把证书放到后端服务器上，我还是建议优先上 Let's Encrypt，把主动权握在自己手里。

6. 格式转换那点事：CER、PEM、PFX 到底怎么互相倒腾

6.1 后缀只是外壳，编码才是关键

很多人在这一步翻车，因为下载下来的证书文件后缀五花八门：.cer、.crt、.pem、.pfx、.jks……一看就头疼。其实后缀只说明"大概是个证书文件"，真正决定文件内容的是编码格式和封装格式。

简单分类：

所以网上说的"cer 转 Tomcat 的 pfx"，本质上是把"DER 或 PEM 编码的公钥证书 + PEM 私钥"打包成一个 PKCS#12 容器。关键不是你拿到了什么后缀，而是你有没有找到配套的私钥。

6.2 用 OpenSSL 把证书打包成 Tomcat 需要的 PFX

如果你已经把站点切到了 Let's Encrypt，那么 /etc/letsencrypt/live/你的域名/ 下就有 fullchain.pem（公钥 + 中间证书链）和 privkey.pem（私钥），用它们生成 pfx 非常直接。执行：

bash复制openssl pkcs12 -export \
  -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -inkey /etc/letsencrypt/live/example.com/privkey.pem \
  -name tomcat \
  -out tomcat.pfx

命令中的 -name tomcat 是给 keystore 里的别名起名，通常用别名 tomcat 便于记忆。执行后 OpenSSL 会要求你设置一个导出密码，这个密码后面配置 Tomcat 时要填，别随手乱设然后忘了。

在 Tomcat 的 server.xml 里配置 HTTPS 连接器，关键是 keystoreType="PKCS12"：

xml复制<Connector port="8443" protocol="HTTP/1.1"
           SSLEnabled="true" scheme="https" secure="true"
           keystoreFile="/path/to/tomcat.pfx"
           keystoreType="PKCS12"
           keystorePass="你的密码" />

如果你的 Tomcat 版本比较老，只认 JKS，就用 keytool 把 pfx 转成 jks：

bash复制keytool -importkeystore \
  -srckeystore tomcat.pfx \
  -srcstoretype PKCS12 \
  -destkeystore tomcat.jks \
  -deststoretype JKS

转换过程中会让你设置目标 keystore 的新密码。转完再把 server.xml 的 keystoreFile 指向 tomcat.jks，keystoreType 改成 JKS 即可。

还有一种情况：你手上只有一个 .cer 文件，里面只有公钥，没有私钥。那无论如何也转不出 pfx，因为 pfx 必须包含私钥。你需要找到当初生成 CSR 时保留的 .key 私钥文件。如果私钥丢了，唯一办法是重新生成证书再申请，所以私钥文件请务必妥善备份。

6.3 其他常见转换命令速查

顺手整理几个高频转换命令，都是 OpenSSL 一行就能搞定的：

• DER 证书转 PEM：

bash复制openssl x509 -inform DER -in cert.cer -out cert.pem

• PEM 证书转 DER：

bash复制openssl x509 -outform DER -in cert.pem -out cert.cer

• 从 PFX 里提取私钥和证书链：

bash复制openssl pkcs12 -in tomcat.pfx -nocerts -nodes -out private-key.pem
openssl pkcs12 -in tomcat.pfx -nokeys -clcerts -out cert-only.pem

• 查看证书有效期：

bash复制openssl x509 -in fullchain.pem -noout -dates

这些命令在日常维护中特别常用。我的习惯是：所有服务器证书都以 PEM 格式为"主存格式"，需要什么格式就现场转，而不是从下载源上保留一堆乱七八糟的副本。主存清晰，转换可复现，排查起来也省心。

7. 实际部署中碰到的各种怪问题汇总

7.1 申请数量与频率限制：免费不等于无限刷

Let's Encrypt 为了保障服务稳定性，对签发有频率限制。以我目前了解到的规则，大致是：每个注册域名每周最多签 50 张证书；同一个域名组合每周最多签发 5 张重复证书；每个账号每 3 小时最多发起 300 个新订单。具体数字以官方文档为准，但这已经足够说明：不要用自动化脚本疯狂重复签发。

我的建议有两条。第一，把多个域名合到一张 SAN 证书里，而不是每加一个子域名就单独签一张，既省事又规避限频。第二，所有测试请求都打到 staging 环境去，地址是 https://acme-staging-v02.api.letsencrypt.org/directory，只有正式上线才用生产环境。Certbot 里可以临时指定 --server 参数，测试完再切回来，这样可以避免因为反复试错把生产配额耗尽。

7.2 HTTP-01 验证失败的隐形杀手：端口和 CDN

HTTP-01 验证看似简单，实际上有个很大的前提：Let's Encrypt 的验证服务器必须能从公网通过"你的域名"访问到你的服务器。这就引申出两个高频坑。

第一个坑是云安全组/防火墙。很多云服务器默认只开 22、80、443，但如果你把所有入站规则都封掉了，或者安全组的顺序有问题，验证请求根本到不了服务器。先在你本机用 curl http://你的域名/.well-known/acme-challenge/xxxx 测试一下，能访问再说。

第二个坑是 CDN。有些站点开了 CDN 加速，HTTP-01 验证的请求回源时被 CDN 缓存或拦截，导致 token 文件访问不到。如果你不确定，可以先把 CDN 暂停，等签发完成再开回来；或者直接用 DNS-01 验证，不经过 Web 端口，这类问题自然不存在。

7.3 泛域名证书与内部系统：公共 CA 不是全能的

泛域名证书（*.example.com）比较实用，尤其当你有一堆子域名要上 HTTPS 时。但它通常只能用 DNS-01 方式验证，因为 HTTP-01 没法对"任意子域名"都准备验证文件。使用场景是：你的域名解析商提供 API，acme.sh 或 Certbot 的 DNS 插件能自动添加和删除 TXT 记录，验证完成再清理，全程不用碰 80 端口。

另外要提醒一句：Let's Encrypt 这类公共 CA 只能签"公网可真实解析的域名"。如果你的服务是用内网主机名、.local 结尾、或者纯 IP 访问，公共 CA 是管不了的。对这种内部系统，别硬套 Let's Encrypt，直接搭一个内部 CA 然后把根证书分发到员工设备，反而更合理。一个最简单的自建 CA 命令：

bash复制openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout ca.key -out ca.crt \
  -days 3650 -subj "/CN=Internal CA"

拿到 ca.crt 后，分发给内网所有客户端，并加入信任列表。再用这个 CA 给内部服务签发证书即可。这么做的好处是，不再依赖公网域名验证，纯内网环境也能有完整的信任链。

7.4 一个检测证书剩余天数的土办法

即使 Let's Encrypt 的续期已经很自动化，我还是建议你做一个兜底监控。不为别的，就为求个心安。最简单的办法是写一个小脚本，用 OpenSSL 读取证书到期的日期，再算一下还剩多少天：

bash复制#!/bin/bash
CERT="/etc/letsencrypt/live/example.com/fullchain.pem"
EXP=$(openssl x509 -enddate -noout -in "$CERT" | cut -d= -f2)
DAYS=$(( ( $(date -d "$EXP" +%s) - $(date +%s) ) / 86400 ))
echo "剩余 ${DAYS} 天"
if [ "$DAYS" -lt 15 ]; then
  echo "证书即将过期，请检查续期任务" | mail -s "证书告警" you@example.com
fi

把脚本放进 cron 里每周跑一次，配合前面说的 certbot renew --dry-run，基本可以把"忘了续期"这种事永久排除掉。我自己的服务器就是这样跑的，几年下来，除了偶尔因为安全组规则调整导致一次续期失败之外，几乎没有因为证书问题影响过业务。说句实在话，把 SSL 证书这个环节做成"免费 + 自动"之后，你省下的不只是钱，还有每年那种"又要续期了"的焦虑感。如果你现在还在为证书续费纠结，真心建议按上面的步骤试一次 Let's Encrypt，大概率你也不会再想回去手动填工单了。