網站 SSL 憑證錯誤怎麼辦？常見 HTTPS 憑證問題與排查方法
網站 SSL 憑證錯誤不一定只是憑證過期，網域不符、憑證鏈異常、TLS 設定錯誤以及 CDN 同步問題都可能導致 HTTPS 存取異常。本文整理常見 SSL 報錯及對應解決方法，幫助站長快速判斷問題原因並完成排查修復。
網站突然出現 SSL 憑證錯誤，很多人的第一反應都是「憑證是不是過期了」。但實際排查下來，憑證過期只是其中一種情況，網域沒有覆蓋、憑證鏈不完整、CDN 還在回傳舊憑證，都可能讓 HTTPS 出現異常。下面就結合幾種常見報錯，具體說說網站 SSL 憑證錯誤應該怎麼查，以及不同問題分別該怎麼處理。
一、先看瀏覽器報的是什麼 SSL 錯誤
不同 SSL 錯誤背後的原因並不一樣，Chrome、Edge 等瀏覽器通常會在安全提示頁面下面給出具體錯誤代碼。相比單純看到「連線不是私密連線」，這些代碼對定位問題更有價值。
常見錯誤提示 | 可能原因 | 優先檢查 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID | 憑證過期、尚未生效、本機系統時間錯誤 | 憑證有效期、電腦時間 |
NET::ERR_CERT_COMMON_NAME_INVALID | 目前存取網域沒有被憑證覆蓋 | CN、SAN 網域 |
NET::ERR_CERT_AUTHORITY_INVALID | 憑證鏈不完整、自簽憑證、CA 不受信任 | CA、Intermediate Certificate |
ERR_SSL_PROTOCOL_ERROR | TLS、HTTPS 或伺服器設定異常 | 443 連接埠、TLS 設定 |
您的連線不是私密連線 | 瀏覽器綜合安全警告 | 查看下面的具體錯誤代碼 |
SSL 憑證已過期 | 目前回傳的憑證超過有效期 | 線上憑證、伺服器或 CDN 設定 |
如果能先確定具體錯誤類型，後面的排查範圍會小很多：比如 ERR_CERT_DATE_INVALID，一般先查憑證時間；而 ERR_CERT_COMMON_NAME_INVALID，重點就應該放在網域比對，而不是反覆重裝同一張憑證。
二、先檢查網站目前實際回傳的 SSL 憑證
遇到 HTTPS 報錯時，我通常不建議第一步就進入伺服器後台重新申請或者重新安裝憑證。應該先確認一件更基礎的事情：使用者現在存取網站時，伺服器到底回傳了哪一張憑證？這一步看起來簡單，卻是很多 SSL 故障最容易忽略的地方。
你已經在伺服器後台上傳了一張新的憑證，後台顯示的有效期也完全正常，但網站前面如果還有 CDN、負載平衡或反向代理，使用者實際收到的並不一定是這張憑證。
常見情況包括：
SSL 憑證剛剛續期；
網站更換過 CDN；
修改過 DNS 解析；
網站存在多台源站；
CDN 不同節點憑證沒有同步；
Nginx 設定已經修改，但服務沒有重新載入；
一個 IP 上部署了多個 HTTPS 站台。
用 Chahu 先確認線上憑證狀態
這種情況下，可以先透過 Chahu 的 SSL 憑證檢測功能檢查網站目前對外回傳的 HTTPS 憑證。
輸入需要檢查的網域後，重點關注幾項資訊：
SSL 憑證是否仍在有效期內；
目前存取網域是否包含在憑證中；
憑證的簽發機構；
憑證鏈是否存在異常；
網站目前實際回傳的是新憑證還是舊憑證；
HTTPS 和 TLS 設定是否存在明顯問題。
這比單純進入伺服器後台看「憑證已經上傳成功」更有參考價值，因為線上檢測看到的是公網使用者真正連線網站時獲得的結果。
可以根據檢測結果快速判斷下一步：
檢測情況 | 後續處理方向 |
|---|---|
SSL 憑證已經過期 | 重新續簽並部署憑證 |
目前網域不在憑證中 | 重新簽發包含對應網域的憑證 |
憑證鏈不完整 | 檢查中繼憑證設定 |
回傳的仍然是舊憑證 | 檢查伺服器、CDN 和節點同步 |
憑證本身正常 | 繼續檢查 TLS、443 連接埠、CDN 或本機環境 |
先把「憑證本身的問題」和「伺服器設定的問題」分開，後面的排查會輕鬆很多。
三、SSL 憑證已經過期怎麼辦？
憑證過期是最常見，也是比較容易判斷的一類 SSL 錯誤。SSL 憑證都有明確的生效時間和失效時間。如果目前時間已經超過 Not After，瀏覽器就會認為這張憑證已經失效，並向使用者顯示安全警告。
常見報錯包括：
NET::ERR_CERT_DATE_INVALID或者直接提示：
憑證已過期
Certificate Expired解決方式並不複雜，重新續簽或者申請新憑證，然後部署到伺服器即可。
真正容易出問題的是：
憑證明明已經續簽了，網站卻仍然顯示舊憑證。
這種情況就不能只檢查 CA 平台或者伺服器面板裡的憑證有效期，還要確認線上實際回傳的憑證是否已經更新。
如果網站使用 Nginx，可以檢查設定中載入的憑證檔案路徑是否正確，例如：
ssl_certificate
ssl_certificate_key替換憑證之後還要重新載入 Nginx 設定，否則執行中的服務可能仍然使用之前載入的內容。
如果網站前面還有 CDN，也要繼續檢查 CDN 節點上的憑證是否同步完成。
四、憑證和網站網域不匹配怎麼辦？
另一種非常常見的情況，是憑證本身沒有過期，但存取網站時仍然出現：
NET::ERR_CERT_COMMON_NAME_INVALID這種錯誤通常意味著：
瀏覽器目前存取的網域，並沒有包含在這張 SSL 憑證的有效網域範圍內。
例如憑證中包含：
example.com
www.example.com此時存取：
https://example.com
https://www.example.com通常沒有問題。
但如果存取：
https://api.example.com而 api.example.com 並沒有出現在憑證的 SAN（Subject Alternative Name）中，瀏覽器就可能直接提示網域不匹配。
這種問題在新增二級網域以後尤其常見。
萬用字元憑證也要注意覆蓋範圍
例如：
*.example.com通常可以覆蓋：
www.example.com
api.example.com
shop.example.com但不要簡單理解成一張萬用字元憑證可以覆蓋任意層級的子網域。
如果實際業務使用的是：
api.shop.example.com就應該重新確認目前憑證是否真的覆蓋這個網域。
因此出現網域不匹配時，首先檢查憑證中的 SAN，而不是單純看憑證狀態是不是「有效」。
五、憑證沒過期，瀏覽器為什麼還是提示不安全？
「憑證明明還有幾個月才到期，為什麼瀏覽器還是報錯？」這種情況在實際維運中並不少見。憑證有效期只是 SSL 檢查中的其中一項，並不能代表整個 HTTPS 設定一定正常。
1. 憑證鏈不完整
瀏覽器驗證一張網站憑證時，並不是只檢查網站憑證本身。
一個完整的信任關係通常類似：
網站 SSL 憑證
↓
Intermediate CA
↓
Root CA伺服器一般不需要直接傳送根憑證，但應該正確提供需要的中繼憑證。
如果 Intermediate Certificate 缺失，就可能出現一個比較奇怪的現象：
自己電腦存取正常，部分手機或者其他使用者卻提示憑證不受信任。
這是因為不同作業系統、瀏覽器和裝置本機儲存的中繼憑證快取可能不同。
解決這種問題時，要檢查伺服器是否部署了完整憑證鏈，而不是只上傳單獨的一張網站憑證。
2. 使用了自簽憑證
自簽憑證比較適合內網、開發或者測試環境，但公網瀏覽器預設不會信任這種憑證。
因此很容易出現：
NET::ERR_CERT_AUTHORITY_INVALID如果是正式對公網提供服務的網站，通常應該使用受主流瀏覽器信任的 CA 簽發憑證。
3. 本機電腦時間錯誤
這個問題比較基礎，卻經常被忽略。
假設一張憑證的有效期是：
2026-08-01
至
2026-11-01但電腦本機時間錯誤地顯示為：
2027-01-10那麼從瀏覽器的角度來看，這張憑證已經過期了。
因此，如果只有某一台電腦出現 SSL 錯誤，而其他裝置存取都正常，可以檢查一下：
系統日期；
目前時區；
自動時間同步；
NTP 服務。
如果錯誤只發生在個別用戶端，本機環境往往比伺服器本身更值得先查。
六、SSL 憑證已經更新，為什麼網站還是顯示舊憑證？
剛剛續簽 SSL 憑證之後，最讓人頭疼的一種情況就是：後台已經換成新憑證，瀏覽器查看卻還是舊的。這種問題通常有幾個方向。
1. Nginx 或者 Apache 沒有重新載入
伺服器上的憑證檔案雖然已經被替換，但 Web Server 仍然可能執行著舊設定。
例如更換：
fullchain.pem
privkey.pem之後，沒有執行對應的 Reload 操作。
對於 Nginx，可以先檢查設定是否正常，然後重新載入：
nginx -t
nginx -s reload如果使用的是面板或者託管環境，也要確認系統有沒有真正重新載入 Web 服務。
2. 更新錯了虛擬主機
一台伺服器上往往不止一個網站。
例如：
example.com
www.example.com
api.example.com都可能擁有獨立的 server 設定。
如果憑證上傳到了另一個虛擬主機，即使檔案本身完全正常，目前網域仍然會繼續回傳舊憑證。
這時應該結合：
Server Name；
SNI；
443 監聽設定；
憑證檔案路徑；
一起檢查。
3. CDN 仍然在回傳舊憑證
如果網站使用 CDN，這一點尤其重要。
實際 HTTPS 鏈路通常不是：
使用者 → 源站而是：
使用者
↓
CDN 邊緣節點
↓
源站瀏覽器首先建立 HTTPS 連線的物件是 CDN 邊緣節點，因此使用者看到的也是 CDN 回傳的 SSL 憑證。即使源站已經更新，只要 CDN 端仍然載入舊憑證，前端存取結果就不會發生變化。
所以更換憑證以後，應該分別確認：源站憑證是否更新，以及 CDN 邊緣憑證是否更新。
4. 部分節點仍然使用舊憑證
如果網站使用全球 CDN、多節點或者負載平衡，還有一種情況是不同節點的設定狀態不一致。
例如：
上海節點 → 新憑證
香港節點 → 新憑證
新加坡節點 → 舊憑證這時就可能出現：自己存取完全正常，但國外客戶一直回報憑證過期。這種問題單靠本機瀏覽器重新整理很難發現，需要從公網或者不同網路環境檢查實際回傳的憑證。
七、HTTP 能打開，但 HTTPS 打不開怎麼辦？
如果：
http://example.com能夠正常存取，
但：
https://example.com完全打不開，
問題就不一定只是 SSL 憑證本身。
一個完整 HTTPS 請求大致要經過：
網域解析
↓
伺服器或 CDN
↓
TCP 443 連線
↓
TLS 握手
↓
SSL 憑證驗證
↓
HTTP 請求
↓
網站應用只要其中任何一個環節出現問題，HTTPS 都可能連線失敗。
先檢查 443 連接埠
HTTP 一般使用 80 連接埠，而 HTTPS 主要使用 443 連接埠。
如果伺服器安全群組、防火牆或者 Web Server 沒有開放 443，即使 SSL 憑證本身完全正確，HTTPS 照樣無法存取。
可以檢查：
雲端伺服器安全群組；
Linux 防火牆；
Nginx/Apache 監聽設定；
CDN 連接埠設定。
檢查 Web Server 是否啟用了 HTTPS
Nginx 設定中通常會看到類似：
listen 443 ssl;如果沒有正確監聽 443，或者 SSL 相關設定沒有載入，也會導致 HTTPS 連線失敗。
檢查憑證檔案路徑
如果憑證路徑填寫錯誤、檔案被刪除、權限不足，Web Server 在啟動或重新載入時也可能失敗。
因此修改 SSL 設定以後，最好先測試設定是否正確，再執行 Reload。
檢查 TLS 設定
如果伺服器只支援已經淘汰的 TLS 協定，或者加密套件設定存在問題，新版本瀏覽器也可能直接拒絕建立連線。
正式網站通常應該使用目前主流、安全的 TLS 設定，避免繼續依賴老舊協定。
八、用了 CDN 以後出現 SSL 錯誤，重點檢查這 4 項
部署 CDN 以後，SSL 排查會比單機伺服器多一層。
因為這時至少存在兩段連線：
訪客 ↔ CDN ↔ 源站如果兩邊都使用 HTTPS，那麼實際上存在：
訪客
↓ HTTPS
CDN
↓ HTTPS
源站因此，前端 HTTPS 正常，不代表 CDN 回源 HTTPS 也一定正常。
1. CDN 是否綁定了正確憑證
很多人在源站更新完憑證以後，以為整個網站就已經完成更新。
但對於 CDN 網站來說，邊緣 HTTPS 往往擁有單獨的憑證設定。
應該確認：
CDN 綁定的憑證是否正確；
憑證對應網域是否一致；
憑證是否仍在有效期內；
新增子網域是否已經加入憑證。
2. CDN 節點是否已經同步
剛更換憑證或者新增網域後，不同邊緣節點可能存在短暫的設定狀態差異。
如果部分地區正常、部分地區報憑證錯誤，就應該重點檢查節點同步情況。
3. CDN 回源 HTTPS 是否正常
有時候使用者到 CDN 這一段完全正常，但 CDN 到源站建立 TLS 連線時失敗。
例如：
使用者 → HTTPS → CDN
↓
HTTPS
↓
源站如果源站憑證過期、網域驗證失敗或者 TLS 設定異常，CDN 可能無法正常回源。
最終網站表現出來的未必是瀏覽器憑證警告，也可能是：
502
525
526
SSL Handshake Failed不同服務商的錯誤碼會有所區別，但排查邏輯基本一致。
4. 檢查 SNI 設定
同一個 IP 上部署多個 HTTPS 網站時，伺服器通常依賴 SNI 判斷應該回傳哪一張憑證。
如果 SNI 設定錯誤，可能出現：
存取 example.com伺服器卻回傳：
otherdomain.com 的憑證瀏覽器自然會認為憑證與存取網域不匹配。
這種問題經常出現在：
多站台伺服器；
反向代理；
CDN 回源；
負載平衡；
這些場景中。
九、網站 SSL 憑證錯誤可以按這個順序排查
如果不確定問題到底出在哪裡，可以按照下面的順序逐層檢查：
瀏覽器出現 HTTPS / SSL 錯誤
↓
查看具體錯誤代碼
↓
使用 Chahu 檢查公網實際回傳的 SSL 憑證
↓
憑證是否過期？
├─ 是 → 續簽並重新部署憑證
└─ 否
↓
目前網域是否被憑證覆蓋？
├─ 否 → 重新簽發正確憑證
└─ 是
↓
憑證鏈是否完整？
├─ 否 → 補充 Intermediate CA
└─ 是
↓
檢查 443 連接埠和 TLS 設定
↓
檢查 Nginx / Apache 設定
↓
網站是否使用 CDN？
├─ 是 → 檢查 CDN 憑證、節點同步、SNI 和回源 HTTPS
└─ 否 → 繼續檢查源站 HTTPS 設定
↓
重新測試網站 HTTPS 狀態這種方式比看到報錯以後直接重新申請憑證更有效，因為很多 HTTPS 問題實際上和憑證簽發本身沒有關係。尤其是剛完成 CDN 切換、憑證續簽或者伺服器遷移的網站，先確認公網實際回傳結果，往往能夠省掉大量不必要的排查時間。
結語
SSL 憑證報錯看起來只是瀏覽器裡的一條安全提示，但真正排查起來，問題可能出現在憑證、網域、憑證鏈、伺服器、TLS、CDN 或者用戶端任意一個環節。憑證過期反而是相對簡單的一類情況。實際維運中更容易浪費時間的，往往是憑證已經更新但線上仍然回傳舊憑證、SAN 沒有覆蓋新增網域、憑證鏈缺失，或者源站和 CDN 之間的 HTTPS 設定沒有同步。
所以遇到網站 SSL 憑證錯誤時，不必一開始就重新申請憑證。先確認網站目前實際回傳的憑證，再按照有效期 → 網域比對 → 憑證鏈 → 443 連接埠 → TLS → Web Server → CDN的順序逐層排查，通常更容易找到真正的問題所在。
相關問答
1. 個人部落格和電商網站選的 SSL 憑證能一樣嗎？
完全不一樣。免費憑證基本都是 DV 等級，只驗證你有沒有網域的控制權，適合個人部落格、測試專案這類對身分驗證要求不高的場景。但電商、支付、政務這類涉及資金交易或敏感資訊的業務，使用者需要確認網站背後是真實可信的組織，這時候就必須用 OV 或 EV 等級的付費憑證。加密強度上免費和付費確實沒區別，但付費憑證提供組織身分驗證、技術支援、保險理賠這些額外保障。
2. 萬用字元憑證和多網域憑證到底該選哪個？
看你的網域結構。萬用字元憑證格式是 *.example.com，能覆蓋同一主網域下所有一級子網域，比如 www.example.com、api.example.com、shop.example.com，新增子網域不用額外操作。多網域憑證（SAN 憑證）是針對不同主網域的，比如同時保護 example.com、example.net、example.org 這幾個完全不同的網域。如果你的子網域層級很深，比如 api.shop.example.com，萬用字元憑證是覆蓋不了的，需要單獨處理。
3. 電腦上存取正常，手機瀏覽器卻提示憑證不受信任，怎麼回事？
這種情況大概率是憑證鏈的問題。不同作業系統和瀏覽器內建的根憑證庫不一樣，老版本的 Android 手機可能沒有某些 CA 的根憑證。如果伺服器只回傳了網站憑證、沒有把中繼憑證也帶上，電腦端可能因為本機快取了中繼憑證而正常存取，但手機端缺少這個中繼憑證就會報錯。解決方案是在伺服器上部署完整的憑證鏈，把中繼憑證和網站憑證合併在一起。
4. 本機電腦時間不對，真的會導致瀏覽網頁報 SSL 憑證錯誤嗎？
會的，而且非常常見（報錯通常為 NET::ERR_CERT_DATE_INVALID）。HTTPS 憑證的校驗是基於時間戳的（有一個「生效時間」和「到期時間」）。如果你的電腦或手機系統時間偏離嚴重（比如電腦電池沒電導致時間倒退回幾年前，或者跑到未來），瀏覽器用本機時間去比對憑證的有效期，就會誤判該憑證「尚未生效」或「已經過期」。建議開啟系統的 NTP 自動同步時間功能。