WordPress SSL 憑證安裝與 HTTPS 轉換完整指南：免費與付費怎麼選、轉換後要收尾什麼

幫朋友把新架好的部落格上線那天，網站打開的瞬間，Chrome 在網址列旁邊標了「不安全」。WordPress 裝好了、佈景主題也選好了，缺的只有一件事：SSL 憑證還沒裝，網站還跑在 http 上。這篇文章要處理的就是這一整條流程——從憑證到底在保護什麼，到免費與付費該怎麼選、六個步驟怎麼裝，再到 HTTPS 轉換之後最容易被漏掉的收尾工作。內容偏實作，會把每一步的代價和風險一起寫出來。

SSL／TLS 到底保護什麼、不保護什麼

先把名詞對齊。SSL（Secure Sockets Layer）是舊名稱，現在實際在跑的協定叫 TLS（Transport Layer Security），但業界習慣還是把憑證叫「SSL 憑證」。你買或申請的那張憑證，功能是讓瀏覽器能驗證「這個網域確實是你的」，並據此協商出一條加密連線。裝好之後網址從 http:// 變成 https://，多出來的 s 就是 secure。

Google 在 web.dev 的官方說明把 HTTPS 的價值拆成三塊：防止中間人篡改網頁內容（例如插入廣告或惡意程式）、保護使用者的瀏覽隱私、以及讓現代瀏覽器功能可用。第三點常被忽略但很關鍵：地理位置、Service Worker、getUserMedia 這些 API 都要求安全來源，網站跑在 http 上等於整批功能都用不了（參考 web.dev：Why HTTPS matters）。

但更值得花時間講清楚的是它不保護什麼，因為這裡的誤解會直接讓人做錯決策：

• 它不代表網站本身可信。釣魚網站一樣可以申請到免費憑證，一樣有鎖頭。鎖頭的語意是「這條連線沒被竊聽或篡改」，不是「這家公司很正派」。
• 它不防後台被入侵。密碼太弱、外掛版本過舊、佈景主題有漏洞——這些跟憑證完全無關。裝了 SSL 之後被駭的站，我看過不少。
• 它不隱藏你連到哪個網站。連線的目標網域在握手階段仍可能被觀察到，加密保護的是內容，不是「你造訪了誰」這件事本身。
• 它不會自動修好你網頁裡的 http 資源。這就是下面會講的混合內容問題。

對數位遊牧者和遠距工作者來說，HTTPS 的實際意義在另一個場景：你在咖啡廳、共享空間、機場的公共 Wi-Fi 上登入自己的網站後台時，加密連線是唯一擋在你和同一個網段其他人之間的東西。如果你經常在外面工作，這篇 在咖啡廳與共享空間工作：公共 Wi-Fi 資安與禮儀全指南裡的網路安全段落值得一起看。

至於 SEO：Google 在 2014 年就公告把 HTTPS 納入排名訊號（HTTPS as a ranking signal）。但我不會告訴你裝完排名會漲多少，因為排名變動沒辦法單獨歸因給一個設定。務實的說法是：HTTPS 屬於「不做會扣分」的基本衛生，不是成長槓桿。把它當地基處理就好。

DV、OV、EV 三種驗證層級：瀏覽器上已經看不出差別

憑證分三種驗證層級，差別在「憑證機構（CA）在簽發之前查了什麼」：

1. DV（Domain Validation，網域驗證）：只驗證你能控制這個網域。驗證方式通常是在網站特定路徑放一個檔案，或在 DNS 加一筆 TXT 記錄。全自動，幾秒到幾分鐘完成。
2. OV（Organization Validation，組織驗證）：除了網域，CA 還會查核申請單位是不是登記存在的法人實體。需要人工，通常要幾個工作日並提供文件。
3. EV（Extended Validation，擴充驗證）：最嚴格的人工查核流程，會驗證公司的法律、營運與實體存在。

這裡是最需要更新認知的一點。過去 EV 憑證的賣點是網址列會顯示綠底的公司名稱，但這個介面已經不存在了。Chromium 官方文件〈EV UI Moving to Page Info〉明確記載，Chrome 從第 77 版起把 EV 的公司名稱從網址列移到點擊鎖頭後才會看到的「網站資訊」面板，理由是團隊的使用者研究資料（見 Chromium：EV UI Moving to Page Info）。其他主流瀏覽器也走了同一個方向。

