CDN多域名证书配置方法详解
深夜調試CDN節點時，服務器突然彈出紅色警報——某個邊緣節點的TLS證書離過期只剩3小時。指尖敲打鍵盤的速度不自覺加快，冷汗卻沿著後頸滑落。這已是我職業生涯第七次被證書問題突襲，而每次災難背後，都藏著對多域名證書配置的認知盲區。
真正的CDN老手都明白，單域名證書在流量洪峰前脆弱得像紙糊的城牆。當你管理著數百個客戶域名，面對全球分散的邊緣節點，多域名證書(SAN Certificate)才是救命的鋼筋骨架。但業界80%的配置失誤都發生在這裡：有人把證書鏈拼錯導致iOS設備報錯，有人誤用泛域名證書觸發瀏覽器安全機制，更有人因證書覆蓋不全被釣魚網站鑽了空子。
生成SAN證書時，openssl命令裡的subjectAltName參數是關鍵命脈。記得三年前某電商大促，因技術員漏填了cdn-user.domain.com這個關鍵節點域名，導致千萬用戶看到紅色警告頁。教訓是用文本編輯器預先列出所有域名，再用xargs轉為DNS.1,DNS.2格式，比手動輸入可靠十倍。別小看這個動作，當你需要同時保護app.domain.com、img.domain.com、api.domain.com等十幾個子域名時，精準比速度更重要。
泛域證書(*.domain.com)看似省心實則暗藏殺機。去年某視頻平台被劫持的教訓仍歷歷在目——攻擊者利用通配符特性註冊了payments.domain.com.fake.com這種子域名。如今我的方案是「泛域證書+SAN白名單」雙重鎖：先用星號證書兜底，再在SAN裡顯式聲明payment、account等高危子域。當Cloudflare和Akamai的WAF日誌裡出現對未聲明子域的探測請求時，這套機制已攔下十七次定向攻擊。
混合架構才是頂級CDN的實戰形態。把靜態資源證書託管給Cloudfront，API流量走Azure Front Door的專屬證書，敏感支付鏈接用KeyCDN獨立證書隔離。這需要你在證書籤發時就規劃好SAN分組：切忌把login.domain.com和promo.domain.com混在同一張證書裡。某金融客戶曾因促銷活動證書私鑰洩露，險些讓黑客摸進核心交易系統。
凌晨四點的證書更新窗口，我盯著終端裡滾動的OCSP響應代碼。突然某東京節點返回\”certificate unknown\”，血壓瞬間飆升。問題出在證書鏈拼接——中間CA證書竟用了PEM格式而非DER。這種細節在文檔裡永遠是輕描淡寫的一行字，卻能讓整個亞太區服務癱瘓。現在我的應急包裡永遠存著三樣東西：完整證書鏈模板、備用私鑰加密U盤、以及能直接連線三家CA機構的專屬客服電話。
當太陽升起時，所有邊緣節點的SSL握手時間從387ms降至92ms。監控圖上代表證書錯誤的紅色尖刺消失不見，就像從未發生過險情。這行幹久了才懂，所謂高可用架構，不過是把別人踩過的坑用水泥反覆澆築成護城河。而護城河的基石，永遠是那串看似枯燥的域名列表。
评论: