基本概念

CA（如 Let's Encrypt）
  ↓ 用 ACME 協議申請
憑證
  ↓ 放在 Server 上
TLS（用憑證做握手 + 加密）
  ↓
瀏覽器看到鎖頭

• 憑證 = 證明「我是這個網站」的文件
• TLS = 驗證身分並加密通訊的協議
• CA = 簽發憑證的機構
• ACME = 向 CA 申請憑證的流程
• OpenSSL = 產生金鑰和憑證的工具

名詞解釋

關係圖

CA（如 Let's Encrypt）
  ↕ 透過 ACME 協議溝通
ACME 客戶端（如 certbot / acme.sh）
  ← 需要 OpenSSL 產生金鑰和 CSR

最終產物：TLS 憑證
  → 放在 Server 上
  → 用於 TLS 握手
  → 瀏覽器驗證

角色關係

┌─────────────┐
│  使用者瀏覽器  │  內建信任 CA 清單
└──────┬──────┘
       │ TLS 連線
       ↓
┌─────────────┐
│  網站伺服器   │  放著 CA 簽發的憑證
└─────────────┘
       ↑
       │ 用 ACME 協議申請
       │
┌─────────────┐
│  CA（如      │  簽發憑證
│  Let's Encrypt）│
└─────────────┘

誰做什麼

TLS 握手流程

1. Client → Server：ClientHello（我要連線，支援這些加密演算法，並附上一把臨時公鑰）
2. Server → Client：ServerHello + 憑證（裡面有公鑰）+ 自己的臨時公鑰
3. Client 檢查憑證：
   - 誰簽發的？ → CA（如 Let's Encrypt）→ 信任清單有 → ✓
   - 網域對嗎？ → myblog.com = myblog.com → ✓
   - 過期了嗎？ → 還沒 → ✓
4. Client 用憑證裡的公鑰，驗證 Server 對這次交握的簽章確實是該私鑰簽的（證明身分）
5. 雙方各自用自己的臨時私鑰 + 對方的臨時公鑰，各自算出同一把共同金鑰（(EC)DHE 金鑰交換）
6. 雙方用這把共同金鑰加密所有後續通訊

憑證在 TLS 中的角色

憑證種類

瀏覽器行為

常見 CA 一覽

Let's Encrypt 只是眾多被瀏覽器信任的 CA 之一。Chrome、Firefox、Edge 和 Safari 各自維護自己的信任清單。清單收錄的根憑證數量約為 100 至 200 個。對應的憑證機構約數十家。確切數字會隨瀏覽器版本，以及憑證下架或新增而變動。數字不是固定的。只要簽發者在瀏覽器的信任清單中，瀏覽器就信任這個簽發者簽出的憑證。

常見的 CA

免費 CA 比較

你能從其他 CA 申請嗎

能。只要該 CA 在瀏覽器信任清單裡，簽發的憑證瀏覽器都信任。用 ACME 申請其他免費 CA：

# === ZeroSSL（必須先在 zerossl.com 取得 EAB 金鑰）===
certbot certonly --server https://acme.zerossl.com/v2/DV90 \
  --eab-kid <你的ID> --eab-hmac-key <你的金鑰> \
  -d myblog.com

# === Google Trust Services（必須先在 Google Cloud 建立 EAB 金鑰）===
certbot certonly --server https://dv.acme-v02.api.pki.goog/directory \
  --eab-kid <你的ID> --eab-hmac-key <你的金鑰> \
  -d myblog.com

付費 CA 則是直接向 CA 購買，或透過代理商（如 SSLs.com、GoDaddy）購買；買完後一樣用 OpenSSL 產生 CSR 提交給 CA，CA 簽發後下載憑證安裝。

ACME 協議

ACME（Automatic Certificate Management Environment）是基於 HTTPS 的 JSON API（RFC 8555）。

流程

1. 建立帳號
   POST /acme/new-account
   → Let's Encrypt 回傳帳號 URL

2. 申請憑證
   POST /acme/new-order
   → Let's Encrypt 回傳挑戰（challenge）

3. 完成挑戰（證明你擁有該網域）
   - HTTP-01：在網站放一個特定檔案
   - DNS-01：在 DNS 加一條 TXT 記錄
   - TLS-ALPN-01：在伺服器的 TLS 回應中放入特定內容