結論很直接：如果你買 EV 的動機是「讓訪客看到公司名稱、提高信任感」，那個動機在今天已經失效了。一般訪客看到的畫面，DV 憑證和 EV 憑證長得一模一樣。三種層級用的加密演算法與金鑰強度也沒有差別——差別純粹在簽發前的人工查核深度，以及隨之而來的合約與保固條款。

那 OV／EV 現在還有意義嗎？有，但受眾很窄：某些產業的合規要求、企業採購的資安檢核表、或是需要在憑證裡呈現法人身分給第三方系統驗證的情境。如果你是個人部落格、內容站、作品集網站、接案工作室，DV 就是正確答案。

免費 Let’s Encrypt 與付費憑證：真實差異在哪

先給判準，再看表。選憑證只要問三個問題：我需要人工組織驗證嗎？我需要泛網域（wildcard）憑證嗎？我需要一份寫明賠償責任的合約嗎？三題都是「不需要」，就用 Let’s Encrypt。

Let’s Encrypt 是一家非營利的公開信任憑證機構，簽發的是 DV 憑證，全自動、免費。它在效期上有明確規定：官方文件寫「Our default certificates are valid for 90 days」，並建議每 60 天就續期一次；另外也開放訂閱者選用六天效期的短效憑證，建議每三天續一次。這些效期無法自行調整，官方明言沒有例外（見 Let’s Encrypt 官方 FAQ）。

90 天聽起來很短，但實務上你不會手動處理——所有正規的整合方式都內建自動續期。真正該擔心的不是效期短，而是自動續期的排程有沒有真的在跑，這點放在後面單獨講。

項目	免費 SSL（Let’s Encrypt）	付費 SSL（商業 CA）
費用	免費	依發行商與層級差異很大，從相當低價到每年數萬元台幣不等，以各發行商公告價為準
加密強度	同一套 TLS 標準，與付費無異	同一套 TLS 標準，與免費無異
驗證層級	僅 DV	可選 DV／OV／EV
預設效期	90 天（另有可選的 6 天短效期）	受 CA/Browser Forum 上限規範，且上限正在分階段縮短
續期方式	全自動（ACME 協定）	視發行商，可能仍需人工重新簽發與部署
泛網域憑證	支援，但必須用 DNS-01 驗證	支援
保固／賠償	無保固條款	有，金額與適用條件依合約，務必看清排除條款
技術支援	社群論壇與文件	多數提供付費客服
適合對象	個人站、內容站、作品集、多數小型商業站	有合規需求、需要組織驗證、或採購流程要求商業合約者

關於保固金額，我刻意不寫具體數字：那些「最高賠償 XX 萬美元」的數字實務意義有限，因為請求賠償的條件通常限制在「CA 自身的簽發錯誤造成的直接損失」，而且舉證門檻很高。把它當成合約條款去讀，不要當成保險額度去比大小。

要判斷你的架站預算該怎麼分配，憑證這一項其實通常不是重點。網站架設費用全解析 2026：自架、找接案、套版平台三種方案的價格與取捨裡把主機、網域、佈景主題的比重拆得比較清楚，可以對照看。

動手之前的四項前置確認

裝憑證本身很快，卡住的通常是前置條件沒滿足。下面四件事先確認完，安裝流程幾乎不會出錯。

