服務定位

Vault 的核心定位是 跨雲 + 跨環境 + 跨 secret 形態的單一 secret 控制面。當組織同時跑 AWS + GCP + on-prem K8s、又需要 dynamic database credential + 內部 PKI + envelope encryption、用三個 cloud-native service 拼起來會出現 secret 治理鏈不連續（AWS 的 secret 怎麼授權 GCP service 取用、on-prem app 怎麼拿短期 cloud credential、內部 CA 跟外部 ACM 怎麼分工）。Vault 把這層 統一抽象 — 應用端只跟 Vault 講話、Vault 後端接各雲 KMS / database / PKI。

跟 AWS Secrets Manager / Google Secret Manager 相比、Vault 多了：dynamic credential engine（cloud-native 對應產品有限）、transit engine 做 encryption-as-a-service、PKI engine 自簽內部憑證、跨雲統一介面。代價是 自管運維（HA cluster、auto-unseal、replication、upgrade）— 跟自管 Keycloak 的取捨同類。HCP Vault（HashiCorp Cloud Platform）是 HashiCorp 託管版、把運維交還、但綁 HashiCorp。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret 適合 Vault（dynamic credential、跨雲、PKI、encryption-as-a-service）、哪些直接用雲端 native service 即可
2. Vault deployment 的最低安全需求（auto-unseal、HA、audit device、policy、replication）
3. Vault 自己出事時的降級路徑（seal storm、root token 復原、audit log gap）
4. 何時用 Vault、何時走 Secrets Manager / Google Secret Manager / Azure Key Vault 的取捨

最短判讀路徑

判斷 Vault deployment 是否健康、最少看五件事：

• 誰能做什麼：root token 是否已 revoke、policy 是否走 path-based least privilege、admin 是否走 OIDC / AWS IAM auth 而不是 token、break-glass token 是否離線存
• Auth method 收緊：AppRole / Kubernetes / OIDC / JWT auth 哪些開、role 對應的 policy 是不是過寬、TTL 是否短、bound_* 條件是否鎖（namespace / audience / subject）
• Secret engine 設定：KV v2 開 versioning？dynamic engine（database / aws / pki）lease TTL 多久、max TTL 限制是什麼、revocation 是否驗證生效
• Seal / unseal 治理：是否走 auto-unseal（KMS-backed）、recovery key 持有者跟 Shamir threshold、replication 跟 DR cluster 是否同步
• 證據是否可回查：audit device（file / syslog / socket）是否多 channel、是否同步到 SIEM、replay 攻擊防護是否開（HMAC + nonce）

五件事任一缺失、就是 Audit Log 與 Secret Management 邊界的待補項目。

日常操作與決策形狀

Auth method 設計：AppRole 適合不在雲端 metadata 內的 workload（on-prem、CI runner）但 secret_id 本身要妥善保管；Kubernetes auth 適合 K8s 內 workload、用 ServiceAccount token + projected token；AWS IAM auth 適合 AWS 內 workload、走 STS 簽名驗證、不需要存 secret；OIDC / JWT 適合 human admin + CI（GitHub Actions / GitLab CI 走 OIDC token）。每個 auth method 對應 一組 role、role 綁 policy 跟 TTL。

Secret engine 分層：KV v2（static secret + version history）作為基線；dynamic database engine（PostgreSQL / MySQL / MongoDB）發短期 DB user、max_ttl = 1h 級別、過期 Vault 自動 revoke；AWS / Azure / GCP secret engine 對 cloud account 發短期 STS credential / service account key；PKI engine 自簽憑證、跟 cert-manager 整合做 K8s workload mTLS；transit engine 做 envelope encryption — app 把資料丟給 Vault 加密、key 不離 Vault。