4. 驗證通過，提交 CSR
   POST /acme/finalize
   → Let's Encrypt 簽發憑證

5. 下載憑證
   POST /acme/cert/...
   → 取得簽好的憑證

所有請求都使用 JSON 格式，並透過 HTTPS 傳輸。每個請求都用你的帳號私鑰簽名。

你通常不會自己寫 ACME 協議，而是用 ACME 客戶端工具自動完成：

OpenSSL 的角色

OpenSSL 是工具，不是 CA，不會自己執行 ACME 協議。

OpenSSL 可以做兩件事

指令範例

# === 自簽（瀏覽器不信任）===
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes

# === 向 CA 申請（瀏覽器信任）===

# 1. 產生私鑰
openssl genrsa -out key.pem 2048

# 2. 產生 CSR（Certificate Signing Request）
openssl req -new -key key.pem -out csr.pem

# 3. 用 ACME 客戶端把 CSR 提交給 Let's Encrypt 申請
certbot certonly --csr csr.pem

# 4. Let's Encrypt 簽發憑證
# → 取得簽好的憑證

同樣是 OpenSSL 產生的憑證

自己簽 → 沒人背書 → ✗ 瀏覽器警告
交給 CA 簽發 → CA 背書 → ✓ 瀏覽器信任

OpenSSL 是產生憑證的工具，不是背書的機構。

Server 端場景

場景 1 — 你架設了一個網站 myblog.com

你需要一張憑證，讓瀏覽器信任你的網站。

1. 用 OpenSSL 產生私鑰和 CSR
2. ACME 客戶端（certbot）用 ACME 協議向 Let's Encrypt 申請
3. Let's Encrypt 驗證你真的擁有 myblog.com
4. Let's Encrypt（CA）簽發一張憑證給你
5. 你把憑證安裝在伺服器上
6. 瀏覽器連線過來 → 看到憑證 → 確認 Let's Encrypt 在信任清單中 → ✓

場景 2 — 你的網站掛在 Cloudflare 後面

瀏覽器 → Cloudflare Edge → 你的伺服器 (Origin)
         ↑                    ↑
    Cloudflare 公開 CA       你用 Origin CA 憑證
    (Universal SSL)         (在 Dashboard 產生)
    (瀏覽器信任)            (只有 Cloudflare 信任)

• 前段（瀏覽器 ↔ Cloudflare Edge）：Cloudflare 自動處理，你不需要處理
• 後段（Cloudflare Edge ↔ 你的伺服器）：你使用 Origin CA 憑證

場景 3 — 你架設了內部服務，不對外公開

用 OpenSSL 產生一張自簽憑證即可。只有你自己使用這個服務。

場景 4 — Cloudflare Pages

瀏覽器 → Cloudflare Edge → Cloudflare Pages
  ↑                         ↑
  Cloudflare 公開 CA 憑證    Pages 內部（你不需要處理）
  (瀏覽器信任)

瀏覽器看到的是 Cloudflare 的公開 CA 憑證（Universal SSL），不是 Origin CA。你完全不需要處理憑證。

Server 端憑證選擇整理

User / Client 端場景

User 什麼時候會接觸到 ACME / Let's Encrypt / CA？

幾乎不會。這些都是 Server 端的事。

User 唯一會接觸到的情況

看到「不安全」警告時。

你連到一個網站
  → 瀏覽器顯示「不安全」
  → 代表對方使用自簽憑證，或憑證過期
  → 你自行決定是否繼續（通常建議不要繼續）

User 端要做的事

Cloudflare 相關

Cloudflare 的憑證架構

使用者瀏覽器  ←→  Cloudflare Edge（全球節點）  ←→  Origin（你的伺服器）
   ↑                    ↑                              ↑
 看到的憑證           憑證在這裡終止                    你的實際伺服器
 (公開 CA)          (Cloudflare 處理)            (放憑證的地方)

兩段加密

Cloudflare SSL/TLS 模式

Origin CA vs 公開 CA

Let's Encrypt 效期正在縮短（2026-2028 時程）

CA/Browser Forum 已通過縮短憑證效期的提案。Let's Encrypt 依此提案排定時程：