1. DNS 已經正確指向這台主機。憑證簽發要驗證網域所有權，而驗證是透過這個網域「現在」解析到的伺服器進行的。如果你剛改 A 記錄還沒生效，驗證一定失敗。先用 dig 你的網域 或線上 DNS 查詢工具確認。
2. 80 埠可以從外部連進來。Let’s Encrypt 最常用的 HTTP-01 驗證方式，是由 CA 去讀取 http://你的網域/.well-known/acme-challenge/<TOKEN> 這個路徑；官方文件明確指出這個方式需要對外開放的 80 埠，而且無法用於泛網域憑證（見 Let’s Encrypt：Challenge Types）。如果你已經在主機上設了「所有 http 一律 301 到 https」的規則，要確認這條規則有排除 /.well-known/ 路徑，否則續期會在你毫無察覺的情況下失敗。
3. 如果要泛網域憑證，先準備 DNS API。同一份官方文件說明，泛網域（*.example.com）只能用 DNS-01 驗證，也就是自動在 _acme-challenge 建立 TXT 記錄，因此需要 DNS 供應商提供 API。文件也提醒：把完整權限的 API 憑證放在網頁伺服器上是風險，盡量用權限收窄的憑證。
4. 先做一份完整備份。包含檔案和資料庫。後面要改 Site Address、要做全站字串取代，這兩個動作出錯的話網站會打不開。這是唯一一個「不做也可以，但出事時你會非常後悔」的步驟。

如果你連主機、網域這層還在猶豫，建議先把架構決定清楚再回來裝憑證：自架站新手的六個決策：網域、主機、佈景主題與上線後維護該怎麼取捨把這幾個取捨拆開來談。

六步驟安裝 SSL 憑證（面板與 VPS 兩種路徑）

安裝路徑取決於你的主機類型。共享主機幾乎都用控制面板一鍵完成，VPS 則是自己跑 ACME 客戶端；兩條路的步驟骨架一樣，差在誰負責跑那支程式。

路徑 A：共享主機／cPanel 的 AutoSSL

如果你的主機是 cPanel，這件事大概不用你動手。cPanel 官方文件說明 AutoSSL 預設的憑證供應商就是 Let’s Encrypt，而且它會在每晚的系統更新流程（upcp）中自動執行，也會在新帳號建立後執行（見 cPanel：Manage AutoSSL）。你要做的是確認它有在跑、以及你的網域沒有被排除。

使用者端的檢查介面是 cPanel 的「SSL/TLS Status」。官方文件說明這個介面可以監看各網域的憑證狀態，並用「Expiring Soon」、「Unsecured」、「Has AutoSSL Problems」等條件篩選出有問題的網域（見 cPanel：SSL/TLS Status）。上線後每季進去看一眼，是成本最低的維護動作。

路徑 B：VPS／自管伺服器的 Certbot

自管主機的標準工具是 EFF 的 Certbot。官方使用手冊寫得很清楚：「Most Certbot installations come with automatic renewal out of the box」，多數安裝方式已內建自動續期；而 certbot renew 只會續期「已經到了該續的時間」的憑證，從 4.0.0 版起的判準是剩餘效期少於三分之一（見 Certbot User Guide）。

通用六步驟

1. 確認主機的憑證管理入口。cPanel 找「SSL/TLS」與「SSL/TLS Status」；Plesk 找 Let’s Encrypt 擴充；寶塔面板在網站設定的 SSL 分頁；純 Linux 環境就是安裝 Certbot 或其他 ACME 客戶端。
2. 選定憑證來源。要用免費就選 Let’s Encrypt（或其他支援 ACME 的免費 CA）。若面板沒開放，可以請主機客服開啟。
3. 產生 CSR（只有手動上傳付費憑證時才需要）。一鍵安裝與 ACME 客戶端都會自動處理金鑰與簽發請求。手動流程才需要自己在面板產生 CSR，再把 CA 回傳的憑證與中繼憑證貼回去。中繼憑證（intermediate／chain）漏貼是手動安裝最常見的錯，症狀是桌機瀏覽器看起來正常、手機或某些客戶端卻報憑證錯誤。
4. 完成網域所有權驗證。一般網域用 HTTP-01，泛網域用 DNS-01。這一步失敗絕大多數是 DNS 沒生效、80 埠被擋、或 /.well-known/ 被重寫規則吃掉。
5. 套用憑證到網域。勾選網域按安裝。完成後直接用 https://你的網域 打開確認，並點開鎖頭看憑證的有效期與簽發者對不對。
6. 設定 http 到 https 的 301 導向。面板通常有「Force HTTPS Redirect」開關；沒有的話在 Apache 用 .htaccess、Nginx 用 return 301。Google 的網站搬遷文件明確建議用伺服器端的永久導向（301 或 308）（見 Google Search Central：How to move a site）。

