Defaults.Exposed › 修復 › TLS 憑證健康度

如何修復 TLS 憑證健康度

你的 SSL/TLS 憑證是一張數位身份證，向訪客證明他真的在和你的網站對話——而不是冒牌貨——並驅動瀏覽器裡那把鎖。本項檢查關注的是：這張憑證是否有效且受信任、是否即將過期，以及是否用強壯、現代的密碼學構建。

對您業務的關鍵影響： 一張損壞或過期的憑證會用一個全螢幕的紅色「您的連線不是私密連線」警告替換掉你的網站。多數訪客會立刻離開、不再回來——線上銷售停擺、註冊停擺，而那個本該私密的連線還可能被悄悄攔截。

這會讓您付出什麼代價

• 你的憑證在一個週末悄悄過期；到週一，每個訪客都撞上一個全頁安全警告，你的結帳和聯絡表單全癱了，每過一小時才有人注意到並續期，你就在丟銷售。
• 一個在咖啡館或酒店 Wi-Fi 上付款的客戶收到警告，說你的憑證與你的網域不符——他以為你的網站是假的或被駭了，放棄了購買，還告訴別人它「看著不靠譜」。
• 一個大客戶的 IT 團隊在簽約前做安全掃描，看到一張自簽名或不受信任的憑證，把你標為風險——這筆生意就卡在一個零成本就能修好的問題上。
• 你的憑證用了過時的簽名方法或孱弱的金鑰；現代瀏覽器開始對它顯示警告，一次安全稽核因為這早已被踢出推薦名單多年的密碼學給你扣分。
• 你收取卡付款，而你的付款服務商重新稽核你；一把弱金鑰或一張過期憑證違反了支付安全規則，你的線上結帳被凍結，直到改正為止。

為什麼它重要。 憑證是你網站安全中最顯眼的一塊——健康時它隱形，損壞時它會用一個嚇人的警告把你整個網站拖垮，把客戶直接趕向競爭對手。憑證過期是網站意外宕機的頭號原因，而它完全可以預防。拿一張有效憑證是免費的，而保持它健康，多半只是讓它自動續期的事。

這是什麼，大白話版

當有人訪問你的網站時，要讓他放心輸入密碼或卡號，得發生兩件事。第一，連線必須加密，讓陌生人讀不到它。第二——也是人們容易忘的部分——訪客的瀏覽器必須確信另一端真的是你的網站，而不是一個搭起的、以假亂真的冒牌貨。同時完成這兩件事的東西，就是你的 TLS 憑證（常被叫做「SSL 憑證」）。

把它想像成你網域的防偽身份證。一家公認機構頒發它，它蓋著你的網域和一個到期日，並攜帶打亂連線的那把加密金鑰。一切核對無誤時，瀏覽器顯示那把鎖，你的網站正常載入。身份證出了問題時，瀏覽器會做與安撫訪客相反的事——它彈出一個全螢幕警告，實質上是說，「此網站可能不安全。」

本項檢查關注這張身份證的健康度，涵蓋四件各自獨立、任一都能讓它失效的事：

• 它有效且受信任嗎？——由公認機構簽發、匹配你的確切網域、非自簽名、未過期。
• 它快過期了嗎？——因為一張失效的憑證會把你整個網站拖垮。
• 它用強方法簽名了嗎？——舊簽名演算法可被偽造。
• 它的金鑰夠強嗎？——一把弱金鑰原則上可被攻破。

先把好消息說在前頭：拿一張健康憑證是免費的，而保持它健康，多半只是讓它自動續期、不必任何人記著的事。

這會讓你付出什麼代價

• 週末宕機。 一張憑證在週五深夜悄悄到了到期日。本該跑的續期沒跑（伺服器搬了、腳本壞了、沒人注意到）。到週六早上，每個訪客——以及每個 Google 爬蟲——看到的是一個全頁紅色警告，而不是你的首頁。你的店關了，你卻還不知道。技術修復只要幾分鐘；丟掉的一個週末的銷售、以及那些認定你「倒閉了」的客戶，卻回不來了。

• 被放棄的結帳。 一個客戶正用手機在酒店 Wi-Fi 上購物。你的憑證與他敲入的網域不太匹配（比如它涵蓋 shop.yourbiz.com 卻不涵蓋他用的光禿禿的 yourbiz.com）。瀏覽器警告他網站「可能在冒充」你的。對一個不懂技術的買家而言，這讀起來就是詐騙——他關掉標籤頁，而你永遠不知道這筆生意存在過。

