2.4 HTTPS 與邊緣憑證：從 ACME 到 Cloudflare 的一鍵加密#

本節目標#

• 理解 TLS 憑證的信任鏈：CA、中繼憑證、leaf 憑證如何層層簽署
• 掌握 Let's Encrypt 與 ACME 協議的「證明網域控制權」流程
• 學會 Cloudflare 的 Universal SSL 與 Edge Certificates 面板操作
• 分辨 SSL/TLS 加密模式的差異：Flexible / Full / Full (Strict)，並啟用 TLS 1.3

歷史：瀏覽器鎖圖標背後的信任體系#

1994 年 Netscape 推出 SSL 2.0，讓 HTTP 走上加密通道；1999 年標準化為 TLS（RFC 2246 之後），今天的主流是 TLS 1.3（RFC 8446，2018）。但加密本身不夠——MITM 也能跟你加密，問題在於你如何相信對方就是銀行？

答案是憑證信任鏈：TLS 交握不只交換對稱金鑰，還附上一份 leaf 憑證的「出生證明」：

  作業系統 / 瀏覽器內建的 Root CA（自我簽署, 約 100+ 家）
        │  簽署
        ▼
  Intermediate CA（中繼憑證, CA 廠商日常營運用）
        │  簽署
        ▼
  Leaf 憑證 (CN: www.example.com)  ←你的網站交給瀏覽器的這張

信任鏈的數學基礎：Root CA 的公鑰寫死在你的 OS 中， Intermediate 的憑證由 Root 簽章（密碼學上不可偽造），Leaf 的憑證又由 Intermediate 簽章。瀏覽器只要往上驗章到 Root 即完成信任驗證。

Let's Encrypt 與 ACME：讓憑證取得自動化#

2015 年前，申請一張 DV 憑證是「網頁表單 + email 驗證 + 人工作業」，一年一次，花錢又易忘記續期。EFF 與 Mozilla 推動的 Let's Encrypt 在 2015 年上線，發明了 ACME（Automatic Certificate Management Environment, RFC 8555）：憑證的全生命週期由軟體自動完成。

ACME 流程（以申請 example.com 的憑證為例）：

步驟 A: 客戶端向 CA 註冊帳戶（一分鐘）
步驟 B: 客戶端請求發證 → CA 指定要用哪種 challenge
步驟 C: 完成 challenge ，證明你控制該網域
   HTTP-01   : 在 http://example.com/.well-known/acme-challenge/ 放一個 CA 給定的 token 檔
   DNS-01    : 在 TXT _acme-challenge.example.com 放一個 CA 給定的 token
   (萬用字元 *.example.com 只能用 DNS-01)
步驟 D: CA 驗證通過 → 下發憑證
步驟 E: 客戶端設定定時器，到期前自動重來（90 天週期）

兩個關鍵設計：

1. 90 天有效期是刻意為之：讓「更新」變成常態工作，忘記修正的世界 = 憑證 3 天後到期，比一年一更窄得多。
2. DNS-01 是唯一能覆蓋萬用字元 *.example.com 的方式——這正是 Cloudflare 的 DNS API 可以接管的角色（ACME client 如 certbot、acme.sh 都有 dns_cf 模組）。

手動發一張 Let's Encrypt 憑證#

# DNS-01 challenge，需要先設定 Cloudflare API token（credentials 檔）
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d example.com -d "*.example.com" \
  --cert-name example --agree-tos -m you@example.com
# 產出: /etc/letsencrypt/live/example/fullchain.pem + privkey.pem

Cloudflare 模式：把 TLS 拆成兩段#

Cloudflare 的架構把 TLS 分成兩條腿：

   使用者(browser)
        │  TLS ①  Edge Certificate（Cloudflare 代管，免費自動）
        ▼
   Cloudflare 邊緣 ←─橘雲代理─
        │  TLS ②  Origin Certificate（你自己選：模式與憑證）
        ▼
   源站 (origin)

1. Edge Certificates：Universal SSL，連按鈕都不用按#

只要網域在 Cloudflare 帳號啟用、並有橘雲記錄，Cloudflare 自動為你簽發免費的 Universal SSL：

在 Dashboard 的 SSL/TLS → Edge Certificates，可再:

• 開啟 Always Use HTTPS（HTTP 301 到 HTTPS）
• 設定 Minimum TLS Version（建議 1.2 起）
• 開啟 TLS 1.3（0-RTT 加速、移除 RC4 等舊加密套件）
• 開啟 HSTS（強制瀏覽器這一年只剩 HTTPS）

2. OriginCertificates：Cloudflare 也會幫你簽一張源站用憑證#

SSL/TLS → Origin Server → Create Certificate，可免費生成一張 15 年有效、由 Cloudflare 的 Origin CA 簽章的憑證，裝到源站伺服器。若你完全在 Cloudflare 生態（本書走 Workers/Pages，多半無源站），這一步可以跳過；但自架源站（第 9 章）或混合環境會用上它。

Flexible / Full / Full (Strict)：三種模式的正確心智模型#

Flexible :
  user ──TLS──→ Cloudflare ──HTTP 明文──→ origin      (!)
Full     :
  user ──TLS──→ Cloudflare ──TLS(不驗章)──→ origin    (!)
Full(S)  :
  user ──TLS──→ Cloudflare ──TLS(驗章)───→ origin     (OK)

「Full 名字聽起來安全，實際上只是『自簽也接受』」——這是 Cloudflare 面板最容易配錯的安全設定。若源站有 Let's Encrypt 或 Origin CA 憑證，永遠選 Full (Strict)。無源站（純 Pages/Workers）的平台托管的情況，模式沒有進一步的作用；混自架源站就要你的決策。

組態上另一個坑：憑證的子網域覆蓋#

若你有 www之外的内容需要多層子網域（例：api.v2.example.com），Universal SSL 不覆蓋——要嘛購買 Advanced Certificate Manager，要嘛退回「每個子網域都恰好一層」的架構（這正是 2.2 節 子網域規劃建議的暗中好處）。

TLS 1.3 進一步：0-RTT 與為何值得開#

Cloudflare 預設吸收大部分此類考慮，你只需要在 Edge Certificates 開啟即可。最佳實務提醒：0-RTT 有重放風險，Cloudflare 已在邊緣處理，但對寫入型 API（付款等）仍應在應用層判斷。

小結與練習#

TLS 憑證的信任鏈由 Root → Intermediate → Leaf 的簽章鏈構成；ACME 把「證明你控制該網域→自動簽發→自動續約」的循環工程化，90 天有效期是設計而非缺陷。Cloudflare 把 TLS 切成兩段：Edge 憑證完全免費自動、源站段由你選 Flexible / Full / Full (Strict)——終極安全是 Full (Strict) + 15 年 Origin CA 憑證（或純雲端無源站）。TLS 1.3 打開 1-RTT/0-RTT 握手，一鍵啟用。

練習：

1. 用 curl -v https://example.com 觀察握手，找出 Leaf 憑證的 Chain 順序，解釋為何需要送 Intermediate 而不用送 Root。
2. 你的源站是自簽憑證的 Apache，應該選 Full 還是 Full (Strict)？若不能產生有效憑證，兩種模式各自的攻擊面是什麼？
3. 用 openssl s_client -connect example.com:443 -tls1_3 與 -tls1_2 各一次，比較 ServerHello 尺寸的差異，解釋為什麼 TLS 1.3 帶來「更快的第一次行為」。
4. 為什麼 Universal SSL 不覆蓋 api.v2.example.com？兩種解法（基礎架構面與花費面）各是什麼？