WordPress 這一端還有兩個設定要處理。第一是後台強制加密：WordPress 官方的進階管理文件建議在 wp-config.php 設 FORCE_SSL_ADMIN，官方說明是「for when you want to secure logins and the admin area so that both passwords and cookies are never sent in the clear」，並註明舊的 FORCE_SSL_LOGIN 已在 4.0 版棄用（見 WordPress.org：HTTPS 與 WordPress.org：Editing wp-config.php）。

同一份文件還提到一個很容易踩的坑：如果你的 WordPress 跑在反向代理後面、由代理負責 SSL，就要讓 WordPress 認得 HTTP_X_FORWARDED_PROTO 標頭，否則會進入無限重導迴圈。用 Cloudflare、Nginx 反代或某些容器化架構的人特別容易遇到。文件同時也誠實寫明這些做法的邊界——它讓竊取 cookie 變得困難得多，但不等於消除所有風險。

第二是外掛。WordPress 外掛目錄裡有幾款專門處理 HTTPS 轉換的外掛（例如安裝量很高的 Really Simple SSL），能自動改寫輸出中的 http 資源網址、設定導向。要說清楚的是：這類外掛是即時改寫輸出，不是真的把資料庫裡的舊網址改掉，所以它是很好的過渡與保險機制，但不該當成永久解——資料庫該清還是要清，理由在下一節。

HTTPS 轉換後的五項收尾

憑證裝好只是完成一半。下面五項是我每次做 HTTPS 轉換都會逐條跑過的清單，漏掉任何一項都會留下後遺症。

一、混合內容（Mixed Content）——先搞清楚現在的瀏覽器行為

混合內容指的是頁面本身用 https 載入，但頁面裡的圖片、CSS、JS 還指向 http。這裡有一個廣為流傳但已經過時的說法：「一張 http 圖片就會把鎖頭打掉」。現代瀏覽器的行為已經不是這樣了。

MDN 的混合內容文件把它分成兩類：可升級的（upgradable）與應封鎖的（blockable）。可升級的包含 <img> 的 src、<audio>／<video> 的 src、<source>，以及 CSS 的 background-image 等圖片屬性——瀏覽器會自動把這些請求從 http 升級成 https；但如果網址的主機是 IP 位址而不是網域名稱，就直接封鎖。至於 <script>、<link> 樣式表、<iframe>、fetch()／XMLHttpRequest、帶 srcset 的圖片、網頁字型、CSS 的 url() 值等等，全部屬於封鎖類，瀏覽器會直接擋掉（見 MDN：Mixed content）。

兩個容易看漏的細節。第一，同一張圖片用 src 會被升級，用 srcset 或包在 <picture> 裡卻是被封鎖的——WordPress 預設就會為圖片輸出 srcset，所以「圖片會自動升級」這個安慰在 WordPress 站上經常不成立。第二，MDN 的可升級清單雖然列了 CSS 的 background-image 這類圖片屬性，但它的封鎖清單同時寫著「CSS 中所有使用 url() 值的情況」；這兩份清單在 CSS 這一塊本身就有重疊，所以實務上不要賭它會被升級，直接把 CSS 裡的 http 網址改掉最省事。

所以你實際會看到的症狀變了：不是鎖頭破掉，而是「某張圖片載不出來」或「某個功能整個壞掉」。樣式表被擋 → 版面亂掉；腳本被擋 → 輪播、表單驗證、彈窗失效；升級後的圖片網址在對方伺服器上不存在 → 圖片變空白，而且沒有退回 http 的備援。

怎麼找？按 F12 打開開發者工具，看 Console 的警告與 Network 面板被封鎖的請求。逐一把來源改成 https 或改成不帶協定的相對路徑。常見來源是舊文章裡貼的外部圖片、第三方嵌入碼、以及頁面編輯器裡直接填的外部網址——用 Elementor 之類的視覺編輯器建站的人尤其要翻一遍舊頁面，可以搭配 Elementor 新手教學：從安裝到做出第一個頁面的完整步驟裡的元件結構去對照哪些欄位會塞外部網址。

