GCP帳號認證充值 谷歌雲SSL證書自動續期設置：利用 Certbot 維護免費的 Let's Encrypt 證書
前言：為什麼要自動續期，且為什麼是 Certbot
在 Google Cloud 上部署網站或 API，SSL 證書是基本功。你可能曾遇過這種情況：證書到期提醒來得很突然，然後服務告警、用戶跳出、SEO 排名波動，最後才匆忙補救。若你用的是付費證書，成本與流程還算可控；但如果你選擇免費的 Let's Encrypt，續期就必須靠自動化來守住穩定性。
這裡的目標很明確：在谷歌雲上，使用 Certbot 來維護 Let's Encrypt 證書，並建立可靠的自動續期機制。你不需要每 60～90 天手動操作，只要把「驗證方式、證書路徑、續期腳本與排程」一次設好，後續便能平穩運行。
不過要先講清楚一件事：Let’s Encrypt 要續期，必須能再次完成域名驗證。谷歌雲的架構可能是 Compute Engine + Nginx、或是外掛式負載平衡（HTTP(S) Load Balancing）、甚至在前面還有 Cloud CDN / Cloud Armor。不同架構意味著驗證方式也不同。因此，下文會用「適用範圍與選擇策略」的方式講清楚，避免你照抄命令卻因環境不符而失敗。
第一章：準備工作與環境假設
你需要先確認的前提
在開始設定之前，請先把以下資訊準備好：
- 一個你已經擁有的域名（例：example.com 與 www.example.com）
- 該域名目前的 DNS 已指向 Google Cloud 上能接收流量的目標（例如 VM 外網 IP、或負載平衡 IP/域名）
- 你要申請與部署證書的主機環境：常見是 Compute Engine 的 Nginx（或其他 Web 服務）
- 你能在 VM 上執行命令（通常是 SSH 權限）
另外，Let's Encrypt 的證書是針對「域名」發放的，而不是針對「你有哪個雲服務」發放的。換句話說，只要域名驗證能通過，你就能拿到免費證書。
選擇驗證方式：HTTP-01 與 DNS-01
Certbot 通常會用兩種主要方式驗證域名所有權：
- GCP帳號認證充值 HTTP-01：Let's Encrypt 會嘗試訪問你網域的某個 HTTP 路徑（例如
http://example.com/.well-known/acme-challenge/...）。如果你的網站能對外提供該路徑，通常最簡單。 - DNS-01：讓你在 DNS 中建立一條特定 TXT 記錄。這種方式對「HTTP 被負載平衡、反向代理或權限限制」的環境特別有用，也更適合只用 443、或很難直接暴露 80 的情況。
如果你已經確定 80 端口能對外（或你能放行），建議先走 HTTP-01；如果你的架構不方便提供 HTTP 驗證，再考慮 DNS-01。
第二章：在 Compute Engine 上安裝與初次簽發證書
更新系統並安裝 Certbot
以下以 Ubuntu 為例（其他 Linux 也類似）。進入你的 VM 後：
sudo apt update
sudo apt install -y certbot
若你使用的是 Nginx，通常還會用到 Nginx 外掛，以便自動修改站點配置。你可以再安裝：
sudo apt install -y python3-certbot-nginx
初次申請：HTTP-01（最常見、也最容易）
假設你的域名 example.com 和 www.example.com 都會指向這台 VM，並且你已經把 Nginx 配好了相應 server_name。確保以下兩點：
- GCP帳號認證充值 防火牆允許外部訪問 VM 的 80/443（至少 80 用於初次驗證）
- Nginx 能正常回應 HTTP 請求
然後用 Certbot 申請：
sudo certbot --nginx -d example.com -d www.example.com
Certbot 會引導你選擇條款、並嘗試自動完成驗證。若一切順利，它會把證書安裝到對應位置，並把 Nginx 重新載入。
GCP帳號認證充值 第一次失敗時，先查什麼
很多人第一次就卡住，是因為「驗證路徑不可達」或「域名指向不對」。你可以按優先順序排查：
- 從你自己的網路（或用手機熱點）打開：
http://example.com是否能顯示 Nginx 內容 - 確認 DNS A/AAAA 記錄是否確實指向這台 VM（或指向負載平衡後再轉發到 VM）
- 確認安全群組（Google Cloud firewall）放行了 80/443
- 檢查 Nginx server_name 是否正確，避免請求落到其他 server block
- 若你做了強制跳轉 HTTPS，仍可能可行，但要確保
.well-known/acme-challenge能被正確處理（一般 Certbot 會替你處理，但前提是 Nginx 設定允許）
你不需要一次看一大堆 logs，把問題縮小到「外網能否訪問挑戰路徑」就會快很多。
第三章：部署證書到 Nginx 與確保自動重新載入
證書通常放在哪裡
Let’s Encrypt 的證書通常在：
/etc/letsencrypt/live/example.com/
你會看到幾個關鍵檔案，例如：
fullchain.pem：完整證書鏈privkey.pem：私鑰- GCP帳號認證充值
chain.pem：中繼證書（視情況使用）
Certbot 用 live 目錄的「符號連結」指向實際版本，因此續期時通常不需要你手動改 Nginx 配置。真正要做的是：續期後要觸發 Nginx reload，確保新證書生效。
為 Nginx 準備正確的 SSL 設定（示意）
你的 Nginx site 配置中，一般會包含類似內容（示意，請按你的檔名/域名替換）：
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
同時確保 server block 的 listen 443 ssl 正確，且 server_name 包含你的網域。
關鍵：讓續期自動觸發 reload
如果你是用 certbot --nginx 方式安裝，Certbot 通常已經把必要的 hook 設好；但在一些特殊情況，你可能需要確認是否存在自動 reload。
你可以手動測試「不真正更新」但檢查續期流程是否可行：
sudo certbot renew --dry-run
若 dry-run 通利，表示你的續期驗證方式與 Nginx 配置大體符合預期。你還可以檢查 renew 設定檔，以確認它知道該使用哪些參數。
第四章：建立自動續期排程（systemd timer 或 cron）
GCP帳號認證充值 你可能已經有 systemd timer
在現代的 Ubuntu/Debian 上，Certbot 常會預設安裝成 systemd timer 或類似機制。你可以檢查：
systemctl list-timers | grep certbot
若你看到 certbot renew 的 timer，通常表示系統會定期嘗試續期，並在需要時更新證書。
GCP帳號認證充值 如果沒有，手動建立排程（建議做法）
建議你使用 systemd timer，因為比 cron 更清楚、也更容易觀察狀態。概念上需要兩個檔案：
- timer：定時啟動服務
- service：呼叫 certbot renew
以下給出一個常見做法（你可依系統調整路徑與檔名）。
1）建立 service 檔案：
sudo nano /etc/systemd/system/certbot-renew.service
內容大致為：
[Unit]
Description=Certbot renew
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet
2）建立 timer 檔案：
sudo nano /etc/systemd/system/certbot-renew.timer
內容大致為：
[Unit]
Description=Run certbot renew daily
[Timer]
OnCalendar=daily
RandomizedDelaySec=3600
Persistent=true
[Install]
WantedBy=timers.target
3）啟用並立即啟動：
sudo systemctl daemon-reload
sudo systemctl enable --now certbot-renew.timer
接著檢查狀態：
systemctl status certbot-renew.timer
你也可以看最近一次執行結果：
journalctl -u certbot-renew.service --since 'today'
續期頻率設多少比較合理
Let's Encrypt 的證書有效期約 90 天。Certbot 續期策略通常會在「剩餘天數低於門檻」時才真正更新，因此你可以把排程設得更頻繁也不會造成額外壓力。每日檢查是一個常見且穩妥的頻率。
重點不在「每天跑」，而在「每天能跑」且「遇到失敗你能看見」。因此除了自動化，監控與 log 也要跟上。
第五章：遇到谷歌雲架構特殊情境的解法
GCP帳號認證充值 你用的是 Google Cloud HTTP(S) Load Balancing，但 VM 沒直接接 80
若你的網站流量先經由負載平衡，再轉發到後端服務，而後端（VM）可能不對外開 80，那 HTTP-01 會變得不穩定。這時你有兩種方向：
- 讓 Let's Encrypt 的驗證請求能到達後端服務的 challenge 路徑（需要你能控制路徑或開放 80）
- 改用 DNS-01 驗證：不依賴 HTTP 通路是否可達
實務上 DNS-01 往往更省事，尤其你已把入口鎖得很嚴，或你只想保證 443。
使用 DNS-01：讓續期不再受網路拓撲影響
DNS-01 的核心是：Certbot 會要求你在指定 DNS 提供商中建立 TXT 記錄。當記錄更新生效後，Let's Encrypt 完成驗證，發放新證書。
如果你使用 Google Domains / Cloud DNS 作為 DNS 提供商，通常可以用對應外掛讓 Certbot 自動管理 DNS 記錄（避免你每次手動加 TXT）。
概念步驟如下：
- 取得並保存 Cloud DNS 的權限（通常是服務帳號的最小權限）
- 安裝 Certbot 的 DNS 外掛（對應 Cloud DNS）
- 執行 Certbot 申請命令，指定使用 DNS 驗證的參數
- 續期時同樣會自動更新 TXT 記錄，完成驗證與更新
注意：DNS-01 仍依賴「你的 DNS 在公開網路能正確顯示 TXT」。若你使用代理或有不合理的 TTL，可能導致驗證延遲。建議在首次部署時允許足夠等待時間，之後再觀察。
證書更新後仍然沒有生效：你可能忘了 reload 或用錯位置
續期成功不代表流量立刻使用新證書。最常見的原因：
- Nginx 沒有 reload（或 reload 失敗）
- GCP帳號認證充值 你在 Nginx 配置中寫了固定版本路徑，而不是 live 目錄（續期更新後路徑不同）
- 你其實沒有正確引用同一個憑證目錄（多域名、多站點時容易搞混）
你可以用以下方式檢查目前 Nginx 提供的證書有效期：
- 瀏覽器查看證書到期日
- 或用命令行工具查詢（例如開連線後看 notAfter）
若發現有效期沒更新，你就回頭檢查 reload hook 是否有執行，以及 Nginx 是否正確讀取了 live 目錄。
GCP帳號認證充值 第六章：把續期做成「可維護」的流程，而不是一次性成功
你應該保留哪些配置與紀錄
要維護，最重要的是可追溯。建議你至少保存：
- Certbot 的 renew 設定：
/etc/letsencrypt/renewal/內的各網域 .conf - Nginx site 配置檔（含 SSL 段）
- 續期 log（systemd journal 或 certbot log）
當下次續期失敗，你不會在完全沒有線索的狀況下重試，而是能快速找出差異點。
定期用 dry-run 做演練
你可以每隔一段時間做一次：
sudo certbot renew --dry-run
這不會真正簽發新證書，但會模擬驗證與更新流程，能提前暴露「網路拓撲改了」「DNS 改了」「防火牆規則變了」之類的問題。把演練納入變更週期（例如你調整了防火牆或更新了 Nginx）會非常有效。
為什麼不能只看「續期是否成功」
Certbot 計算到期時間後只會在必要時續期。若你很久沒觀察，有可能出現以下情況：
- 某次續期驗證因為域名指向變更而失敗
- 排程其實掛了，但你沒看到
- Nginx 設定變更後，reload hook 失效
因此你需要的不只是「成功更新一次」，而是「整套鏈路：排程 → 驗證 → 更新 → reload → 提供新證書」。只要其中一環斷掉，就會在臨界點爆雷。
第七章：整合實務示例（以 Nginx + Compute Engine 為主）
一個常見的完整流程回顧
假設你的環境是：域名指向同一台 Compute Engine VM；Nginx 提供網站服務；你已開放 80/443。完整流程通常是：
- 安裝 certbot 與 certbot-nginx
- 用
certbot --nginx -d example.com -d www.example.com首次簽發 - 確認 Nginx 正確引用
/etc/letsencrypt/live/...下的證書檔 - 確認自動續期排程存在（systemd timer 或 cron）
- 用
certbot renew --dry-run測試續期流程 - 確認續期更新後能 reload Nginx（可在 log 中看到相應行為）
如果你後續新增了子網域或替換站點，仍然沿用同樣邏輯：先保證驗證路徑可通，再確保 reload 與引用路徑正確。
當你有多個站點（多個 server block）
多站點情境很常見。你可能在一台 VM 上放了多個 domain。建議注意：
- 每個 server block 的
server_name必須準確 - 避免同一個網域被多個站點配置或重複引用
- 用 Certbot 時指定清楚的 -d 列表，不要只申請主域卻忘記 www（或相反）
若你維護的網域變多，可以建立一個簡單的文件記錄：每個網域的證書類型、驗證方式（HTTP-01 或 DNS-01）、以及對應的 Nginx 配置檔位置。這會讓後續排障快很多。
結語：把證書自動續期變成一種「日常可靠性」
SSL 證書不是一次性任務。Let’s Encrypt 的免費優勢讓你可以把成本降到幾乎為零，但代價是你必須把續期做成自動化、可觀察、可回溯。透過 Certbot，你能把流程標準化：申請、驗證、部署、續期與 reload 都能串起來。
在 Google Cloud 的世界裡，最容易出問題的是「域名驗證通路」與「架構差異」。因此你要做的不是盲目照抄命令，而是先選對驗證方式：能用 HTTP-01 就先用它；如果入口受限或拓撲複雜，DNS-01 往往更穩。
當你完成本文的設定後，接下來的重點就變成兩件事：定期用 dry-run 演練一次，以及確保系統有排程、log 可查。你不會再因為到期而被迫救火，SSL 也會成為默默工作的一部分。
