二级域名HTTPS证书：一个都不能少的安全拼图

【导读】二级域名HTTPS证书不是可选项，而是现代网站架构的事实刚需。只要你的业务用了 mail、admin、api、shop 等子域，就得一一配齐，否则安全隐患就在那里等着被放大。

为什么单独谈二级域名HTTPS证书？因为它常常被忽略
很多站长花了大力气给 www.example.com 和 example.com 配好了SSL，却发现访问 blog.example.com 或 dev.example.com 时浏览器赫然跳出“不安全”警告。殊不知，每个子域在HTTPS世界里都是独立实体——就像一栋大楼的各个单元房，门锁得各自安好。

更严重的是：一旦某个二级域名仍在裸奔HTTP，黑客就可能借此注入恶意脚本、劫持Cookie、实施中间人攻击，进而波及其他同源站点（SameSite策略并不能完全隔离）。

主流方案怎么解决二级域名HTTPS证书问题？
目前有三类成熟做法，适配不同技术能力和预算水平：

通配符证书 (*.example.com)：一张证书覆盖所有三级及以下子域（如 api.example.com、cdn.static.example.com），适合子域较多且变动频繁的场景；
多域名SAN证书：单张证书绑定多个指定域名（如 example.com + www.example.com + shop.example.com + admin.example.com），灵活性高、兼容性强；
逐个申请DV证书：分别为每个二级域名单独走一遍Let’s Encrypt验证流程，适合初期少量子域、后期逐步扩容的情形。
没有绝对最优解，关键是看你未来几年是否会大规模拓展子服务体系。

通配符 vs SAN：该怎么选？一看就知道
二者表面相似，内在逻辑迥异：

✅ 通配符证书优点是省事、弹性好，缺点是对DNS验证强依赖（必须能操作TXT记录）、不支持根域名+泛域名同签（即 .example.com ≠ example.com）；
✅ SAN证书优点是可以混合不同类型域名（example.com + app.io + cdn.net）、无需改DNS、天然包含主域，缺点是新增子域需重新申请、总量有限制（通常≤100个）。
举例：如果你下周就要上线 mobile.example.com 和 pay.example.com，用通配符立刻生效；若你还打算把 old-site.com 也迁进来，则SAN更合适。

实战教学：三步搞定二级域名HTTPS证书部署（以Nginx为例）
假设你已持有适用于 blog.example.com 的证书文件（fullchain.pem 和 privkey.pem）：

将证书上传至服务器任意安全目录（如 /etc/nginx/ssl/blog/）；
编辑对应 server{} 块，在 listen 443 ssl; 下方添加：
ssl_certificate /etc/nginx/ssl/blog/fullchain.pem;ssl_certificate_key /etc/nginx/ssl/blog/privkey.pem;
保存后执行 nginx -t && systemctl reload nginx 生效。
然后打开 https://blog.example.com 测试是否显示绿色锁图标。若有异常，请继续阅读下一节排障指南。

在此处添加配图

常见报错速查手册：为什么二级域名HTTPS证书总是配不好？
以下是工程师高频遭遇的问题及应对思路：

❓ “NET::ERR_CERT_COMMON_NAME_INVALID” → 检查证书 Subject Alt Names 是否包含 blog.example.com，而非仅 example.com；
❓ 页面样式丢失、JS报错 → 极大概率混用了HTTP资源，F12 Console中搜索 Mixed Content 关键字定位；
❓ 刷新后偶尔恢复HTTP → Nginx配置中缺失 permanent 重定向规则，应在80端口server块内补上：return 301 https://$host$request_uri;；
❓ 子域间 Cookie无法共享 → 需设置 Set-Cookie 的 Domain=.example.com 参数，并启用 SameSite=None; Secure 标识。
这些问题大多不出现在证书本身，而出现在周边联动配置上。

最后提醒：别忘了CDN和负载均衡器的存在
如果你在二级域名前面加了Cloudflare、腾讯云CDN或Nginx Proxy，那真实的HTTPS链条其实是这样的：

[用户] ←HTTPS→ [CDN节点] ←HTTPS→ [源站]

这就意味你需要两张证书：

CDN侧：由CDN厂商自动管理（如CF免费Universal SSL）；
源站侧：你自己部署的二级域名HTTPS证书，用来保障最后一公里通信安全。
两者缺一不可。否则可能出现“前台看着绿锁，后台却明文传参”的危险局面。

说到底，二级域名HTTPS证书不是炫技配件，而是分布式服务架构下的责任分割线。每一个对外开放的入口，都应该有自己的加密盾牌。认真对待它，就是在加固整个数字地基。

延伸问答
Q：我能用同一张通配符证书同时保护 example.com 和 sub.example.co.uk 吗？
A：不能。“.”只作用于同一注册域（Registered Domain）之下，co.uk 是英国二级国家代码顶级域（ccTLD），需单独申请。
Q：API接口放在 api.example.com 上，也需要HTTPS吗？
A：必须需要。所有涉及身份令牌（JWT/Bearer Token）、敏感参数传递的接口，都应强制HTTPS，否则Token极易被盗用。