如果舊網址實在太多，可以用 CSP 的 upgrade-insecure-requests 指示瀏覽器把站內所有不安全網址當成安全網址處理。但 MDN 明確列出它的限制：它不會升級指向第三方的頂層導覽連結，也不能取代 HSTS，而且資源如果真的沒有 https 版本，請求就直接失敗、不會退回 http。官方建議的做法是搭配 Content-Security-Policy-Report-Only 先觀察再強制執行（見 MDN：upgrade-insecure-requests）。把它當緩衝墊，不是抹布。

二、資料庫裡寫死的舊網址

WordPress 後台「設定 → 一般」裡的「WordPress 位址」與「網站位址」要都改成 https 開頭。WordPress 官方文件說明這兩個欄位控制 WordPress 的所在位置，也可以改用 wp-config.php 的 WP_SITEURL 與 WP_HOME 常數手動指定（見 WordPress.org：Migrating WordPress）。

但欄位改完只解決了一部分。文章內容、自訂欄位、選項表裡那些當初用絕對路徑寫死的 http://你的網域/... 還在原地。官方文件也涵蓋了直接修改資料庫的做法（wp_options 的 siteurl 與 home、以及文章內容中的網址），實務上多數人會用 Better Search Replace 這類外掛做全站字串取代。

做這件事有兩個注意事項。第一，先跑「乾跑」（dry run）模式看會影響幾筆，再實際執行；第二，官方文件特別強調搬遷時絕對不要改 GUID 欄位——GUID 是 feed 訂閱端用來判斷「這是不是同一篇」的識別碼，改了會讓 RSS 訂閱者收到一整批重複的舊文章通知。取代時記得排除 GUID。

三、301 導向與固定連結重刷

導向的原則前面說過：用伺服器端永久導向。值得補充的是 Google 網站搬遷文件裡的兩個細節：從 HTTP 搬到 HTTPS 不需要使用 Search Console 的「變更網址」工具（那是換網域才用的）；而導向規則官方建議至少維持一年。另外要記得更新 sitemap 並重新提交、清掉舊的。

WordPress 這端還有一個小動作常被忘記：到「設定 → 永久連結」按一次儲存，重新產生重寫規則。這不會改變你的網址結構，但能讓 .htaccess 的規則重新寫入，避免舊規則和新的 HTTPS 導向規則打架。改完之後把 CDN 或快取外掛的快取清一次。

四、Search Console 與分析工具要重新對齊

這是最容易被漏掉、卻直接影響你之後判讀數據的一項。Search Console 把 http:// 和 https:// 視為不同的資源（property）。如果你原本驗證的是 http 版，轉換後 http 資源的數據會逐漸歸零，而 https 資源如果沒建立，你就等於什麼都看不到。建議直接建立「網域」層級的資源，一次涵蓋所有協定與子網域。操作細節可以參考 Google Search Console 新手完整教學：從驗證網站到找出可優化關鍵字。

分析工具那邊也要檢查：GA4 的資料串流網址、以及任何寫死在追蹤碼裡的 http 網址都要更新，否則你會在報表裡看到一批來源不明的自我推薦流量。轉換後第一週把即時報表打開看一眼，確認事件還在進來。不熟悉 GA4 設定的話，Google Analytics 4 新手教學：安裝、看懂報表到追蹤轉換裡有資料串流的設定位置。

五、順手把 HTTP/2 的紅利拿走

現代 HTTP/2 與 HTTP/3 在瀏覽器端實質上都要求加密連線，也就是說沒有 HTTPS，你連不上這些協定的多工與標頭壓縮好處。轉換完之後值得請主機確認有沒有啟用 HTTP/2 以上，這通常是主機端的一個開關而不是你要寫的程式。速度這條線還有其他更關鍵的因素，WordPress 佈景主題推薦 2026：免費與付費主題怎麼選（含速度考量）裡談的主題肥大問題影響通常比協定版本更大。

HSTS：它擋什麼，開之前要先確認什麼

設好 301 導向之後還有一個殘留風險：訪客第一次輸入網址時走的仍然是 http，那一次請求在被導向之前是明文的，攻擊者可以在那個瞬間攔截並阻止升級（SSL 剝離攻擊）。HSTS（HTTP Strict Transport Security）就是為了關掉這個縫隙。