• 擱淺的合約。 一個大客戶的安全團隊在簽約前做例行掃描。結果顯示你某個子網域上有一張自簽名或不受信任的憑證。即便其他一切都好，這一面紅旗就把一次快速批准變成了一來一回、拖延生意——為的是一個零成本就能修好的問題。

• 慢動作的警告。 你的憑證技術上有效，卻用 SHA-1 簽名——一個瀏覽器一直在淘汰的舊方法。一次瀏覽器更新之後，一部分訪客開始看到你在自己最新機器上重現不出的警告。客服工單零星地進來，說網站「看著壞了」，你卻查不出原因。

• 合規失敗。 你收取卡付款。在一次重新稽核中，你服務商的檢查標記出一把弱金鑰、或一張已失效的憑證。卡安全規則要求強壯、當代的加密——於是你的線上付款被暫停，直到你重新簽發，在最糟糕的時刻凍結了營收。

它到底是什麼（四個部分）

一張憑證能以四種不同方式不健康，本頁全部涵蓋。每一項在底層都是一項獨立檢查，但對你而言它們都是「我的憑證沒問題吧？」

1. 有效且受信任

這是大頭——也是憑證健康度裡唯一一項關鍵、最高權重的檢查。一張憑證只有在以下全部成立時才算「有效且受信任」：

• 它由一家瀏覽器已經信任的公認憑證機構簽發（Let’s Encrypt、DigiCert、Sectigo、Google、Amazon 等）。
• 它匹配訪客正在使用的確切網域——包括子網域。一張 www.yourbiz.com 的憑證若不同時涵蓋 yourbiz.com，就會在光禿禿的網域上報警告。
• 它不是自簽名——即不是你頒發給自己的那種，它加密卻證明不了你是誰。
• 它當前處於其日期視窗之內——沒過期，也沒有（雖怪卻確實會發生）被設成將來才開始生效。
• 它的信任鏈完整——簽它的那家機構自己也受信任，一路向上。

只要其中任何一項失敗，瀏覽器就顯示那個可怕的「您的連線不是私密連線」頁面，本項檢查就硬性失敗。好長這樣：一張來自公認機構的憑證，涵蓋你實際使用的每一個網域和子網域，舒舒服服地處在它的有效期內。

2. 不會馬上過期

每張憑證都有一個硬性結束日期。免費的通常持續 90 天；付費的常為一年。過了那個日期，信任瞬間蒸發——沒有寬限期。本項檢查衡量還剩多少天，以及這與誰簽發了它如何相互作用：

• 如果它已過期、或將在 7 天內過期，那被視為關鍵——一個續期已失敗的信號。
• 如果它在 30 天內過期且非自動管理，那是一個該立刻續期的警告。
• 如果它來自一家自動續期的服務商（Let’s Encrypt、Cloudflare、Google、Amazon、ZeroSSL 等）且至少還剩一週，它就通過——因為它預期會在死線前自我續期。
• 跑道很長（90 天以上，或自動管理）是乾淨的通過。

好長這樣：一張自動管理、無需任何人觸碰就自我續期的憑證。永不出現過期宕機的最可靠方式，就是讓一台機器、而非一個人，對續期負責。

3. 強簽名演算法

每張憑證都用一個加密演算法「簽名」，讓瀏覽器能偵測篡改。舊演算法——MD5 和 SHA-1——已被證明可偽造，意味著攻擊者原則上能炮製一張看起來合法地屬於你的欺詐憑證。本項檢查在憑證使用強壯、現代的簽名時通過：SHA-256 或更強（SHA-384、SHA-512）、現代 ECDSA，或 Ed25519/Ed448。MD5 和 SHA-1 不通過。好長這樣：SHA-256 或更好——這是每張免費及現代憑證的預設，所以對近年簽發的任何憑證，這都很少成為問題。

4. 強金鑰

憑證攜帶一把做實際打亂工作的加密金鑰。如果那把金鑰太短，現代計算能力——只要資源足夠——就能攻破它，讓攻擊者冒充你的網站或解密流量。公認的最低標準是 2048 位元 RSA 或 256 位元橢圓曲線（EC）。本項檢查在這些尺寸或以上時通過，以下則不通過。好長這樣：2048 位元（或 4096 位元）RSA，或一把像 P-256 這樣的 256 位元 EC 金鑰——同樣是現代免費憑證的預設。

關於後三項的說明：有效且受信任是那個驅動警告頁的關鍵項。簽名和金鑰強度關乎的是面向未來與稽核——一張近期的免費憑證幾乎總會自動通過它們，但它們是安全審查會查的東西，所以值得做對。

