刘子栋我在给个人网站配 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 免费证书到底帮我省了多少
我整理了一个对比表，方便你直观感受：
| 对比项 | 传统收费 DV 证书 | Let's Encrypt |
|---|---|---|
| 证书费用 | 一年几百到上千元 | 0 |
| 签发有效期 | 多为 1 年，部分厂商压缩到 3 个月 | 90 天 |
| 验证方式 | 手动提交 CSR、等审核 | ACME 自动验证域名 |
| 续期方式 | 手动申请、手动替换 | 定时自动续期 |
| 支持的域名数量 | 按数量计价，泛域名更贵 | 一张证书可带多个 SAN |
| 受信任程度 | 主流系统内置 | 主流系统与浏览器全部内置 |
当然也要说句公道话，收费证书并不是一无是处。企业级客户如果要求 OV（组织验证）或 EV（扩展验证），浏览器地址栏能显示企业名称，这类需求 Let's Encrypt 暂时替代不了。但对于个人网站、中小型企业官网、API 服务、测试环境、NAS 这类场景，DV 证书就够用了，而 Let's Encrypt 在 DV 这个档位上，成本归零，体验还更好。这些年我看过不少公司，项目本身很小，却在证书上花着大几千的预算，唯一原因就是没人愿意去尝试新方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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 拼接进去，就会导致客户端校验链不完整，报错"证