【導(dǎo)讀】二級域名HTTPS證書不是可選項，而是現(xiàn)代網(wǎng)站架構(gòu)的事實剛需。只要你的業(yè)務(wù)用了 mail、admin、api、shop 等子域，就得一一配齊，否則安全隱患就在那里等著被放大。

為什么單獨談二級域名HTTPS證書？因為它常常被忽略
很多站長花了大力氣給 www.example.com 和 example.com 配好了SSL，卻發(fā)現(xiàn)訪問 blog.example.com 或 dev.example.com 時瀏覽器赫然跳出“不安全”警告。殊不知，每個子域在HTTPS世界里都是獨立實體——就像一棟大樓的各個單元房，門鎖得各自安好。

更嚴(yán)重的是：一旦某個二級域名仍在裸奔HTTP，黑客就可能借此注入惡意腳本、劫持Cookie、實施中間人攻擊，進(jìn)而波及其他同源站點（SameSite策略并不能完全隔離）。

主流方案怎么解決二級域名HTTPS證書問題？
目前有三類成熟做法，適配不同技術(shù)能力和預(yù)算水平：

通配符證書 (*.example.com)：一張證書覆蓋所有三級及以下子域（如 api.example.com、cdn.static.example.com），適合子域較多且變動頻繁的場景；
多域名SAN證書：單張證書綁定多個指定域名（如 example.com + www.example.com + shop.example.com + admin.example.com），靈活性高、兼容性強(qiáng)；
逐個申請DV證書：分別為每個二級域名單獨走一遍Let’s Encrypt驗證流程，適合初期少量子域、后期逐步擴(kuò)容的情形。
沒有絕對最優(yōu)解，關(guān)鍵是看你未來幾年是否會大規(guī)模拓展子服務(wù)體系。

通配符 vs SAN：該怎么選？一看就知道
二者表面相似，內(nèi)在邏輯迥異：

? 通配符證書優(yōu)點是省事、彈性好，缺點是對DNS驗證強(qiáng)依賴（必須能操作TXT記錄）、不支持根域名+泛域名同簽（即 .example.com ≠ example.com）；
? SAN證書優(yōu)點是可以混合不同類型域名（example.com + app.io + cdn.net）、無需改DNS、天然包含主域，缺點是新增子域需重新申請、總量有限制（通常≤100個）。
舉例：如果你下周就要上線 mobile.example.com 和 pay.example.com，用通配符立刻生效；若你還打算把 old-site.com 也遷進(jìn)來，則SAN更合適。

實戰(zhàn)教學(xué)：三步搞定二級域名HTTPS證書部署（以Nginx為例）
假設(shè)你已持有適用于 blog.example.com 的證書文件（fullchain.pem 和 privkey.pem）：

將證書上傳至服務(wù)器任意安全目錄（如 /etc/nginx/ssl/blog/）；
編輯對應(yīng) server{} 塊，在 listen 443 ssl; 下方添加：
ssl_certificate /etc/nginx/ssl/blog/fullchain.pem;ssl_certificate_key /etc/nginx/ssl/blog/privkey.pem;
保存后執(zhí)行 nginx -t && systemctl reload nginx 生效。
然后打開 https://blog.example.com 測試是否顯示綠色鎖圖標(biāo)。若有異常，請繼續(xù)閱讀下一節(jié)排障指南。

在此處添加配圖

常見報錯速查手冊：為什么二級域名HTTPS證書總是配不好？
以下是工程師高頻遭遇的問題及應(yīng)對思路：

? “NET::ERR_CERT_COMMON_NAME_INVALID” → 檢查證書 Subject Alt Names 是否包含 blog.example.com，而非僅 example.com；
? 頁面樣式丟失、JS報錯 → 極大概率混用了HTTP資源，F(xiàn)12 Console中搜索 Mixed Content 關(guān)鍵字定位；
? 刷新后偶爾恢復(fù)HTTP → Nginx配置中缺失 permanent 重定向規(guī)則，應(yīng)在80端口server塊內(nèi)補(bǔ)上：return 301 https://$host$request_uri;；
? 子域間 Cookie無法共享 → 需設(shè)置 Set-Cookie 的 Domain=.example.com 參數(shù)，并啟用 SameSite=None; Secure 標(biāo)識。
這些問題大多不出現(xiàn)在證書本身，而出現(xiàn)在周邊聯(lián)動配置上。

最后提醒：別忘了CDN和負(fù)載均衡器的存在
如果你在二級域名前面加了Cloudflare、騰訊云CDN或Nginx Proxy，那真實的HTTPS鏈條其實是這樣的：

[用戶] ←HTTPS→ [CDN節(jié)點] ←HTTPS→ [源站]

這就意味你需要兩張證書：

CDN側(cè)：由CDN廠商自動管理（如CF免費Universal SSL）；
源站側(cè)：你自己部署的二級域名HTTPS證書，用來保障最后一公里通信安全。
兩者缺一不可。否則可能出現(xiàn)“前臺看著綠鎖，后臺卻明文傳參”的危險局面。

說到底，二級域名HTTPS證書不是炫技配件，而是分布式服務(wù)架構(gòu)下的責(zé)任分割線。每一個對外開放的入口，都應(yīng)該有自己的加密盾牌。認(rèn)真對待它，就是在加固整個數(shù)字地基。

延伸問答
Q：我能用同一張通配符證書同時保護(hù) example.com 和 sub.example.co.uk 嗎？
A：不能。“.”只作用于同一注冊域（Registered Domain）之下，co.uk 是英國二級國家代碼頂級域（ccTLD），需單獨申請。
Q：API接口放在 api.example.com 上，也需要HTTPS嗎？
A：必須需要。所有涉及身份令牌（JWT/Bearer Token）、敏感參數(shù)傳遞的接口，都應(yīng)強(qiáng)制HTTPS，否則Token極易被盜用。