如何修復（免費，約 15 分鐘）

把這一節交給運營你網站或主機的人——修復免費。 一張有效、強壯、自動續期的憑證透過 Let’s Encrypt 或任何現代主機分文不取。我們只對長期監控它是否保持健康收費，而不對修復收費。如果你沒有 IT 人員，下面的平台說明能把多數業主帶到位。

第 1 步——用一張免費、受信任的憑證取得（或替換）憑證。 這一步同時修好有效性、簽名和金鑰強度，因為現代免費憑證預設使用 SHA-256 和強金鑰。

• Cloudflare： 在 SSL/TLS → Overview 裡，把模式設為 Full (Strict)。Cloudflare 為你簽發並自動續期一張受信任的邊緣憑證；確保你的來源端也有一張有效憑證，「Strict」才能生效。
• Google Workspace / Microsoft 365 託管或任何 cPanel 主機： 找 SSL/TLS Status 並執行 AutoSSL。它自動設定並續期免費憑證。
• 建站工具（Squarespace、Wix、Shopify、現代 WordPress 主機）： SSL 通常預設開著——確認它在你的網域/安全設定裡已啟用，並且同時涵蓋 yourbiz.com 和 www.yourbiz.com。
• 你自己的 Linux 伺服器（Nginx/Apache）： 用 Certbot 安裝 Let’s Encrypt——sudo certbot --nginx -d yourbiz.com -d www.yourbiz.com（或 --apache）。要一把現代 EC 金鑰，加上 --key-type ecdsa。用 -d 列出你提供服務的每一個主機名稱，讓憑證全部匹配。

第 2 步——讓續期自動化，從此不再過期。 這是防住週末宕機情景的那一步。

• 在 Let’s Encrypt 伺服器上，確認續期計時器已啟動並測試它：sudo certbot renew --dry-run。Certbot 通常會裝一個自動計時器；若沒有，加一個每日 cron 任務：0 3 * * * certbot renew --quiet。
• 在 Cloudflare、cPanel AutoSSL 和託管/建站工具主機上，續期由它們替你處理——沒什麼要安排的。

第 3 步——確保它涵蓋正確的名稱。 最常見的「有效卻報警告」原因是名稱不匹配。憑證必須涵蓋客戶實際使用的每一個主機名稱——光禿禿的網域、www，以及像 shop. 或 app. 這樣的任何子網域。產生憑證時，把每一個都包含進去（像 *.yourbiz.com 這樣的萬用字元一次涵蓋所有子網域）。

第 4 步——如果只標記了簽名或金鑰強度，重新簽發即可。 你不需要買任何東西：產生一張全新的憑證（第 1 步），新的那張會自動使用 SHA-256 和一把強金鑰。在你自己的伺服器上，你可以顯式釘一把現代金鑰——例如 EC 用 openssl ecparam -genkey -name prime256v1 -out server.key，RSA 用 openssl genrsa -out server.key 4096——然後重新簽發。

第 5 步——驗證，然後回這裡重新檢測。 用一條快速指令確認日期、簽發者和金鑰——echo | openssl s_client -servername yourbiz.com -connect yourbiz.com:443 2>/dev/null | openssl x509 -noout -dates -issuer -subject——然後重新執行本項檢查。

常見錯誤

• 把「我們裝過一次 SSL」當成完事了。 憑證按時鐘過期。沒有自動續期，問題不是它會不會失效，而是何時——通常在最不方便的時刻。
• 涵蓋了 www 卻不涵蓋光禿禿的網域（或反過來）。 兩者都必須在憑證上，否則其中一個會拋出名稱不匹配警告。同樣的陷阱也會絆住後來新加的子網域。
• 在一個其實公開的「測試」子網域上留著自簽名憑證。 它加密，所以感覺安全——但瀏覽器（和安全掃描器）把它當作不受信任，它是經典的稽核紅旗。
• 以為付費就更安全。 一張免費的 Let’s Encrypt 憑證與一張昂貴的一樣受信任、一樣加密。多花錢不會造出一把更強的鎖。
• 續了憑證卻忘了重載伺服器。 一張躺在磁碟上的新憑證在 Web 伺服器被重載、把它讀進去之前毫無作用——這是「我續了它但還顯示過期」的一個意外常見的原因。
• 悄悄失敗的自動續期。 一個續期任務可能損壞（檔案被移、DNS 變了、埠被封），卻繼續安靜地「成功」。監控到期日——而不只是續期任務——才是真正在它咬人之前抓到它的辦法。

常見問題