阿里雲實名驗證帳號 阿裡雲 SSL 證書部署到 ALB/CDN 後提示“不安全”或“證書鏈不完整”解決
先弄清楚：為什麼已經部署證書，瀏覽器還會提示不安全
很多人把 SSL 證書上傳到阿里雲 ALB 或 CDN 之後，以為 HTTPS 就一定能正常生效，結果打開網站仍然看到“不安全”“連線不是私人連線”或“證書鏈不完整”。這類問題最容易讓人誤判，以為是證書過期、平台沒部署成功，實際上真正出問題的地方往往不在證書本身，而在證書鏈、域名匹配、回源方式、邊緣節點快取、以及前後端混合內容。
阿里雲實名驗證帳號 阿里雲的 ALB 和 CDN 都屬於終端加速和分發層，瀏覽器看到的不是你伺服器上的原始配置，而是最終對外提供握手的那一層。如果這一層的證書格式不完整、私鑰不對、鏈路缺失，或者使用者實際訪問的域名和證書上的域名不一致，瀏覽器就會直接報警。換句話說，部署成功不等於可用，能握手成功也不等於沒有風險提示。
常見現象與對應含義
提示“不安全”但頁面能打開
這種情況通常代表 HTTPS 已經建立，但瀏覽器沒有把站點視為完全可信。最常見的原因有三個：第一，證書不是受信任 CA 簽發；第二，證書鏈缺少中間證書；第三，頁面裡仍然引用了 HTTP 資源。前兩種會直接影響瀏覽器對站點身份的判定，第三種則會讓頁面出現混合內容警告，有時雖然整體頁面仍可載入，但地址列會顯示不安全。
提示“證書鏈不完整”
這通常不是根證書問題，而是上傳到 ALB 或 CDN 的證書檔少了中間證書。某些證書檔案只包含站點證書，沒有把簽發機構的中間鏈一起帶上，瀏覽器在部分環境下還能自動補齊，在某些環境下卻無法完成驗證。這也是最常見、最容易忽略的錯誤之一。
不同地區、不同瀏覽器表現不一致
如果部分裝置正常，部分裝置異常，往往不是站點“有時好有時壞”，而是你使用的憑證鏈或配置依賴了客戶端的自動補全能力。某些新瀏覽器會自行下載中間證書，但舊系統、部分 App 內嵌瀏覽器、企業代理環境不一定會這樣做。只要有一環補不齊，就會出現不穩定的安全提示。
排查順序：先看域名，再看證書，最後看回源
第一步：確認訪問的域名與證書一致
證書不是“綁到服務上就行”，而是要和實際訪問的主機名完全匹配。比如你申請的是 `www.example.com` 的證書，但使用者實際訪問的是 `example.com`，或反過來；又或者你只給單域名證書，卻想同時覆蓋多個子域名，這都會導致瀏覽器提示異常。若使用萬用字元證書，也要注意它只覆蓋一層子域名，不能跨層匹配。
排查時先打開瀏覽器證書詳情，看“主體備用名稱”是否包含實際訪問域名。很多人只看證書是否“存在”，沒有核對 SAN，結果折騰半天都沒找到真正原因。
第二步：確認上傳的是完整證書鏈
阿里雲 ALB 和 CDN 都支援上傳 SSL 證書，但不同來源的證書包內容可能不同。有的 CA 會提供單獨的站點證書，有的會提供 full chain 文件，還有的會把證書與中間證書拆開。若你只上傳了 leaf certificate，而沒把中間證書一起帶上，就很容易出現“證書鏈不完整”。
最穩妥的做法，是直接使用 CA 提供的完整證書包，或把站點證書與中間證書合併成完整鏈後再上傳。對很多部署問題來說，這一步往往是關鍵。
第三步：確認私鑰與證書是一對
有些情況下，證書是對的，鏈也是完整的，但私鑰不是當初申請這張證書時對應的那一把。這種錯配在平台上不一定會立刻報錯，有時候上傳都能成功，但 TLS 握手時會失敗，或瀏覽器顯示異常。若你是在多次申請、替換、遷移的過程中操作，尤其要留意這個問題。
簡單判斷方式是核對證書與私鑰的指紋或公鑰內容是否匹配。若不能確認，直接重新匯出對應的完整證書包，避免沿用舊文件。
ALB 部署後不安全的典型原因
ALB 綁定成功，但前端協議沒有真正切到 HTTPS
有些人只在 ALB 監聽器上綁了 443 證書，卻沒有把 80 跳轉到 443，也沒有在應用層強制 HTTPS。結果使用者仍然可能透過 HTTP 入口進站，網站看起來“可訪問”，但地址列一開始就是不安全。這不是證書錯，而是入口策略沒做好。
正確做法是讓 80 端口做 301 跳轉到 HTTPS，或者在應用層強制所有請求都轉向加密協議。這樣即使使用者手動輸入 http，也能被統一導向安全連線。
後端回源配置不當導致重定向迴圈
ALB 前端是 HTTPS，但後端服務可能仍然按 HTTP 判斷請求來源。如果應用沒正確識別 `X-Forwarded-Proto`，就可能反覆把請求重定向到自身，造成跳轉異常。瀏覽器雖然看到的是 HTTPS，但頁面載入異常、資源丟失，最後也可能出現安全警告或混合內容提示。
部署這類場景時，要確認應用知道自己實際是站在 ALB 後面，並正確處理代理標頭。否則前端證書再正確，使用者體驗仍然不完整。
CDN 部署後證書鏈不完整的常見根源
上傳的是單段證書，不是完整鏈文件
CDN 最常見的錯誤，就是把 CA 發來的主證書直接丟上去，忽略了中間證書。某些管理介面會把它顯示成“上傳成功”，但實際對外提供握手時，節點拿到的不是完整鏈，因此部分客戶端無法驗證到可信根。這種問題特別容易在手機端、老版本瀏覽器、企業網路中暴露。
因此，部署前最好先確認證書檔案內容是否包含完整鏈。若平台要求 PEM 格式，通常應保證站點證書在前，中間證書在後，順序不要弄錯。若 CA 提供了 `fullchain.pem`，優先使用它，省去自己拼接時出錯的風險。
CDN 邊緣節點還在快取舊證書
有時你已經更新了證書，但某些地區的節點仍然使用舊配置，導致使用者時好時壞。這在 CDN 服務中很常見，因為配置需要向多個邊緣節點同步。若剛更新完就測試，可能會因為同步延遲而誤以為部署失敗。
遇到這種狀況，不要只看控制台狀態，還要從不同地區、不同網路、不同瀏覽器實測。若平台提供強制刷新配置或證書同步功能，也可以配合使用，縮短生效時間。
回源 HTTPS 配置與前端證書混淆
不少人把“CDN 前端證書”和“回源站點證書”混為一談。前端證書負責使用者到 CDN 的安全連線，回源證書則是 CDN 到源站之間的加密。這兩段是獨立的。前端證書正常，不代表回源一定正常；回源異常，也未必會直接顯示在瀏覽器地址列，但可能引發 502、握手失敗、頁面資源缺失，間接造成使用者認為網站“不安全”。
如果源站使用自簽證書，或者源站證書域名不匹配，CDN 回源時可能直接失敗。此時要么更換可信證書，要么按平台要求配置回源校驗策略，但前者通常更穩妥。
一套實用的修復思路
先重建證書包，再重新上傳
當你懷疑證書鏈有問題時，不要只在控制台裡反覆切換。最有效的方式是重新從 CA 下載完整證書包，確認包含站點證書與中間證書，然後重新上傳到 ALB 或 CDN。若平台支援直接匯入 PEM 格式，就用完整鏈文件；若支援分項填寫，則按要求拆分，但不要漏掉任何一段。
這一步的目的不是“碰碰運氣”，而是把不確定因素全部去掉。很多現場故障最後都靠這種最樸素的方法解決。
統一使用正確的域名入口
把所有可對外訪問的域名整理清楚：裸域名、www 子域名、API 子域名、測試域名，分別對應哪張證書，哪個入口，是否需要跳轉。只要其中一個域名沒有被證書覆蓋，使用者就可能撞到安全警告。若業務場景比較複雜，直接規劃好多域名證書或萬用字元證書，比事後修修補補省事得多。
啟用全站 HTTPS 並清理混合內容
證書鏈修好之後，如果頁面裡仍然引用 HTTP 圖片、JS、CSS 或接口，瀏覽器還是會提示不安全。這時候要從前端模板、靜態資源地址、第三方腳本、埋點代碼逐一排查，把所有資源都改成 HTTPS，或使用協議相對路徑。尤其是歷史較久的站點，很容易留下一批硬編碼的 HTTP 地址。
如果站點已經全面切到 HTTPS，還可以配合 HSTS 強化，讓瀏覽器記住只用安全連線。但在啟用 HSTS 前，請先確認整站和子域名都沒有任何 HTTP 依賴，否則會把錯誤放大。
如何快速判斷問題到底在誰身上
用瀏覽器看證書詳情
最直接的方法，是點開地址列的鎖頭圖示，看發給誰、有效期、簽發者、證書鏈。若主體名稱不對，問題在域名；若鏈條不完整，問題在證書包；若證書看起來正常但頁面還報警，問題多半在混合內容或跳轉邏輯。
從不同端分別測試
阿里雲實名驗證帳號 桌面瀏覽器、手機系統瀏覽器、App 內嵌 WebView、企業代理環境，對證書鏈的容忍度不一樣。若只有部分端異常，說明你的部署方式還不夠嚴謹。真正穩定的 HTTPS，不應依賴某個客戶端幫你補鏈。
不要忽略回源健康狀態
對 ALB 和 CDN 而言，前端證書只是表層，回源健康才是基礎。如果源站異常、回源握手失敗、源站超時，使用者最終看到的往往不是單純的 404，而是各種像“安全”問題一樣的異常表現。排查時要把前端、邊緣、源站三層分開看，避免把所有症狀都歸咎於證書。
阿里雲實名驗證帳號 最後的檢查清單
部署前
阿里雲實名驗證帳號 先確認證書覆蓋的域名範圍，再確認是否為完整鏈，最後檢查私鑰是否匹配。若是 ALB，還要想好 80 到 443 的跳轉策略；若是 CDN，還要確認前端證書與回源證書各自的配置是否正確。
部署後
用正式域名實測 HTTPS，檢查證書主體、鏈路、有效期和瀏覽器提示。再打開站點首頁，搜尋是否仍存在 HTTP 資源，必要時清理快取，避免舊配置干擾判斷。若是 CDN，別忘了從多地區、多網路測試同步狀態。
持續維護
證書不是一次性配置。它有有效期，有更新節奏，也可能在平台遷移、域名擴展、源站變更時被重新組裝。把證書文件、私鑰、完整鏈、到期時間整理成清單，才能在真正需要更新時少走彎路。很多“突然不安全”的故障，本質上都不是突然發生，只是前面埋下的隱患終於在某一天爆出來。
結語
阿里雲 SSL 證書部署到 ALB 或 CDN 後仍提示“不安全”或“證書鏈不完整”，本質上大多不是平台故障，而是配置細節出了偏差。只要按“域名是否匹配、證書鏈是否完整、私鑰是否對應、前後端是否都切到 HTTPS、回源是否正常”這條線逐項排查，絕大多數問題都能定位出來。真正穩定的 HTTPS，不只是把證書上傳上去，而是讓整條鏈路從使用者到源站都說得通、驗得過、跑得穩。
