证书申请流程:Let's Encrypt 与商业证书
我记得刚开始搞全站 HTTPS 迁移那会儿,最头疼的就是证书怎么来。
自己签发吧,浏览器不认。买商业证书吧,流程繁琐还贵。直到 Let's Encrypt 出现,这局面才算打破。
今天咱们就聊聊这两种主流证书的申请流程。我尽量把实操中的坑都抖出来。
一、Let's Encrypt:免费自动化的代表
Let's Encrypt 的最大特点是「全自动」。你想想看,一个命令下去,证书就自动生成、自动续签,多省事。
它的核心是靠 ACME 协议完成的。客户端向服务器证明你对域名的控制权,验证通过后就直接签发。
1. 常用客户端:Certbot
我个人习惯用 Certbot。它是 EFF 官方维护的,支持 Nginx 和 Apache 的自动配置。
# 安装 Certbot (Ubuntu 20.04)
sudo apt update
sudo apt install certbot python3-certbot-nginx
# 获取证书 (自动修改 Nginx 配置)
sudo certbot --nginx -d example.com -d www.example.com
# 仅获取证书 (手动配置)
sudo certbot certonly --nginx -d example.com
执行完上面命令,证书通常保存在 /etc/letsencrypt/live/example.com/ 目录下。
这里面有几个关键文件:
fullchain.pem:证书链(服务端证书 + 中间证书)privkey.pem:私钥(务必保密!)
2. 验证方式:HTTP-01 与 DNS-01
Let's Encrypt 最常用的验证方式有两种。这里存在一个很容易被忽视的性能差异。
- HTTP-01:在
/.well-known/acme-challenge/下放一个 文件。简单直接,但要求 80 端口必须开放。 - DNS-01:在 DNS 解析记录中添加一个 TXT 记录。不需要 80 端口,适合纯四层负载均衡或内网。
⚠️ 我曾经踩过的坑
早期我有个前端项目用了 CDN,80 端口流量全被 CDN 回源到了后端节点。结果 Certbot 验证时找不到公网 80 端口,一直报连接超时。后来改用 DNS-01 验证方式才解决。
3. 自动续签
Let's Encrypt 证书有效期只有 90 天。你一定得配上自动续签机制。
# 测试续签
sudo certbot renew --dry-run
# 添加到 crontab (每周执行一次)
0 3 * * 1 /usr/bin/certbot renew --quiet
嗯,这里要注意:续签前一定确认你的网站还在正常运行。我之前设定了一个每月执行的定时任务,结果那段时间服务器宕机了,证书过期了才发现。
4. Let's Encrypt 的优缺点
| 优点 | 缺点 |
|---|---|
| 免费,无隐藏成本 | 有效期只有 90 天 |
| 自动化程度高 | 某些旧设备/浏览器不信任 ISRG Root X1 |
| 生态完善,社区活跃 | 单域名有速率限制(每周 50 张) |
| 支持泛域名(需 DNS-01) | 需要开放 80 或 443 端口用于验证 |
二、商业证书:信任与服务的另一种选择
说白了,商业证书卖的就是「信任」和「服务」。
银行、支付系统、金融类网站,他们更喜欢商业证书。因为商业证书的根证书几乎在所有浏览器和系统里都预埋了,不会出现兼容性问题。
1. 选购与验证
商业证书根据验证级别分为三种:
- DV(域名验证):验证域名所有权,最基础,跟 Let's Encrypt 差不多。
- OV(组织验证):验证企业组织信息,证书里会显示公司名称。
- EV(扩展验证):验证企业身份更严格,浏览器地址栏会显示公司名+绿色锁标。
# 生成 CSR(证书签名请求)
openssl req -new -newkey rsa:2048 -nodes \
-keyout example.key \
-out example.csr \
-subj "/C=CN/ST=BeiJing/L=BeiJing/O=Company/CN=example.com"
# 将 CSR 提交给 CA 机构
# 等待 CA 审核通过后下载证书
提交 CSR 后,CA 会通过邮件或后台验证你提交的组织信息。这个流程少则几小时,多则三五天。
我在项目中遇到过一家客户,注册资本较大,EV 验证时被要求提供近期对公流水。当时客户财务不配合,拖了一周才搞定。
2. 商业证书的差异
| 对比项 | Let's Encrypt | 商业证书(DV/OV/EV) |
|---|---|---|
| 价格 | 免费 | 数百~数千元/年 |
| 有效期 | 90 天 | 1~3 年(部分 CA 最长 2 年) |
| 签发速度 | 分钟级 | DV 分钟级;OV/EV 小时~天级 |
| 浏览器兼容性 | 较新(可能遇到 Android 2.3.6 以下) | 广(兼容较老设备) |
| 管理方式 | 全自动命令行 | 手动填写 CSR,通过 CA 后台管理 |
| 组织验证 | 不包含 | OV/EV 包含企业信息 |
| 泛域名支持 | 支持(需要 DNS-01 验证) | 支持(部分 CA 额外收费) |
三、如何选择:我的建议
这个问题没有标准答案,但我个人有几个判断准则:
- 内网或测试环境:直接用自签证书,或者用 Let's Encrypt 做 Staging 测试。
- 对外公开的商业站点:如果用户群体老、设备杂(比如银行客户),我建议用商业证书。别为了省钱最后导致用户访问不了。
- API 或管理后台:如果只面向程序调用,Let's Encrypt 完全够用,配上自动续签就好。
- 企业合规需求:如果客户要求审计留痕,或者必须显示公司信息,那就用 OV 或 EV 证书。
四、核心流程对比图
下面这张图展示了我最常用的证书选型和申请决策路径。你可以直接照着这个流程走。
核心要点:
证书选型不是技术问题,是信任成本和运维成本之间的权衡。Let's Encrypt 解决了「免费+自动化」的痛点,而商业证书解决了「兼容性+信任」的痛点。搞清楚自己的用户场景,选择就简单了。
我个人习惯:非核心业务用 Let's Encrypt 加上 crontab 自动续签;核心业务或面向用户的网站,买一个 OV 商业证书,运维省心,用户也放心。
💡 小提示
无论你选哪种证书,申请完以后记得做两件事:一是用 openssl 检查证书链是否完整,二是用测试工具(比如 SSL Labs)扫描一遍,确认没有潜在漏洞。