chundev
日期：2026-06-08 領域：PKI / Certificate Lifecycle Management
CA/Browser Forum 已通過 Ballot SC-081v3，TLS 憑證最長效期將在 2029 年縮到 47 天。手動管理完全不可行，必須全自動。自動化分兩階段：簽發（ACME 協定） 和 部署（Orchestration）。部署最難的不是技術，是盤點——你不知道有幾百張 cert 散在哪裡。
| 時間點 | 最長效期 | 推動者 |
|---|---|---|
| 2020 | 398 天 | Apple 單方面要求 |
| 2025/04 | Ballot SC-081v3 通過 | CA/B Forum（29 票贊成、0 反對） |
| 2026/03/15 | 200 天 | 第一階段生效 |
| 2027/03/15 | 100 天 | 第二階段 |
| 2029/03/15 | 47 天 | 最終目標 |
為什麼要這樣做？
短效憑證的安全邏輯是：讓被洩漏的私鑰「自然過期」就能失效，減少對 CRL（Certificate Revocation List）和 OCSP 的依賴。現實中 OCSP 有 soft-fail 問題——瀏覽器查不到撤銷狀態時預設放行——等於撤銷機制形同虛設。短效期直接繞過這個問題。
ACME（Automatic Certificate Management Environment）是 Let’s Encrypt 推廣的自動簽發協定，現在幾乎所有主流 CA 都支援。
核心流程：
Client CA (ACME Server)
|── POST /newOrder ───────────→| 建立訂單（含域名列表）
|←── 200 + challenges ─────────| 回傳驗證挑戰
| |
|── [完成 challenge] ──────────→| 證明域名控制權
|←── challenge valid ──────────|
| |
|── POST /finalize (CSR) ─────→| 送出簽署請求
|←── 200 + certificate URL ────| 取得憑證
| 類型 | 驗證方式 | 適用場景 | 限制 |
|---|---|---|---|
| HTTP-01 | 在 /.well-known/acme-challenge/{token} 回應指定內容 |
有公網 80 port 的 web server | 不支援 wildcard |
| DNS-01 | 新增 _acme-challenge.{domain} TXT record |
任何場景，含 wildcard | 需要 DNS API 權限 |
| TLS-ALPN-01 | 用特殊 ALPN 協商回應 | 只開 443 的場景 | 不支援 wildcard |
DNS-01 是最彈性的——不需要 incoming HTTP、支援 wildcard、後端可以在任何網路位置。代價是需要 DNS provider 的 API 存取權（Cloudflare API key、Route53 credentials 等）。
公網用 ACME，企業內部 CA 則有其他選擇：
| 協定 | 年代 | 常見場景 |
|---|---|---|
| SCEP（Simple Certificate Enrollment Protocol） | 較舊 | Microsoft ADCS、Apple MDM |
| EST（Enrollment over Secure Transport） | 較新 | 現代企業內部 CA |
| CMP（Certificate Management Protocol） | 彈性高 | 電信/金融級 PKI |
| Vault PKI Engine | 2015+ | Cloud-native，超短效憑證（TTL 數小時） |
這是最難的部分。「用到憑證的地方」極度分散：Web server、Load Balancer、CDN、API Gateway、Mail server、VPN、IoT 設備……每種的更新方式都不一樣。
[CLM 中控] ──指令──→ [Agent on host]
│
1. 向 CA 申請新 cert
2. 寫入指定路徑
3. 執行 post-hook
4. 回報成功/失敗
Post-hook 本質就是一行 reload 指令，依服務而異：
# nginx
systemctl reload nginx
# Docker container
docker exec proxy nginx -s reload
# Java app (更新 keystore)
keytool -importcert -keystore app.jks ... && systemctl restart app
# HAProxy
cat cert.pem key.pem > /etc/haproxy/certs/combined.pem
systemctl reload haproxy
代表工具： Venafi Agent、Keyfactor Orchestrator、certbot
現代基礎設施通常提供 API，不需要碰檔案系統：
| 目標 | 做法 |
|---|---|
| AWS ALB / CloudFront | ACM 完全自動，zero touch |
| Cloudflare | API 上傳或用 Origin CA |
| F5 BIG-IP | iControl REST API |
| Azure App Gateway | Key Vault 整合 |
| Kubernetes | cert-manager 寫 Secret |
代表工具： DigiCert Trust Lifecycle Manager、AppViewX CERT+
把 TLS 終止點收攏，後端全走明文：
Internet ──TLS──→ Reverse Proxy ──HTTP──→ Backend Services
(唯一管 cert 的地方) (不碰 cert)
代表工具： Caddy（內建 ACME，零設定自動 cert）、Traefik、K8s Ingress + cert-manager
| 工具 | 定位 | 簽發能力 | 部署方式 | 強項 |
|---|---|---|---|---|
| Venafi TLS Protect | Enterprise CLM 龍頭 | 多 CA 整合 | Agent + API | Discovery 最完整，connector 最多 |
| DigiCert Trust Lifecycle Manager | CA + CLM 一條龍 | 自家 CA + ACME | Agentless discovery + push | 併購 Symantec 後的生態整合 |
| Sectigo Certificate Manager | 中價位 CLM | 自家 CA + ACME + 第三方 | Agent + integrations | 2026 G2 Leader，CP 值較高 |
| Keyfactor Command | PKI + CLM | ADCS 整合強 | Agent (Orchestrator) | 微軟生態、內部 CA |
| AppViewX CERT+ | 多 CA 編排 | 整合 30+ CA | Workflow engine | F5/Citrix/NetScaler 整合 |
| GlobalSign Atlas | CA + 自動化 | ACME + API | Pull model | ACME 不額外收費 |
| HashiCorp Vault PKI | Cloud-native | 自建 CA | App 自己拉 | 短效憑證哲學，leak 也無所謂 |
| cert-manager (OSS) | K8s 專用 | ACME/Vault/Venafi issuer | 自動寫 K8s Secret | 免費，K8s 標配 |
所有商業工具的 killer feature 不是「自動 renew」（certbot 免費就能做），而是 Discovery——掃描全網找出「你不知道的憑證」：
企業最常見的 outage 原因不是「renew 失敗」，而是「根本不知道有這張 cert 存在，過期了才發現」。
| 模式 | Proxy → Backend | 安全等級 | 效能成本 |
|---|---|---|---|
| TLS Offload | 明文 HTTP | 依賴網路隔離 | 最低 |
| TLS Re-encryption | 建立新 TLS 連線 | 傳輸層加密 | 中（多一次 handshake） |
| TLS Passthrough | Proxy 不解密，直通 | E2E encryption | Proxy 無法做 L7 |
核心問題：誰能碰到那段內部網路？
| 網路範圍 | 攻擊者需要 | 業界做法 |
|---|---|---|
| 同一台主機（localhost / Unix socket） | 已有 root | 加密無額外防禦，明文 OK |
| Docker bridge / K8s Pod network | 已進入 container 或 node | 多數接受明文 |
| 同一 VLAN（private network） | ARP spoofing | 多數接受，合規稽核可能要求加密 |
| 跨機房 / 跨雲 / 任何公網路徑 | 路徑上竊聽 | 絕對不行，必須加密 |
Service Mesh（Istio / Linkerd）：
Pod A Pod B
[App]─HTTP→[Envoy Sidecar]══mTLS══→[Envoy Sidecar]─HTTP→[App]
自動 rotate cert 自動 rotate cert
(SPIFFE identity) (SPIFFE identity)
CNI 層加密（Cilium WireGuard / Calico）：
集中解密不只是「方便管 cert」，更重要的是 Proxy 看得到內容才能做 L7 路由：
| 能力 | TLS Offload | TLS Passthrough |
|---|---|---|
Path-based routing（/api vs /web） |
✅ | ❌ |
| WAF 規則 | ✅ | ❌ |
| Per-URL rate limiting | ✅ | ❌ |
| Header 改寫 / 注入 | ✅ | ❌ |
| Response 壓縮 / 快取 | ✅ | ❌ |
| Access log 含完整 URL | ✅ | ❌ |
| gRPC / WebSocket routing | ✅ | ❌ |
Trade-off 很明確：要 L7 智慧就必須在某處解密。
| 標準 | 內部網路加密要求 |
|---|---|
| PCI-DSS v4 | 跨公網強制；內網「強烈建議」 |
| ISO 27001 | 依風險評估決定 |
| NIST 800-53 SC-8 | 依資料分類保護 |
| 台灣資通安全法 | A 級機關通常要求全程加密 |
合格的稽核回答：「該網段為隔離 container network，存取需先突破邊界防護，風險評估為可接受，記錄於 SoA。」
你的環境是什麼？
│
├─ K8s cluster
│ └─ cert-manager + Let's Encrypt (ACME DNS-01)
│ 公網 cert 全自動；內部 mTLS 考慮 Istio/Linkerd
│
├─ 純 Docker / VM（< 20 台）
│ └─ Traefik 或 Caddy 當 reverse proxy（內建 ACME）
│ cert 管理集中在一個點
│
├─ 企業混合環境（Windows + Linux + 網路設備 + Cloud）
│ └─ 商業 CLM（Venafi / DigiCert / Sectigo）
│ 先做 Discovery 盤點，再逐步自動化
│
└─ 雲原生（全在 AWS/GCP/Azure）
└─ Cloud-native cert 服務（ACM / GCP Certificate Manager）
完全託管，zero touch