做 Web 项目时，域名往往会越用越多。
最开始可能只有一个 example.com，后来逐渐增加：
example.com
├── www.example.com 官网
├── app.example.com Web 应用
├── api.example.com API
├── admin.example.com 管理后台
└── docs.example.com 文档
这些服务可能分别部署在 Nginx、Docker、云服务器或者不同的应用平台上。
每个域名都要配置 HTTPS，如果分别申请 SSL 证书，后续更新和维护就比较分散。
这种情况下，可以考虑使用通配符证书。
一张证书覆盖多个子域名
通配符证书使用 * 匹配一个层级的子域名。
比如：
*.example.com
可以用于：
www.example.com
api.example.com
admin.example.com
docs.example.com
但不能直接匹配：
example.com
dev.api.example.com
前者需要额外包含根域名，后者属于更深层级的子域名。
这里还要区分两个概念：
一张通配符证书可以部署到多个服务，并不代表它必须部署到同一台服务器。
只要域名匹配、证书有效，且服务正确配置了对应的证书和私钥，就可以使用。
不过，多个服务共用私钥也意味着风险范围更大，生产环境中需要根据安全要求决定是否共用。
申请证书一定要在服务器上操作吗？
不一定。
像 Certbot、acme.sh 这样的工具，比较适合需要长期自动签发和续期的场景。
但如果只是想快速验证项目、部署一个临时环境，或者给面板上传一张证书，未必需要先安装这些工具。
这里使用 LapseZero 的在线工具演示：
支持免费申请单域名和通配符 SSL 证书。
实际流程是：
1. 填写域名
选择通配符证书，输入 example.com。
下图使用自有测试域名 ssl-demo.hxkit.com，与文中的 example.com 示例对应。
2. 完成 DNS 验证
根据页面提示，在 DNS 服务商后台添加指定记录。勾选同时覆盖主域名时，需要添加两条 TXT 记录，两个值分别填写。
为什么要操作 DNS？
因为证书签发方需要确认你确实拥有该域名的控制权。
DNS 验证有一个好处：不依赖你的应用是否已经部署，也不要求服务器对外开放 80 端口。
因此，哪怕项目还在内网开发阶段，只要你有域名的 DNS 管理权限，也能完成验证。
3. 获取证书
验证成功并完成签发后，下载证书及私钥文件，放到需要使用 HTTPS 的服务上。
一个 Nginx 部署示例
以 api.example.com 为例：
server {
listen 443 ssl;
server_name api.example.com;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
证书部署完成后，检查并重新加载配置：
nginx -t
nginx -s reload
其中证书路径和后端端口都需要替换为自己的实际配置。
如果使用其他服务器软件或云产品，部署方式会有所不同。
在线申请工具的私钥问题
使用第三方网站申请证书时，需要关注私钥在哪儿生成。
如果私钥由服务端生成，就必须考虑如何安全地传输、保存和删除。
上面这个工具的私钥是在浏览器本地生成的，私钥不会上传给平台服务器。
这可以减少私钥在申请过程中暴露给第三方服务的风险。
但下载后的私钥依然要自己管理好，比如：
- 不要提交到 Git 仓库。
- 不要把私钥打包到前端静态资源中。
- 在服务器上限制私钥文件的访问权限。
- 不要将包含真实私钥的截图或日志公开。
一次申请与自动续期是两回事
这种在线方式适合快速获取证书，但证书到期后依然需要更新。
如果是长期生产环境，我更推荐把申请、续期、部署和监控串成自动化流程。
尤其是同时维护 API、管理后台、多个业务站点时，不能只考虑第一次部署成功，还要考虑几个月后证书如何替换。
文中使用的 LapseZero 还支持证书自动续期和部署，不要太方便。
如果有 DNS 验证或者部署方面的问题，也欢迎交流。