它的原理是回應一個 Strict-Transport-Security 標頭，告訴瀏覽器「在接下來的 max-age 秒內，這個網域一律直接用 https 連，不要先試 http」。Google 的 HTTPS 導入指引也把「開啟 HSTS 與安全 cookie」列在轉換流程的後段，並提醒已把你的站列為 HSTS host 的用戶端，一旦你的 TLS 設定出錯（例如憑證過期）就會直接硬失敗——文件明言 HSTS 就是被刻意設計成這樣（見 web.dev：Enable HTTPS on your servers）。

但這是本文唯一一個我要特別提醒「設錯會鎖住自己」的設定，因為 HSTS 是單向門。MDN 的官方說明列出幾個必須事先知道的行為：

• 這個標頭只能透過 https 回應才有效。從 http 回應的 HSTS 標頭會被瀏覽器忽略，這是為了防止中間人偽造。
• 一旦部署，之後如果你需要退回 http，在 max-age 到期前是被鎖住的。要關閉必須改成 max-age=0，而且這個指令只有在瀏覽器發出安全請求並收到該回應時才生效——MDN 的原文是「By design, you cannot disable HSTS over insecure HTTP」——刻意不讓你從明文連線關掉它。換句話說，如果 https 已經壞掉，你連關閉它的機會都沒有。
• 要先從很短的 max-age 開始，等你確定 https 會一直可用之後再往上加。這是整段裡最重要的一句，而它不是 MDN 的說法——Google 官方的 HSTS 預載服務把它寫成明確的部署建議：分階段拉長 max-age（先 5 分鐘、再一週、再一個月），每一階段都要「修掉出現的問題，並且等滿該階段的 max-age 之後才進下一階段」（見 hstspreload.org：Deployment Recommendations）。
• 網域一旦成為 HSTS host，使用者就無法點過去繞過憑證錯誤警告。這正是它防中間人的機制，代價是「憑證過期時整站直接進不去，連跳過的選項都沒有」。
• includeSubDomains 會把政策套用到所有子網域，但不會反向套用到上層網域。如果你有子網域還沒上 https，加了這個指令會直接讓那些子網域不可用。
• 加入瀏覽器預載清單（preload）需要 max-age 至少 31536000 秒（一年）且必須帶 includeSubDomains。預載能解決「第一次請求」的漏洞，但代價是幾乎不可逆：預載服務自己就寫明「列入預載清單無法輕易撤銷」，而且變更要透過 Chrome 版本更新才會抵達使用者，需要好幾個月；官方因此明說，除非你確定整站與所有子網域都能長期支援 HTTPS，否則不要申請（見 hstspreload.org）。

（未另註明來源者皆見 MDN：Strict-Transport-Security。）

我的實務建議：新站上線、確認所有子網域都有憑證之後，先設一個短的 max-age 觀察一兩週，確認沒有任何路徑非得走 http，再逐步拉長。preload 除非你確定這個網域長期只做 https，否則不急著加。要誠實說清楚它防的範圍：HSTS 只防「連線被降級成明文」這件事，它不防釣魚、不防你的後台被入侵、也不防憑證機構本身出錯。

憑證到期與自動續期失敗：徵兆與排查順序

憑證過期是最不該發生、卻很常發生的意外，因為它幾乎都不是「忘記續」，而是「以為在自動續，其實排程早就掛了」。這一節給你徵兆與排查順序。

徵兆

• 瀏覽器出現全頁攔截警示（Chrome 的 NET::ERR_CERT_DATE_INVALID 之類），而不是網址列旁邊的小提示。憑證過期是硬錯誤，訪客看到的是整頁紅底警告。
• 桌機正常、手機或 API 客戶端報錯：這通常不是過期，而是中繼憑證鏈不完整。桌機瀏覽器常有快取的中繼憑證可以補，其他客戶端沒有。
• 只有某個子網域壞掉：憑證的 SAN 清單裡漏了那個名稱，或那個子網域被 AutoSSL 排除了。
• 續期在特定時間點後全部失敗：常見於改過 DNS、換過主機、或加了新的重寫規則之後。

排查順序