Cloudflare Tunnel 的憑證

不論使用哪種 Tunnel，瀏覽器 ↔ Cloudflare Edge 這段的憑證都由 Cloudflare 自動處理。你完全不需要自己申請或設定憑證。

Cloudflare Edge vs Windows Edge

兩者完全不同，只是名稱相同：

自簽憑證問題（科學上網場景）

自簽憑證在公開 WWW 上的流量

非常少，幾乎可以忽略。

自簽憑證在科學上網中的問題

例外：Cloudflare WARP

Cloudflare WARP（162.159.197.2 等）也使用自簽憑證。但是 WARP 和企業使用者共用入口，封鎖 WARP 會有附帶傷害。一般人自行簽發的憑證沒有這種保護。

常見組合整理

OpenSSL + Let's Encrypt

OpenSSL（產生金鑰 + CSR）
  → ACME 客戶端（certbot / acme.sh）
    → Let's Encrypt（CA 簽發）
      → 取得憑證 → 瀏覽器信任 ✓

OpenSSL 自簽

OpenSSL（產生金鑰 + 自己簽）
  → 沒有 CA 背書
    → 瀏覽器警告 ✗

OpenSSL CSR + CA + Let's Encrypt

# 1. OpenSSL 產生私鑰
openssl genrsa -out key.pem 2048

# 2. OpenSSL 產生 CSR
openssl req -new -key key.pem -out csr.pem

# 3. ACME 客戶端把 CSR 提交給 Let's Encrypt 申請
certbot certonly --csr csr.pem

# 4. Let's Encrypt（CA）簽發憑證
# → 取得簽好的憑證 → 瀏覽器信任 ✓

Cloudflare Origin CA

1. 在 Cloudflare Dashboard 產生 Origin CA 憑證
2. 安裝在你的伺服器上
3. 設定 SSL/TLS 模式為 Full (strict)
4. Cloudflare Edge 信任你的伺服器
5. 瀏覽器看到的是 Cloudflare 的公開 CA 憑證 → 信任 ✓

Cloudflare Tunnel

1. cloudflared 連到 Cloudflare Edge
2. 瀏覽器 ↔ Cloudflare Edge 的憑證由 Cloudflare 自動處理
3. 你不需要處理任何憑證
4. 瀏覽器信任 ✓

常見 Q&A

Q：CA 背書的是 ACME 還是 Let's Encrypt？

是 Let's Encrypt（CA）背書。ACME 只是申請的協議/流程，不背書。

Q：OpenSSL 很多人用，為什麼瀏覽器不信任？

OpenSSL 是工具，不是 CA。同樣是 OpenSSL 產生的憑證：自己簽發 → 沒人背書 → 警告；交給 CA 簽發 → CA 背書 → 不警告。

Q：掛在 Cloudflare 後面的危險網站，瀏覽器會警告嗎？

不會。瀏覽器看到的是 Cloudflare 的公開 CA 憑證，不是 Origin CA。憑證只證明連線加密，不證明內容安全。

Q：User 端需要準備憑證嗎？

不需要。憑證是 Server 端準備的。User 端的瀏覽器內建信任 CA 清單，自動驗證。

Q：ACME 是什麼？

自動申請/續簽憑證的協議（RFC 8555）。基於 HTTPS 的 JSON API。你通常用 ACME 客戶端（如 certbot）自動完成，不會自己寫協議。

Q：TLS 跟憑證有什麼關係？

TLS 是使用憑證的協議。憑證用來證明網站身分。TLS 是「檢查憑證並加密通訊」的流程。沒有憑證，TLS 無法驗證對方身分。

Q：Origin CA 和公開 CA 一樣嗎？

不一樣。Origin CA 只被 Cloudflare 信任，瀏覽器不信任。公開 CA（如 Let's Encrypt）被所有瀏覽器信任。Origin CA 只在 Cloudflare Edge ↔ 你的伺服器之間使用。

Q：Cloudflare Tunnel 需要設定憑證嗎？

不用。不管 Quick Tunnel 還是 Named Tunnel，瀏覽器 ↔ Cloudflare Edge 的憑證都是 Cloudflare 自動處理的。