Policy（path-based）：Vault policy 是 path + capabilities（create / read / update / delete / list / sudo）的 mapping。常見錯配：給 secret/* read 等於整個組織所有 secret 都看得到、應該用 secret/data/{team}/* 之類前綴限定；admin policy 不要給 sudo 太寬、policy 變更走 PR review + CI apply。

Rotation 跟 lease 治理：static secret（KV）的 rotation 是 app 自己做（拿新 secret 後手動 update）；dynamic secret 是 Vault 控制 lease 生命週期、app 只要在 TTL 內續租即可。對應 Failure: Credential Rotation Without Scope：static secret 的 rotation 必須有 scope map — 哪些 service 用了同一把 secret、哪個 service 支援零停機 rotation、誰是 last to be rotated。沒這份 map 就會發生「rotate 後某個被遺忘的 cron job 認證失敗、整個下游崩」。

Seal / unseal 設計：Vault 啟動時 sealed、必須 unseal 才能服務。Shamir secret sharing 是預設（5 key holders、3 threshold）— 任何重啟需要找齊 3 個人合 unseal、production 場景幾乎都該換 auto-unseal（用 AWS KMS / GCP KMS / Azure Key Vault 當 master key custodian）。代價是 把 master key 託給雲廠 — 不接受的組織保留 Shamir + 嚴格 key holder rotation。

Audit device 是 必開：Vault 預設不開 audit、要手動 enable（vault audit enable file path=/var/log/vault_audit.log）。沒 audit device 在 production = 事故時 連 token 被誰用過都查不到。建議多 channel（file + syslog + 推到外部 SIEM）— 單一 channel 失效（disk full、socket broken）Vault 會拒絕請求、影響 availability、所以多 channel 是必要冗餘。

Break-glass 與 root token：初始化時產生的 root token 應該 用完立刻 revoke、改用 admin policy + OIDC auth。break-glass scenario 用 recovery key 重新發 root token、recovery key 走 Shamir 多人持有 + 離線存。

核心取捨表

選 Vault 的核心訴求：跨雲 + dynamic credential + 內部 PKI + transit encryption 至少滿足兩項、且能投入 SRE 量能跑 HA cluster、有 SIEM 接 audit log、能接受 self-hosted 的 upgrade / cert / DB 運維成本。單純需要 AWS-only static secret rotation、直接用 Secrets Manager 更便宜更簡單。

進階主題

Dynamic credential 的 lease 生命週期治理：dynamic engine 發出的 credential 都帶 lease ID、Vault 在 TTL 到期時自動 revoke（database engine 真的會 DROP USER、cloud engine 真的會 DeleteAccessKey）。設計時要算清楚 app 連線池的 connection lifetime — DB connection 持續用同一組 credential、credential lease 過期但 connection 還在會出現 staled credential 問題。常見作法：lease TTL > connection idle timeout * 2、加 lease renewal mechanism（app 在 TTL 50% 時主動 renew）。

Transit engine（encryption-as-a-service）：app 不持 encryption key、把 plaintext 丟給 Vault encrypt API、拿 ciphertext 回來；解密時把 ciphertext 給 Vault decrypt API。Key 完全不離 Vault、所有 cryptographic operation 在 Vault 內、app 只需要 encrypt / decrypt capability。對應 Storm-0558 signing key chain 的對照啟示：key 不能 export 是減 blast radius 的關鍵設計 — transit 把這個原則內建。

PKI engine + cert-manager 整合：Vault PKI engine 可以當內部 root CA + intermediate CA、issue 短期 cert（hours-level）給 K8s workload；cert-manager 用 Vault PKI issuer 自動更新 cert。比起手動跑 OpenSSL CA、Vault PKI 的優勢是 cert lifecycle 進 Vault audit、跟 secret rotation 用同一套 evidence chain（呼應 credential rotation scoped evidence）。

Namespace（Enterprise）跟 multi-tenancy：Enterprise 版 namespace 是 tenant 邏輯隔離、每個 namespace 有自己的 auth method、policy、secret engine。OSS 版沒 namespace — 多團隊共用 Vault 要靠 path 命名規約 + policy prefix 拼隔離、邊界較鬆。大組織通常需要 namespace 才能避免單一 admin 跨 team 越界。

Replication（Enterprise）：Performance Replication（主從 + 多 region active）跟 DR Replication（純 standby）是兩個獨立功能。production HA 通常需要 同 region 的 cluster + 跨 region 的 DR replication、recovery key 跟 unseal 機制要跨 cluster 一致。

排錯與失敗快速判讀

• Audit device 沒開：production 啟動時忘了 enable audit、事故發生時無 forensic data — 啟動 checklist 必含「enable audit before serving traffic」、SRE runbook 用 health check 驗
• Policy 過寬：給整個 secret/* read、單一 token 等於拿到全公司 secret — 用 path prefix 限定到 {team}/{env}/*、policy review 走 PR
• Dynamic credential lease 太長 / 沒 max_ttl：DB user 跑了一週還沒收、攻擊者只要拿到一次就長期可用 — 設定 lease TTL = 1h、max_ttl = 24h
• Auto-unseal KMS access 沒監控：AWS KMS / GCP KMS 的 Vault auto-unseal key 沒 alert 異常使用 — KMS 端設 alert（GetKeyValue / Decrypt 突增）
• Replication lag 沒 alert：Performance / DR replication 落後幾分鐘到幾小時、failover 時拿到 stale state — Prometheus 監控 vault.replication.* metric
• Root token 未 revoke：初始化時的 root token 還在用、policy / audit / OIDC 全 bypass — 初始化 checklist 強制 revoke、CI 跑 vault token lookup 驗證 root 不可用
• Sealed 後 unseal key 找不到人：production cluster 緊急 restart、Shamir threshold 3 但有 1 個 key holder 在度假 — production 必須 auto-unseal、recovery key 走 break-glass 流程

何時改走其他服務

不在本頁內的主題

• Vault 完整 API reference 跟 CLI 詳盡用法
• 每個 secret engine 的內部實作細節（DB connection pool、cloud SDK 呼叫順序）
• Enterprise 各 license tier 的功能對照
• Terraform / Ansible 跟 Vault 整合的完整步驟
• 各 auth method 的 OIDC / SAML provider 設定教學

案例回寫

Vault 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.13 偵測覆蓋率與訊號治理
• 平行：AWS Secrets Manager、Google Secret Manager、Azure Key Vault
• 下游：AWS KMS / Google Cloud KMS（Vault auto-unseal master key custodian）
• 下游：cert-manager（用 Vault PKI engine 作為 K8s workload cert issuer）
• 跨模組：8 事故處理 vendor 清單（Vault 事件如何 routing 進 IR 流程）
• 官方：Vault Documentation

服務定位

cert-manager 的核心責任是 K8s cluster 內所有 cert 的生命週期治理。從 Ingress / Gateway 對外 TLS、internal service mTLS、到 workload-level 短期 cert、都用同一套 declarative model 表達。Issuer 抽象讓底層 cert 來源可換 — 公開 cert 走 Let’s Encrypt ACME、內部 cert 走 Vault PKI engine 或 self-signed CA、企業環境走 Venafi 或 AWS PCA — 上層 Certificate spec 不變。

跟 AWS ACM 的差異是 cert 的部署面：ACM 是 AWS-managed cert、只能掛在 AWS service（ELB / CloudFront / API Gateway）、私鑰永不離 AWS；cert-manager 是 K8s-native client、cert 放在 cluster 內的 Secret、可以掛任何 ingress controller 或 workload mTLS。跟 Let’s Encrypt 的關係是 client vs issuer — cert-manager 是 ACME client、Let’s Encrypt 是 ACME server、不是替代關係。跟 SPIRE 的差異是 身份模型 — cert-manager 給 DNS-named cert（CN / SAN 是 hostname）、SPIRE 給 SPIFFE ID-based workload identity（spiffe://trust-domain/workload）、兩者互補不衝突。

本章目標

讀完本頁、讀者能判斷：

1. cert-manager 用 Issuer / ClusterIssuer 哪個、配什麼 issuer backend（Let’s Encrypt / Vault PKI / self-signed / 公司 CA）
2. Challenge solver 選 HTTP01 還是 DNS01、為什麼 wildcard cert 必須用 DNF01
3. Auto-renewal 觸發點、renew 失敗的 alert 時機、跟 Ingress / Gateway API 整合的 annotation
4. 何時用 cert-manager、何時改走 ACM（雲端原生 service）或 SPIRE（workload identity）

最短判讀路徑

判斷 cert-manager 部署是否健康、最少看四件事：

• Issuer 配置：是 ClusterIssuer（cluster-wide）還是 Issuer（namespace-scoped）、backend 是哪一種（acme / vault / ca / venafi）、credential（ACME private key、Vault token、CA cert）放哪、RBAC 限制誰能參考這個 issuer
• Certificate spec：dnsNames / ipAddresses 跟實際 service 一致、duration 跟 renewBefore 比例合理（renewBefore >= duration / 3）、secretName 指向的 Secret 是不是 ingress 真的會讀的那個
• Renewal 觸發：controller log 有沒有按時觸發 renew、kubectl describe certificate 的 Renewal Time 接近沒、Challenge resource 沒有卡在 pending
• Challenge solver：HTTP01 的 ingress / Gateway 80 port 真的能被 Let’s Encrypt 從 Internet 打到、DNS01 用的 cloud provider credential 還有效、wildcard cert 沒誤用 HTTP01

四件事任一缺失、cert 就會在不知不覺中過期、production 看到 x509: certificate has expired 才驚覺、是 Transport Trust and Certificate Lifecycle 的典型缺口。

日常操作與決策形狀

Issuer vs ClusterIssuer 的選擇：Issuer 是 namespace-scoped、只能 issue 該 namespace 的 cert、適合 單 team 自管 issuer credential 的場景；ClusterIssuer 是 cluster-wide、所有 namespace 都可以參考、適合 平台 team 統一管理 issuer。production 通常用 ClusterIssuer 配特定 issuer backend + RBAC 收 Certificate 建立權（讓 application team 只能在自己 namespace 建 Certificate、不能改 ClusterIssuer）。

Certificate spec 設計：dnsNames 列出該 cert 涵蓋的 hostname（支援 wildcard *.example.com）、ipAddresses 加 IP SAN（mTLS 跨 service 常用）、duration 是 cert 有效期、renewBefore 是提前多久 renew（預設 duration 的 1/3）。短期 cert（hours-level、Vault PKI 常用）配 renewBefore 短、長期 cert（90 天、Let’s Encrypt）配 renewBefore 30 天。secretName 指向 cert-manager 會寫入的 Secret、Ingress 跟 workload 從這個 Secret 讀。

Challenge solver 的選擇：ACME issuer（Let’s Encrypt）需要證明 你控制這個 domain、有兩個方法：HTTP01（在 http://yourdomain/.well-known/acme-challenge/<token> 放檔案、Let’s Encrypt 從 Internet 來抓）跟 DNS01（在 DNS zone 加 _acme-challenge.yourdomain TXT <token> record、Let’s Encrypt 查 DNS）。wildcard cert（*.example.com）必須用 DNS01、HTTP01 不支援 wildcard 因為 Let’s Encrypt 不知道要打哪個 subdomain。HTTP01 要求 ingress controller 80 port 對 Internet 開放、DNS01 要求 cluster 有 cloud DNS API credential。

Auto-renewal 機制：cert-manager 在 cert lifetime 達到 (duration - renewBefore) 時間時觸發 renew、預設約 lifetime 2/3 點。Let’s Encrypt cert 90 天 = 60 天時開始嘗試 renew、留 30 天緩衝給 renew 失敗的重試。renew 失敗會持續重試（exponential backoff、最長 8 小時間隔）、剩下 ~7 天時 controller log 開始 ERROR 級別 alert — 監控要 hook 進這個 log 訊號、否則 cert 真的過期才知道就太晚。

跟 Ingress 整合：Ingress resource 加 annotation cert-manager.io/cluster-issuer: letsencrypt-prod（或 cert-manager.io/issuer:）、cert-manager 看到 Ingress 的 tls.hosts 自動建立對應 Certificate、issue 完寫進 tls.secretName 指定的 Secret、ingress controller 自動 reload 用新 cert。Gateway API 的整合機制類似、用 cert-manager.io/issuer annotation 在 Gateway resource。

CertificateRequest Approval Policy（v1.4+）：每個 Certificate 建立會產生 CertificateRequest、由 Approver 決定要不要送給 issuer。預設 cert-manager 內建 approver 自動 approve、但可以加 admission policy（Kyverno / OPA / 自寫 webhook）限制「誰能在哪個 namespace 建什麼 SAN 的 cert」— 防 internal compromise 任意 issue cert 對外冒名。production 環境通常會在 platform-level 鎖 wildcard cert、防 application team 誤建涵蓋整個 zone 的 cert。

核心取捨表

選 cert-manager 的核心訴求：cluster 內 cert 跨 issuer 統一管理 + 自動 renew + 跟 Ingress / Gateway declarative 整合。如果 cert 完全給 AWS service 用、不進 K8s workload、ACM 更簡單（不用裝 controller、AWS 自動處理）。如果是非 K8s 環境（VM、bare-metal Nginx）、certbot + cron 仍是合理選擇、不需要為了 cert 跑 K8s controller。

進階主題

DNS01 challenge 跟 cloud DNS 整合：cert-manager 支援多家 cloud DNS provider 作為 DNS01 solver — Route53、Cloud DNS（GCP）、Azure DNS、Cloudflare、ACMEDNS（自管 DNS proxy）。每個 provider 需要 DNS zone 寫入 credential（IAM role、service account key、API token）— 這份 credential 等於 任意改該 zone DNS record 的權力、blast radius 大、要走 least privilege 限定到 specific zone + 只給 TXT record write、不要全 zone 全 record type。

跟 Vault PKI engine 整合：cert-manager 可用 Vault PKI engine 作為 issuer backend — 在 cluster 內建 Issuer / ClusterIssuer type 為 vault、指向 Vault address + PKI mount path + auth method（Kubernetes auth / AppRole）。每張 cert 的 issue / revoke 都進 Vault audit log、跟 secret rotation 用同一套 evidence chain（呼應 Credential Rotation Scoped Evidence）。typical 用法：short-lived workload mTLS cert（hours-level duration、minutes-level renewBefore）、靠 Vault PKI 短期 cert + cert-manager 自動換。

跟 SPIRE 的互補：cert-manager 自動更新 cert、但 cert 是給人讀的 DNS name；SPIRE 自動建立 workload identity、identity 是 SPIFFE ID。兩者解不同問題 — cert-manager 解「Ingress / external API 的 TLS」、SPIRE 解「service A 要怎麼證明自己是 A 給 service B 看」。production 環境常 並存：edge cert 跟 user-facing TLS 用 cert-manager + Let’s Encrypt、internal service mesh 用 SPIRE + SPIFFE。

Trust bundle 管理（trust-manager）：trust-manager 是 cert-manager 姐妹專案、解決 trust anchor（root CA bundle）跨 namespace 同步 問題。傳統做法是每個 pod ConfigMap 各自塞 CA bundle、更新時要逐個改；trust-manager 提供 Bundle resource 一處定義、自動 distribute 到指定 namespace 的 ConfigMap。對應 cert rotation 跟 CA rotation 是兩條獨立 chain、後者是 trust-manager 的領域。

排錯與失敗快速判讀

• Challenge 卡在 pending：HTTP01 卡 = ingress 80 port 沒對 Internet、firewall / NLB 沒開、redirect 80→443 把 challenge 也轉了；DNS01 卡 = DNS provider credential 過期、IAM 沒 zone write 權、_acme-challenge record 沒寫進去 — kubectl describe challenge 看 reason
• Wildcard cert 用 HTTP01：申請失敗 + log 寫 “wildcard not supported with HTTP-01” — 改 DNS01 solver
• renewBefore 太短：renew 失敗只剩幾天才 alert、實際過期前來不及處理 — renewBefore 至少 duration / 3、production cert 給 30 天
• Secret 沒被 ingress 讀到：Certificate 已 Ready 但 ingress 還用舊 cert — ingress tls.secretName 拼錯、ingress controller 沒 reload、TLS handshake 用的 SNI 沒匹配
• ACME rate limit 撞牆：Let’s Encrypt rate limit 每週同 domain 50 cert / 同 account 300 pending — 反覆建錯 Certificate 重 issue 會撞、staging environment 用 letsencrypt-staging issuer 測過再上 prod
• ClusterIssuer 被 application team 誤改：沒設 RBAC、任何 namespace 都能 patch ClusterIssuer — 用 admission policy 鎖 ClusterIssuer 變更權給 platform team
• Approval Policy 缺失：任何 namespace 能建 wildcard cert、internal compromise 拿到 K8s API token 就能 issue 假冒 cert — 上 CertificateRequest Approval Policy + Kyverno / OPA rule

何時改走其他服務

不在本頁內的主題

• cert-manager Helm chart 的所有 value 細節跟版本相容性矩陣
• 每個 issuer backend 的完整 schema（acme / vault / venafi / ca / selfSigned）
• Gateway API 跟 Ingress API 的 cert-manager annotation 完整對照
• ACME RFC 8555 protocol 細節（HTTP01 / DNS01 / TLS-ALPN-01 challenge mechanism）
• trust-manager 的 Bundle source 種類（inMemory / secret / configMap / defaultPackage）

案例回寫

cert-manager 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、Transport Trust and Certificate Lifecycle
• 平行：Let’s Encrypt（ACME issuer）、AWS ACM（AWS-managed cert）、SPIRE（workload identity）
• 下游：HashiCorp Vault（PKI engine 作為 issuer backend）
• 跨模組：8 事故處理 vendor 清單（cert 過期 / mis-issue 事件如何 routing）
• 官方：cert-manager Documentation

服務定位

ACM 的核心定位是 AWS 平台內 cert 的全託管 lifecycle。客戶不持私鑰、不跑 ACME client、不手動 renew — 但代價是 ACM public cert 只能 attach 到 AWS-managed service（ELB / CloudFront / API Gateway / App Runner / Nitro Enclaves）、不能 export 給自管 Nginx / EC2 應用。Private cert 必須有 ACM Private CA (PCA) 後端、ACM 自己不是 CA。

跟其他 cert 工具的場景重疊度低、定位是分工互補：cert-manager 走 cluster 內 K8s workload cert（Ingress / service mesh）、Let’s Encrypt 走跨平台公共 ACME cert（可 export 任何地方使用）、ACM Private CA 走自管 CA hierarchy（root + intermediate、客戶控制 policy）。常見組合：AWS-native endpoint 用 ACM、K8s workload + 自管伺服器走 cert-manager + Let’s Encrypt、內部 mTLS root 走 PCA。詳細差異見「核心取捨表」。

本章目標

讀完本頁、讀者能判斷：

1. ACM public cert vs private cert vs imported cert 各自的使用邊界（能 attach 哪些 service、能不能 export）
2. DNS validation vs Email validation 的差異、跟 auto-renewal 條件的關聯
3. 跨 region 跟 CloudFront 的 us-east-1 限制如何處理
4. 何時 ACM 不夠用、要改走 cert-manager / Let’s Encrypt / ACM Private CA

最短判讀路徑

判斷 ACM cert 部署是否健康、最少看四件事：

• Cert 跟 service 整合：cert ARN 是否真的 attach 到 ELB / CloudFront / API Gateway listener、DescribeCertificate 的 InUseBy 有沒有資源、有 cert 但沒 attach 等於 issue 失敗
• DNS validation 設定：cert 是 DNS 還是 Email validation、DNS 的 CNAME record 是否還留在 DNS（auto-renewal 需要這條 record 持續存在）、Route53 vs 外部 DNS 的責任分界
• Renewal status：DescribeCertificate 的 RenewalSummary.RenewalStatus 是 SUCCESS / PENDING_AUTO_RENEWAL / FAILED、失敗時 RenewalStatusReason 是什麼（多半是 DNS record 被刪、CNAME 不再回應）
• CloudTrail 證據：RequestCertificate / ImportCertificate / DeleteCertificate 的 caller identity、是否有非預期的 cert 建立或刪除（防誤刪 / 惡意刪）

四件事任一缺失、就是 Transport Trust and Certificate Lifecycle 的覆蓋缺口。

日常操作與決策形狀

Request public cert：對 internet-facing endpoint（網站、API）issue public cert、走 RequestCertificate API、選 DNS validation。ACM 給一組 CNAME record、放進 DNS（Route53 可一鍵 create）、ACM 自動驗證 + issue。Cert 生效後 attach 到 ELB / CloudFront / API Gateway listener。Issuer 是 Amazon Trust Services、所有主流瀏覽器 / OS trust store 都認。

Request private cert（需 PCA 後端）：內部 service mTLS root、走 RequestCertificate 但指定 PCA ARN。ACM 透過 PCA 簽 cert、cert chain 是組織內部 CA hierarchy。Trust store 必須在各 workload 手動建立（不像 public cert 自動 trust）。

DNS validation vs Email validation：DNS validation 是預設 + 推薦 — CNAME record 放進 DNS 後、ACM 持續驗證 domain ownership、auto-renewal 全自動。Email validation 是 legacy、ACM 寄信到 domain 的 WHOIS / 預設 admin email、人工點連結驗證；auto-renewal 不會自動完成、cert 到期前必須手動 re-validate。Production 一律用 DNS validation。

Auto-renewal 條件：ACM 在 cert lifetime 60 天前嘗試 renew、條件嚴格：(1) cert 是 ACM-issued（不是 imported）(2) DNS validation 走 CNAME record 仍存在且可回應 (3) cert 至少 attach 到一個 AWS service。三個條件任一不滿足、renewal 不自動觸發、cert 會 expire。Imported cert 完全不自動 renew、必須在 expiry 前手動 re-import。

跟 ELB / CloudFront / API Gateway 整合：ELB / API Gateway 用所在 region 的 ACM cert、CloudFront 例外 — 只認 us-east-1 region 的 ACM cert（CloudFront edge 是 global、cert metadata 統一從 us-east-1 拉）。Multi-region app 要在每個 region 各 request 一份 cert、CloudFront 那份固定放 us-east-1。

Imported certificate：自管 cert（外部 CA 簽的、舊系統遷移過來的）可以 import 進 ACM、拿到 ARN 後一樣 attach 到 AWS service。代價是 ACM 不會 renew、expiry 前必須手動 re-import 新版。常見事故源：imported cert 過期、AWS service 突然 serve expired cert、Browser 顯示警告。建議 imported cert 都設 CloudWatch alarm 監 DaysToExpiry。

跟 AWS IAM 整合：誰能 issue / delete cert 走 IAM policy 控制 — acm:RequestCertificate / acm:DeleteCertificate / acm:ImportCertificate。Tag-based access control 可以限定「只有帶 team=platform tag 的 cert 才能被 platform team IAM role 改」、防誤刪 production cert。Cert 是 region-scoped resource、IAM policy 可指定 Resource ARN 限定 region / cert ID。

核心取捨表

選 ACM 的核心訴求：cert 主要 attach 到 AWS-managed service、希望 cert 完全 hands-off、不需要 export 私鑰、能接受 AWS lock-in。需要 export PEM 或跨雲 / 自管 endpoint、改走 cert-manager + Let’s Encrypt。需要內部 mTLS root + CA hierarchy 控制、走 ACM Private CA。

進階主題

ACM Private CA hierarchy：PCA 支援 root CA + 多層 intermediate CA、生產建議 root CA 離線（CA 簽完 intermediate 後 disable）、日常簽發走 subordinate CA。Subordinate CA compromise 時 revoke 該層、root 不受影響。Cert policy（path length、key usage、name constraint）在 CA 建立時設定、之後無法改、設計時要算對。

Cross-region cert（CloudFront 的 us-east-1 限制）：CloudFront 是 global service、但 attach 的 ACM cert 必須在 us-east-1。Multi-region 部署：每個 region 各 issue 一份 cert 給該 region 的 ELB / API Gateway、CloudFront 的那份單獨在 us-east-1 issue。Terraform / CloudFormation 要顯式宣告 provider region。

Imported cert 跟 auto-renewal 邊界：imported cert（外部 CA 簽的）ACM 知道存在、可以 attach、但 不 renew。常見事故：團隊 import cert 後忘了；幾個月後 cert 到期；CloudFront / ELB serve expired cert；客戶看到 browser 警告。對策：所有 imported cert 設 CloudWatch alarm DaysToExpiry < 30、AlmostExpired event 推 EventBridge → PagerDuty。長期策略是把 imported cert 都遷移成 ACM-issued cert（如果 domain ownership 可驗證）。

Tag-based access control：cert 加 tag（team=platform、env=prod）後、IAM policy 用 Condition 限定：只有同 tag 的 role 才能 update / delete。防誤刪 production cert（dev IAM role 跑 cleanup script 不會誤刪 prod）。配合 AWS IAM 的 ABAC 模型運作。

Wildcard cert 跟 SAN cert：ACM 支援 wildcard（*.example.com 涵蓋一層 subdomain）跟 SAN（一張 cert 多個 domain，最多 100 個）。Wildcard 簡化部署但 blast radius 大 — 一張 cert compromise 等於整個 subdomain tree 出事；SAN cert 細粒度但管理成本高。Production 建議按服務邊界拆 — 每個 service 一張 cert、不共用 wildcard，除非確實有大量短 lifecycle subdomain。

排錯與失敗快速判讀

• Cert PENDING_VALIDATION 一直卡住：DNS validation CNAME record 沒放對、或 DNS provider 緩存太久 — 用 dig 直接查 CNAME 是否生效、Route53 + ACM 整合通常幾分鐘、外部 DNS 可能 30 分鐘以上
• Cert renewal FAILED：RenewalStatusReason 多半是 DOMAIN_VALIDATION_DENIED（CNAME record 被刪了）或 cert 沒 attach 到任何 service — 補回 CNAME record、或把 cert attach 到至少一個 resource
• CloudFront 找不到 cert：cert 在 us-east-1 以外的 region issue — 在 us-east-1 重 issue、或用 Terraform 顯式跨 provider 設定
• Imported cert expired：忘了 manual renewal、AWS service serve expired cert — CloudWatch alarm + EventBridge 推 alert、長期遷成 ACM-issued
• ACM cert 無法用在 EC2 自管 Nginx：public cert 私鑰不能 export 是設計限制 — 改用 ACM Private CA 或 Let’s Encrypt + cert-manager
• 誤刪 production cert：沒設 tag-based protection、admin script bug — 開 deletion protection（暫時無內建、用 IAM Condition 限定 delete operation + 24h cooldown via Lambda）+ CloudTrail alert 上 acm:DeleteCertificate
• Cross-account cert 共用：ACM cert 不支援 RAM 共用 — 跨 account 要在每個 account 各 issue（或用 PCA + RAM 共用 PCA、各 account 從 PCA issue）

何時改走其他服務

不在本頁內的主題

• ACM Private CA 完整 hierarchy 設計（root CA 離線儲存、HSM-backed CA key、CRL / OCSP responder 部署）
• ACM API 完整 CLI reference 跟 Terraform resource 詳盡欄位
• TLS protocol 本身（TLS 1.2 vs 1.3、cipher suite、handshake 流程）
• Certificate Transparency log 跟 SCT embedding 內部機制
• 各 browser / OS trust store 的更新週期

案例回寫

ACM 在 07 案例庫沒有直接 vendor-level 事件、以下採對照引用：

下一步路由

• 上游：7.4 傳輸信任與憑證生命週期、7.3 入口治理與伺服器防護
• 平行：cert-manager、Let’s Encrypt、SPIRE
• 下游：AWS IAM（誰能 issue / delete cert）、AWS KMS（PCA CA key 後端）
• 跨模組：8 事故處理 vendor 清單（cert expiry / mis-issuance 進 IR 流程）
• 官方：AWS Certificate Manager Documentation

服務定位

Let’s Encrypt 的角色是 跨雲、跨平台、跨組織規模 的公共 DV cert 來源。對於需要 public TLS cert 又不被特定雲廠綁定的場景（on-prem、edge node、跨雲 service、自架 CDN origin、開源專案）、Let’s Encrypt 是預設選項。它解決的問題不是「能不能拿到 cert」、而是「能不能 無人值守 持續拿到 cert」— ACME protocol 把申請、驗證、issue、renew、revoke 全部標準化、ACME client（cert-manager / certbot / acme.sh / Caddy / Traefik）負責 client 端執行。

跟 AWS ACM 比、Let’s Encrypt 跨雲跨平台、ACM 限 AWS-managed service（ALB / CloudFront / API Gateway）內使用、export 出去要另談；ACM Private CA 又是另一個產品。跟商業 CA（DigiCert / Sectigo / Entrust）比、商業 CA 提供 OV（Organization Validation）/ EV（Extended Validation）cert、cert 內含經過驗證的組織資訊、金融網站或法遵需求會用；Let’s Encrypt 只發 DV cert、不驗證組織身份。跟 HashiCorp Vault PKI 比、Vault PKI 是 internal CA（不被公共瀏覽器信任、適合 internal mTLS / workload identity）、Let’s Encrypt 是 public CA（瀏覽器信任、適合 public-facing service）— 兩個是互補關係、不是替代。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 cert 需求適合 Let’s Encrypt（public-facing、DV、跨平台）、哪些該走 ACM / 商業 CA / Vault PKI
2. ACME protocol 的四個 first-class concept（Account / Order / Authorization / Challenge）跟自己選的 ACME client 怎麼對應
3. Rate limit 是 硬限制、SaaS 多 tenant 場景如何規劃（wildcard / SAN / rate limit exemption）
4. 90 天 TTL + CT log 公開 + revocation 弱化 在 production 設計上的影響

最短判讀路徑

判斷 Let’s Encrypt 使用是否健康、最少看四件事：

• Account 管理：ACME account 是 cross-domain 的身份、同一個 account 可以申請組織所有 domain 的 cert — account key 外洩等於 attacker 可以對所有 domain 發 cert；account key 是否離線備份、是否跟 ACME client 用獨立 key（不重用 server key）
• Challenge 選擇：HTTP-01 需要 port 80 reachable、適合單機 + 直接 internet 暴露；DNS-01 需要 DNS API access、適合 wildcard + 私有環境；TLS-ALPN-01 走 443、適合 port 80 不可用的場景 — Challenge 選錯會卡在 validation 階段
• Rate limit 規劃：50 cert/week per registered domain、5 duplicate cert/week — 大型 SaaS 服務多 customer subdomain 容易撞牆、要先估 cert 量、再決定 wildcard / SAN / rate limit 申請
• Revocation 流程：cert 被洩漏怎麼辦 — revoke 不是 fleet-wide invalidation、real-world 失效靠 rotate + 短 TTL；revocation 程序是否寫入 runbook、舊 cert 是否在所有 endpoint 確實 retire

四件事任一缺失、就是 Transport Trust and Certificate Lifecycle 跟 Credential Rotation Scoped Evidence 邊界的待補項目。

日常操作與決策形狀

ACME client 選擇：cert-manager 適合 K8s 環境、Ingress / Gateway / Certificate CRD 自動化；certbot 適合單機 / VM、官方參考實作；acme.sh 是 pure shell、嵌入既有 deployment script 容易；Caddy / Traefik 把 ACME 內建進 reverse proxy、零設定拿 cert。client 端的選擇決定 cert 怎麼存、怎麼 deploy 到 termination point、Let’s Encrypt 自己不管這層。

ACME Account（cross-domain identity）：Account 是 ACME server 認可的身份、用一把 account key（不同於 cert private key）簽 ACME request。同一個 account 可以申請 組織所有 domain 的 cert — 安全意義是 account key 外洩 = attacker 對所有 domain 都能 issue cert。Production 場景把 account key 視為跟 root signing key 同等級的 secret、離線備份、跟日常 ACME client 用獨立 key。

Challenge 選擇 — HTTP-01 / DNS-01 / TLS-ALPN-01：HTTP-01 在 /.well-known/acme-challenge/<token> 放 response、Let’s Encrypt 從 port 80 拉、適合單機 + 直接 internet 暴露；DNS-01 在 _acme-challenge.<domain> 放 TXT record、適合 wildcard cert（*.example.com 必須 DNS-01、HTTP-01 不行）跟私有環境（不需要 port 80 開放）；TLS-ALPN-01 走 port 443、用 special ALPN extension 回 challenge、適合 port 80 被擋的場景。Wildcard cert 強制 DNS-01 是 Let’s Encrypt 政策、不能用 HTTP-01 繞過。

Rate limit 是硬限制：50 cert/week per registered domain（包含 SAN 在內）、5 duplicate cert/week（同樣 SAN 組合）、300 new orders/3 hours per account、5 failed validation/hour。大型 SaaS 對 N 個 customer subdomain 發 cert 容易撞牆 — 解法有三：用 wildcard cert 把多 subdomain 合一張（單張 cert 服務無限 subdomain）、用 SAN cert 把多個 subdomain 寫進同一張 cert、申請 rate limit 上限提高（官方表單）。撞 rate limit 後該 domain 整個 week 不能發新 cert、是 production outage 等級。

Staging environment 必用於測試：acme-staging-v02.api.letsencrypt.org 是 Let’s Encrypt 的測試 endpoint、cert 不被瀏覽器信任、但 rate limit 寬鬆很多（30000 cert/week / 60 duplicate cert/week）。debug ACME client 設定、新 deploy pipeline、CI 跑 cert renewal test 都應該先指 staging、確認 OK 再切 production endpoint。直接在 production 試錯撞 rate limit 是常見事故。

90 天 TTL + 60 天 renew cadence：Let’s Encrypt cert 固定 90 天 TTL、ACME client convention 是 過 60 天就開始 renew、留 30 天 buffer 給 retry。90 天是 設計選擇、不是技術限制 — 短 TTL 強迫自動化、把「過期前手動處理」這個失敗模式從設計中拿掉。如果你的 cert renewal 還需要人介入、表示 ACME client / deployment pipeline / monitoring 哪邊沒做好、要在 60 天 buffer 內修。

CT log 公開可查：Let’s Encrypt cert 都會進 Certificate Transparency log（CT log）、可以用 crt.sh 查任何 domain 的歷史 cert。對 production 意義有兩面：blue team 可以監控自家 domain 的 unexpected cert（attacker 用相似 domain 釣魚會留痕）；red team 可以查 target 公司新出現的 internal hostname（cert 上的 SAN 等於公開的 service inventory）。對 internal-only hostname、不要用 Let’s Encrypt cert、否則 SAN 變成 recon 資料源 — 內部服務走 Vault PKI / 私有 CA。

核心取捨表

選 Let’s Encrypt 的核心訴求：public-facing + DV 等級夠用 + 跨平台 + 需要自動化。需要 EV cert 走商業 CA、需要 internal mTLS 走 Vault PKI、AWS-only + 留在 ALB / CloudFront 內走 ACM 更省事。

進階主題

Rate limit 規劃跟 SaaS 多 tenant：N 個 customer subdomain 場景下、單 domain 50 cert/week 很容易撞牆。設計選項：(1) wildcard cert（*.app.example.com）一張覆蓋無限 subdomain、但 wildcard cert 不能保護 nested subdomain（*.app.example.com 不蓋 foo.bar.app.example.com）；(2) SAN cert 把多個 subdomain 寫進同一張 cert（單張最多 100 個 SAN）、適合 customer 數固定、新增不頻繁的場景；(3) 申請 rate limit 上限提高、production scale SaaS 走這條；(4) cert reuse — 同樣 SAN 組合在 5 duplicate cert/week 內可 reuse、不重發。

跟 cert-manager + DNS-01 整合：production K8s 環境最常見組合是 cert-manager + Let’s Encrypt + DNS-01、DNS provider 走 Route53 / Cloud DNS / Cloudflare。cert-manager 用 ClusterIssuer 設定 Let’s Encrypt account + DNS solver、Certificate CRD 宣告需要的 cert、cert-manager 自動完成 ACME flow。優勢是 wildcard cert 可用（DNS-01 不受 HTTP-01 的 port 80 限制）、跨 cluster 可標準化、cert renewal 進 K8s event stream 容易監控。

ACME profiles（client-specific behavior）：Let’s Encrypt 2024 開始提供 ACME profile 機制、允許 client 選擇 cert 屬性（如 short-lived 6 天 cert vs standard 90 天）。short-lived cert 適合機器 workload、進一步壓縮 revocation 缺陷的影響窗口；普通 web service 用 standard profile 即可。Profile 是 opt-in、ACME client 要支援。

跨 ACME CA fallback：Let’s Encrypt 不是唯一 ACME CA — ZeroSSL、Buypass、Google Trust Services 都提供 ACME endpoint。production 建議 ACME client 設兩個 issuer（Let’s Encrypt primary + ZeroSSL / Buypass secondary）、Let’s Encrypt 出事（rate limit 撞牆、AWS outage 影響 challenge 驗證、ISRG 服務中斷）時可以 fallback、不會 cert 全停。cert-manager 用兩個 ClusterIssuer 即可、application 端零感知。

Revocation 的弱化現實：cert 可以 revoke、但實際失效路徑薄弱 — CRL（Certificate Revocation List）跟 OCSP（Online Certificate Status Protocol）更新有延遲、且大多數 client（瀏覽器、API client）不會主動檢查 revocation 狀態（soft-fail：查不到就放行）。real-world 的 cert 失效機制其實是 短 TTL + rotate、不是 revocation API。設計時不要寄望 revoke 後 attacker 拿到的 cert 就無效 — rotate 出新 cert + 在所有 endpoint deploy 新 cert + 觀察舊 cert traffic 歸零、才算真正失效。

排錯與失敗快速判讀

• ACME challenge 失敗：HTTP-01 拉不到 /.well-known/acme-challenge/<token>、檢查 port 80 reachability、firewall、CDN 是否擋；DNS-01 TXT record 沒生效、檢查 DNS provider API permission、TXT TTL 是否設太長
• 撞 rate limit：50 cert/week per registered domain 撞牆、整個 week 不能發新 cert — production 必須先 staging 測完 再切 production、cert reuse 機制要開（同 SAN 組合不重發）、長期解走 wildcard / SAN consolidation / rate limit exemption
• Renewal 沒在 60 天前開始：cert 過期前才 renew、撞到 ACME server 暫時不可用會直接過期 — ACME client 設 60 天 renew threshold、cert expiry 30 天前 alert 給 oncall
• Account key 沒備份：account key 弄丟、可以重新註冊但 舊 cert 的 revocation 權限沒了（除非用 cert 私鑰 revoke）— account key 跟 root signing key 同等級保護、離線備份
• CT log 暴露 internal hostname：Let’s Encrypt cert 進 CT log、internal-only hostname 的 SAN 變 recon 資料源 — internal service 不用 Let’s Encrypt、改 Vault PKI / 私有 CA
• Wildcard cert 用 HTTP-01：*.example.com 申請失敗、Let’s Encrypt 政策強制 wildcard 走 DNS-01 — 切到 DNS-01 solver、設定 DNS provider API access
• Cert 出事 revoke 後 attacker 還能用：revocation 不是 fleet-wide invalidation、CRL/OCSP 多數 client 不檢查 — 真正失效靠 rotate + 觀察舊 cert traffic 歸零、不是 revoke API

何時改走其他服務

不在本頁內的主題

• ACME protocol RFC 8555 完整規格逐條解讀
• 每個 ACME client（certbot / cert-manager / acme.sh / Caddy / Traefik）的完整設定教學
• Let’s Encrypt 內部 CA infrastructure 跟 ISRG governance 細節
• CT log 內部結構跟 SCT（Signed Certificate Timestamp）驗證流程
• DNS provider 的 API 認證設定（Route53 IAM / Cloud DNS service account / Cloudflare API token）

案例回寫

Let’s Encrypt 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.4 Transport Trust and Certificate Lifecycle、7.5 Credential Rotation Scoped Evidence
• 平行：AWS ACM、cert-manager、SPIRE
• 下游：HashiCorp Vault（Vault PKI 處理 internal CA、跟 Let’s Encrypt public CA 互補）
• 跨模組：8 事故處理 vendor 清單（cert 出事 / private key 外洩如何 routing 進 IR 流程）
• 官方：Let’s Encrypt Documentation、ACME RFC 8555、crt.sh CT log search

mTLS 的核心是把系統身分綁到 X.509 憑證與私鑰，而不是可重用的 shared secret。介紹文章常把它簡化成「雙向 TLS 憑證、適合金融醫療」，但實際落地時，設計責任會立刻延伸到 CA 階層、憑證生命週期、撤銷與基礎設施整合：

• 自簽 CA 還是商業 CA？
• 憑證放哪、怎麼 rotate？
• 怎麼撤銷？CRL 還是 OCSP 還是 short-lived cert？
• nginx 設定怎麼寫、service mesh 怎麼整合？
• 跟 API Key、OAuth 比，什麼情境適合承擔 mTLS 的運維成本？

這些是 mTLS 第一次部署就要處理的基本問題。若只知道「雙向憑證」而沒有 lifecycle 設計，系統會在過期、撤銷或 mesh 升級時失去可預測性。

本文拆解 mTLS 的工程實務：

1. CA 階層：為什麼要分層、Root CA / Intermediate CA / Leaf cert
2. 憑證生命週期：簽發、儲存、rotation、撤銷
3. 基礎設施整合：nginx / envoy / service mesh 設定模式
4. 跟其他 Layer 2 方案的取捨：何時 mTLS 才是對的選擇

本文位置：本文是 API 認證的三層信任邊界 Layer 2 的深入篇之一。主文聚焦「為什麼系統間要獨立 credential」、本文聚焦「用 mTLS 實作這層的具體工程細節」。

mTLS 解什麼問題

跟一般 TLS 的差異

一般 TLS（HTTPS）是單向認證：client 驗證 server 身分，server 再透過 API Key、token 或 session 辨識 client。

1client ────"我要連 example.com"────▶ server
2       ◀───server 出示憑證───────── server
3       驗證:"這是真的 example.com 嗎"
4       ↓
5       建立加密通道

client 驗證 server、但 server 不驗證 client。Client 是匿名的、靠後續 API Key / token 認證。

mTLS 加上反向驗證：server 也在 TLS handshake 階段驗證 client 憑證，把系統身分提前到連線層建立。

1client ──"我要連 example.com、這是我的憑證"──▶ server
2       ◀──server 出示憑證───────────────────── server
3       
4       雙方驗證對方憑證：
5       client: "這是真的 example.com 嗎"
6       server: "這個 client 是被授權的嗎"
7       ↓
8       建立加密通道、且雙方都已認證

每個 client 有自己的憑證、server 用 CA 信任鏈驗證 client 憑證是否合法。Client 的身分綁定在 X.509 憑證上、不需要額外的 API Key。

mTLS 解的具體威脅

mTLS 的核心優勢是：client 端的 private key 是 scope-bound、不跨系統共用。私鑰理論上不離開 client，且驗證憑藉的是 CA 簽章而非可重用字串；相較 shared API Key，一個 client 的私鑰外流通常可被限制在該 client 的憑證與授權範圍內。

代價是：PKI 基礎建設複雜、憑證生命週期管理重、運維成本高。

CA 階層設計

為什麼要分層

CA 分層的核心責任是降低最高信任根的暴露頻率。直覺做法是「用一張 Root CA 直接簽 client 憑證」：

1Root CA ──signs──▶ client-A.crt
2        ──signs──▶ client-B.crt
3        ──signs──▶ client-C.crt
4        ...

Root CA 私鑰是整個 PKI 的最高信任根，通常需要離線、HSM 與多人簽核。它一旦洩漏，所有信任這個 Root 的系統都要重新建立信任；Root CA 又通常活 10-20 年，撤換成本極高。

如果 Root CA 私鑰要常常拿出來簽 client cert、暴露風險就大幅提高。

解法：分層。Root CA 只簽 Intermediate CA、Intermediate CA 負責日常簽發 client cert：

1Root CA (offline, 20 年)
2    ↓ signs (一次性 / 5-10 年)
3Intermediate CA (online, 1-5 年)
4    ↓ signs (日常、每張 90 天-1 年)
5Leaf certificates (client / server)

Root CA 通常完全離線（air-gapped 機器、硬體 HSM）、私鑰一年只拿出來簽幾次（簽 Intermediate）。Intermediate CA 才是 online、處理日常簽發。

階層帶來的好處

三種典型部署模式

模式 A：自管 CA

完全自己跑 CA infra：

• Root CA：離線 HSM、年度作業簽 Intermediate
• Intermediate CA：online、用工具如 step-ca、cfssl、Vault PKI、Smallstep
• Leaf cert：自動化簽發、短 TTL

適合：純內部系統、不需 public trust、要完全控制 CA infrastructure。

模式 B：商業 CA（DigiCert / Sectigo / Entrust）

買商業 CA 服務、商業 CA 已預埋進所有 OS / browser trust store：

• 適合：需要 public trust（HTTPS server cert、SSL/TLS for end users）
• mTLS client cert 通常在自己的封閉系統內驗證，public trust 的價值較低，因此較少使用商業 CA

模式 C：Cloud-managed PKI

雲廠商提供 managed PKI：

• AWS Private CA（ACM PCA）— managed Root + Intermediate
• GCP Certificate Authority Service
• Azure Key Vault Certificates

適合：已在某朵雲、不想自管 CA infra、可接受 vendor lock。

自管 CA 的最小工具鏈

如果走模式 A、推薦工具：

step-ca 是最低門檻的起手選擇 — 一行 step ca init 建好整套 CA、自動發 ACME 給 client。

憑證生命週期

簽發

Server cert 簽發流程：

11. Server 產生 private key (RSA 2048+ 或 ECDSA P-256)
22. Server 用 private key 產生 CSR (Certificate Signing Request)
33. CSR 送給 CA
44. CA 驗證 CSR 內容（DN、SAN、用途）
55. CA 用 Intermediate CA 私鑰簽 cert
66. 把簽好的 cert 回給 server
77. Server 部署 cert + 自己的 private key

Client cert 簽發流程：跟 server 一樣，但 SAN 通常是 client identifier（service name、device ID），而非 hostname。

私鑰留在產生端

關鍵安全原則是：private key 在哪產生、就只在那裡存活。CA 只收 CSR（裡面只有 public key），簽完 cert 回去；client private key 全程留在 client 的受控環境。

失效模式：

• CA 幫 client 產生 keypair、把 private key 跟 cert 一起寄給 client（密鑰在 CA 經手了）
• 把 private key 跟 cert 打包成 PKCS12 用 email 寄
• 把 keypair 放進公共 git repo

操作路由：

• Client 端產生 keypair、只送 CSR 給 CA（CSR 只含 public key）、簽完 cert 回來、private key 全程不離開 client

儲存

Private key 的儲存等級：

Production server cert 私鑰至少應該 OS 層保護（檔案權限 + 加密磁碟）、高敏感場景上 HSM。

Rotation

mTLS 憑證的 rotation 跟 shared secret rotation 概念類似、但有具體差異：

實務上的 rotation 模式：

短 TTL + 自動續發（推薦）：

• Leaf cert TTL 設短（24 小時 ~ 7 天）
• 用 ACME protocol（如 Let’s Encrypt 的協定）讓 client 自動續發
• rotation 由續發流程承擔，過期前自動換新

工具：cert-manager（K8s）、step-ca + step、certbot。

中 TTL + 半自動（傳統）：

• TTL 1 年、年度手動 rotation
• 用工具列管所有 cert 的 notAfter、過期前 30 天自動告警
• 適合舊架構、無法跑短 TTL 的場景

長 TTL（不建議）：

• TTL 多年、近乎不 rotate
• 私鑰暴露窗極長、被洩漏到察覺的時間差大
• 唯一情境：IoT 設備、無法 OTA 更新

撤銷

當 cert 在 notAfter 前需要失效（私鑰洩漏、員工離職、合約終止）、需要撤銷機制。有三種主流方案：

CRL（Certificate Revocation List）

CA 維護一份「已撤銷憑證 list」、定期發佈（小時級到天級）。Client 端要：

1. 下載最新 CRL
2. 連線時檢查對方 cert 是否在 CRL 內

優點：簡單、infrastructure 輕。

缺點：

• CRL 大、下載成本高
• Cache 期內撤銷不生效（最差幾小時）
• Client 沒下載 CRL、撤銷完全沒效

OCSP（Online Certificate Status Protocol）

Real-time 查詢、client 每次連線時即時 query OCSP responder：「這張 cert 還有效嗎？」

優點：Real-time、撤銷即時生效。

缺點：

• 每次連線增加一次 OCSP query、延遲
• OCSP responder 是 single point of failure
• Privacy 顧慮（每次連線都告訴 CA 你在連誰）

進階：OCSP Stapling — server 預先 query OCSP、把結果 staple 在自己的 cert chain 裡、client 不需自己 query。解決延遲跟 privacy、但 server 端要實作。

Short-lived cert（不撤銷、讓它過期）

最現代的做法：cert TTL 極短（小時、甚至分鐘）、不實作撤銷機制、靠過期自然失效。

優點：

• 可省略 CRL / OCSP infrastructure
• 撤銷窗 = TTL（小時級）、可預期
• Privacy 友善

缺點：

• 需要可靠的自動續發機制
• Client 無法續發時直接斷線

工具：SPIFFE/SPIRE 主推這個模式、cert TTL 設小時級。

三種撤銷方案的選擇

基礎設施整合

nginx 設定 mTLS server

最常見的場景：nginx 當 reverse proxy、要求 client 出示憑證。

 1server {
 2    listen 443 ssl;
 3    server_name api.example.com;
 4
 5    # Server cert (出示給 client)
 6    ssl_certificate     /etc/ssl/certs/api.crt;
 7    ssl_certificate_key /etc/ssl/private/api.key;
 8
 9    # 要求 client 出示憑證、用這個 CA 驗證
10    ssl_client_certificate /etc/ssl/ca/client-ca-chain.pem;
11    ssl_verify_client on;            # 強制 client 出示憑證、否則拒絕
12    ssl_verify_depth 2;              # 驗證 chain 深度、視 PKI 階層調 (Root → Intermediate → Leaf)
13
14    location / {
15        # 把 client cert 資訊傳給後端 application
16        proxy_set_header X-Client-DN  $ssl_client_s_dn;
17        proxy_set_header X-Client-Verify $ssl_client_verify;
18        proxy_pass http://backend;
19    }
20}

關鍵 directive：

nginx 設定 mTLS client（呼叫上游）

當 nginx 是 client、要呼叫上游 mTLS server：

1location /upstream {
2    proxy_pass https://upstream.example.com;
3    proxy_ssl_certificate     /etc/ssl/certs/client.crt;
4    proxy_ssl_certificate_key /etc/ssl/private/client.key;
5    proxy_ssl_trusted_certificate /etc/ssl/ca/upstream-ca.pem;
6    proxy_ssl_verify on;
7}

Envoy / API Gateway 整合

Envoy 是 service mesh 的常見 data plane、mTLS 設定模式：

 1listeners:
 2- name: api_listener
 3  address: { socket_address: { port_value: 443 } }
 4  filter_chains:
 5  - transport_socket:
 6      name: envoy.transport_sockets.tls
 7      typed_config:
 8        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
 9        common_tls_context:
10          tls_certificates:
11          - certificate_chain: { filename: /etc/ssl/api.crt }
12            private_key:      { filename: /etc/ssl/api.key }
13          validation_context:
14            trusted_ca: { filename: /etc/ssl/client-ca.pem }
15        require_client_certificate: true

上方只展 inbound listener 的 DownstreamTlsContext。Envoy 作為 client 呼叫上游 mTLS server 時、要在對應的 cluster 配 transport_socket + UpstreamTlsContext（含 client cert + private key + trusted CA）、不在這份 listener 設定裡。

跟 nginx 比、Envoy 的優勢：

• 動態設定（xDS API、不需 reload）
• 支援 SDS（Secret Discovery Service）動態取憑證
• 跟 Istio / Linkerd 等 mesh 整合

Service Mesh（Istio / Linkerd）

Service mesh 內建 mTLS：

1# Istio: 強制 mesh 內所有 service 走 mTLS
2apiVersion: security.istio.io/v1beta1
3kind: PeerAuthentication
4metadata:
5  name: default
6  namespace: production
7spec:
8  mtls:
9    mode: STRICT

機制：

• Mesh control plane（Istio: Istiod / Linkerd: identity）內建 CA、自動發每個 pod 一張 cert
• Sidecar proxy（Envoy / Linkerd proxy）handle TLS termination、application code 完全不感
• Cert TTL 短（Istio 預設 24 小時、視版本而定）、自動續發
• mTLS identity 綁定 K8s ServiceAccount

優點：application 完全不用改 code、不用管 cert、不用管 rotation — mesh 全包。

缺點：綁定整套 mesh 架構、運維 mesh 本身是大事、學習曲線陡。

為 application 直接做 mTLS

某些場景（沒 mesh、需要 application 級控制）需要 application 直接做 mTLS：

1# Python requests 範例 - mTLS client
2import requests
3
4response = requests.get(
5    'https://api.example.com/data',
6    cert=('/path/to/client.crt', '/path/to/client.key'),
7    verify='/path/to/server-ca.pem',
8)

 1// Go net/http 範例 - mTLS client
 2cert, err := tls.LoadX509KeyPair("client.crt", "client.key")
 3if err != nil { return err }
 4
 5caCert, err := os.ReadFile("server-ca.pem")
 6if err != nil { return err }
 7caCertPool := x509.NewCertPool()
 8caCertPool.AppendCertsFromPEM(caCert)
 9
10client := &http.Client{
11    Transport: &http.Transport{
12        TLSClientConfig: &tls.Config{
13            Certificates: []tls.Certificate{cert},
14            RootCAs:      caCertPool,
15        },
16    },
17}
18resp, err := client.Get("https://api.example.com/data")

每個語言的 stdlib 都有對應 API、寫法大同小異。但 application 要自己處理 cert reload、過期、rotation — 比 service mesh 麻煩很多。

跟其他 Layer 2 方案的成本比較

mTLS 在三層信任邊界的 Layer 2 是安全強度高、運維責任也重的選項。是否採用，要看威脅模型、合規要求、私鑰保護能力與自動化成熟度。

mTLS 適合的場景

mTLS 成本偏高的場景

常見失敗模式

失敗 1：忘記 Intermediate CA、chain 不完整

症狀：server 設定看似正確、但 client 連線時報 certificate verify failed。

根因：server 端只放了 leaf cert、沒附 Intermediate CA。Client 端只信任 Root、無法 chain 到 Root。

緩解：server 端 ssl_certificate 要放完整 chain（leaf + intermediate、不含 root）：

1cat leaf.crt intermediate.crt > chain.crt
2# nginx 用 chain.crt 而非單獨 leaf.crt

失敗 2：Cert 過期造成連線中斷

症狀：cert notAfter 過了、所有 client 突然連不上。

緩解：

• 監控 cert 過期時間、提前 30 天告警、提前 7 天緊急告警
• 用自動續發機制（cert-manager / step-ca / ACME）
• 過期防護應由系統監控與自動續發承擔，而不是依賴人工記憶

失敗 3：私鑰權限過寬、被同機其他 user 讀走

症狀：security audit 發現 /etc/ssl/private/server.key 是 644、所有 user 可讀。

緩解：

• Private key 一律 chmod 600、owner root 或 application user
• 用 systemd 跑的 service、private key 放 LoadCredential= 而非 file path
• 定期 audit /etc/ssl/ 權限

失敗 4：撤銷後 cert 仍能用

症狀：cert 撤銷了、但 client 還能連上。

根因：

• CRL 設定但 server 沒 enable CRL check
• OCSP 設定但 client 沒 query
• 用 short-lived cert 但 TTL 太長、撤銷窗不可接受

緩解：撤銷機制要端到端測試、不只「設定上有」、要驗證「實際生效」。

失敗 5：Service mesh upgrade 後 mTLS 中斷

症狀：Istio 升級後、cluster 內部分 service 互相連不上。

根因：mesh control plane 的 CA 換了、舊 cert chain 不通。

緩解：

• Mesh upgrade 走 staged rollout，分批驗證 cert chain
• Mesh 提供的 CA migration 流程要完整執行
• Staging 環境先跑升級流程

收尾

mTLS 是「用 PKI 換掉 secret 管理」的設計 — 私鑰不離 client、身分綁在 X.509 cert 上、不依賴可重用的字串。安全等級高、但代價是要建立 CA infrastructure、處理 cert 生命週期、整合到各種基礎設施。

幾個核心判斷：

1. CA 分層是基本盤 — Root + Intermediate + Leaf，讓最高信任根維持低暴露
2. 私鑰留在產生端 — CA 只簽 CSR、不碰 private key
3. 撤銷方案要實證可用 — CRL / OCSP / Short-lived 三選一，並驗證實際生效
4. Service mesh 是 cloud-native 的低成本入口 — Istio / Linkerd 把 mTLS 變成基礎設施，application 改動較小
5. mTLS 是高責任方案 — 對外開放 API、小規模、無 mesh 場景，OAuth / API Key 往往更容易維運

延伸閱讀：

• API 認證的三層信任邊界 — 本文的主篇、mTLS 在「Layer 2 系統層」的位置
• Shared Secret 安全輪替設計 — 不用 mTLS 走 secret-based 認證的對應 lifecycle 問題
• Laravel Sanctum 的 Bearer Token 設計剖析 — Layer 1 使用者層的 token 機制、跟 mTLS 解的問題不同