1. 先確認到底是哪一種錯誤。點開瀏覽器的憑證檢視器看有效期與簽發者，或用 openssl s_client -connect 你的網域:443 -servername 你的網域 直接看回傳的憑證鏈。先分清「過期」、「鏈不完整」、「名稱不符」三者，後面的動作完全不同。
2. 檢查自動續期排程還在不在。Certbot 官方手冊指出可以在 /etc/crontab 檢查，或用 systemctl list-timers 看有沒有對應的 timer；也可以用 --dry-run 測試整個續期流程而不會真的寫出憑證，官方對這個旗標的說明是「Test ‘renew’ or ‘certonly’ without saving any certificates to disk」（見 Certbot User Guide）。--dry-run 是這整節最有價值的一個指令：它讓你在憑證還沒到期之前，就知道下一次續期會不會成功。
3. 檢查 HTTP-01 的驗證路徑通不通。直接用瀏覽器或 curl 打 http://你的網域/.well-known/acme-challenge/test，看回什麼。如果被 301 導向到 https、被防火牆擋掉、或被 WAF 判定可疑，續期就會失敗。這是我見過最常見的續期失敗原因。
4. 檢查是否撞到 CA 的頻率限制。續期腳本設錯（例如每小時跑一次全新簽發而不是續期）會很快撞到限制。Let’s Encrypt 有公開的頻率限制文件，包含每個註冊網域的簽發上限、重複憑證上限、以及驗證失敗次數上限，數值都寫得很明確（見 Let’s Encrypt：Rate Limits）。撞到限制之後只能等時間視窗過去，沒有加速的辦法，所以不要用「反覆重試」當排查手段。
5. 確認續期後有重新載入服務。憑證檔換了但 Nginx／Apache 沒 reload，對外提供的還是舊憑證。Certbot 的 deploy hook 就是為這件事存在的。
6. 加一個外部監控。用任何能檢查 TLS 到期日的監控服務設一個提前數週的告警。自動化的正確配套不是「相信它」，而是「監控它」。我自己就踩過續期排程失效、憑證過期整站掛紅字的坑，事後回看，缺的不是自動化而是告警。

憑證效期正在變短：為什麼自動化不再是選項

最後補一個很多舊教學還沒更新、但會直接影響你維運方式的變化。公開信任的 TLS 憑證效期上限正在分階段縮短。

CA/Browser Forum 在 2025 年 4 月通過的 Ballot SC081v3 建立了這個時程表，官方頁面的描述是「Eventual reduction of maximum validity period from 398 days to 47 days」，並說明這些縮減「are proposed to occur starting in March 2026 and concluding in March 2029」（見 CA/Browser Forum：Ballot SC081v3）。各階段的具體天數，憑證機構自己的公告寫得比較明確：2026 年 3 月 15 日起上限降為 200 天，2027 年 3 月 15 日起 100 天，2029 年 3 月 15 日起 47 天（見 DigiCert：TLS certificate lifetimes will officially reduce to 47 days）。實際生效日各家 CA 可能提前幾天作為安全邊際，以你的發行商公告為準。

這件事對自架站的人有三個實際影響：

• 「買一年憑證省得麻煩」這個策略已經走到盡頭。未來即使付費，你也一樣要頻繁更換憑證，付費不再換得到「一年不用管」。
• 免費與付費在「續期麻煩程度」上的差距被抹平了。Let’s Encrypt 從一開始就是為自動化設計的（這也是它把效期設在 90 天、還提供 6 天選項的原因）；而傳統上依賴人工重新簽發部署的付費流程，反而要被迫改成自動化。
• 你唯一該投資的是「續期會不會自動成功」加上「失敗時我會不會知道」。不是憑證品牌，不是保固金額。

如果你是把網站當作接案門面在經營，這條維運線的穩定度其實跟作品集本身一樣重要——客戶點進來看到紅底警告的代價，比你想像的高。這方面的取捨在 接案作品集網站怎麼做？沒有大案子也能談到客戶的 Portfolio 實作裡也有相關討論。

💡 延伸閱讀｜準備好動手架站了嗎？先挑對主機商，能省下日後搬家的大麻煩：WordPress 虛擬主機推薦 2026：新手架站 5 大主機商比較與選擇指南。

常見問題

免費的 Let’s Encrypt 憑證安全性比付費憑證差嗎？

不會差。兩者用的是同一套 TLS 協定與同等的加密強度，瀏覽器對它們的信任處理也一樣。差別在三處：驗證層級（Let’s Encrypt 只簽 DV，不做組織驗證）、合約保固（免費憑證沒有保固條款）、以及技術支援方式（社群文件而非付費客服）。對個人站、內容站與多數小型商業站，DV 憑證在安全性上完全足夠。真正決定你會不會被入侵的是密碼強度、外掛更新與後台存取控制，不是憑證的價格。

Let’s Encrypt 憑證 90 天就到期，我要每 90 天手動處理一次嗎？

不需要，正常情況下完全自動。Let’s Encrypt 官方建議在 90 天效期中每 60 天就續期一次，留出失敗重試的緩衝；cPanel 的 AutoSSL 會在每晚的系統更新流程中自動執行，VPS 上的 Certbot 多數安裝方式也內建自動續期。你要做的是驗證自動化真的有效：用 certbot renew --dry-run 測試流程、確認 /.well-known/acme-challenge/ 路徑沒有被重寫規則或防火牆擋掉、並設一個外部到期監控。憑證過期幾乎都是排程早就失效但沒人發現，不是忘記手動續。

我的網站是 HTTPS 但鎖頭旁邊有提示，或某些圖片載不出來，是什麼問題？

幾乎都是混合內容。現代瀏覽器會把 <img>、<video>、<audio> 以 src 指定的 http 請求自動升級成 https（但網址主機是 IP 位址時直接封鎖），而 <script>、樣式表、<iframe>、網頁字型、fetch 請求，以及用 srcset 或 <picture> 載入的圖片則會被直接封鎖。所以症狀通常不是鎖頭消失，而是圖片空白（升級後的網址不存在，且沒有退回 http 的備援）或功能壞掉（腳本被擋）。排查方式是按 F12 看 Console 警告與 Network 面板被封鎖的請求，把來源改成 https。舊文章裡貼的外部圖片、第三方嵌入碼、頁面編輯器裡填的外部網址是最常見的三個來源。

EV 憑證能讓網址列顯示我的公司名稱嗎？值得為此付費嗎？

不能了，這個理由已經不成立。Chromium 官方文件記載 Chrome 從第 77 版起就把 EV 的公司名稱從網址列移到點鎖頭後才會看到的「網站資訊」面板，其他主流瀏覽器也走了相同方向。一般訪客看到的畫面，DV 憑證和 EV 憑證完全一樣。現在還會需要 OV／EV 的情境，通常是產業合規要求、企業採購的資安檢核表、或需要在憑證中呈現法人身分供第三方系統驗證。如果你的動機純粹是「讓訪客更信任」，這筆錢買不到你想要的東西。

該不該開 HSTS？開了有什麼風險？

值得開，但要按順序開。HSTS 能關掉「第一次輸入網址時仍走 http」這個縫隙，防的是連線被降級成明文的攻擊；它不防釣魚、不防後台被入侵。風險在於它是單向門：MDN 官方文件明確指出，部署後在 max-age 到期前你無法退回 http，關閉必須改成 max-age=0 且同樣要透過安全連線送出；而且網域一旦成為 HSTS host，使用者無法點過去繞過憑證錯誤，憑證一過期就是整站進不去。Google 的 HSTS 預載服務（hstspreload.org）給的部署建議是分階段拉長 max-age——先 5 分鐘、再一週、再一個月，每階段修掉問題並等滿該階段的 max-age 才進下一階段。includeSubDomains 要等所有子網域都有憑證再加；preload 則幾乎不可逆（官方明言列入後無法輕易撤銷，變更要幾個月才隨瀏覽器更新抵達使用者），不急著申請。

延伸閱讀｜WordPress 自架站系列

• 自架站新手的六個決策：網域、主機、佈景主題與上線後維護該怎麼取捨
• 網站架設費用全解析 2026：自架、找接案、套版平台三種方案的價格與取捨
• WordPress 佈景主題推薦 2026：免費與付費主題怎麼選（含速度考量）
• Google Search Console 新手完整教學：從驗證網站到找出可優化關鍵字
• 在咖啡廳與共享空間工作：選點、設備、公共 Wi-Fi 資安與禮儀全指南