跟 GoReplay 比、Service Mesh Mirroring 在 proxy / sidecar 層、是 K8s mesh-native 的 L7 HTTP request mirror、不需要 application 或 host 端 capture binary；GoReplay 在 application host 層、適合無 mesh 的環境或要 capture artifact 離線 replay。跟 AWS VPC Traffic Mirroring 比、Service Mesh Mirroring 在 L7（HTTP route / header / subset 可控）、VPC Traffic Mirroring 在 L3-L4 packet 層、見度更底層但缺 application 語意。三者組合常見於 K8s + 多 cloud 混合環境。

最短判讀路徑

判斷 Service Mesh Mirroring 部署是否健康、最少看四件事：

• Mesh implementation 對齊：用哪套 mesh（Istio / Linkerd / Envoy gateway / Consul Connect）、control plane 版本、sidecar injection coverage、跨 namespace policy 邊界是否清楚
• VirtualService mirror config：mirror destination 是否限制在同 namespace / 同 cluster、mirror_percent 是否從 1% 漸進、route / header filter 是否排除 write-heavy 或 PII path
• Target service capacity：shadow target deployment 是否有獨立 HPA、跟 primary 同 node pool 還是隔離、DB / cache / external API 是否導 mock 或 sandbox、不會 share connection pool 造成 primary 飽和
• Response handling：mirrored response 是 fire-and-forget（Istio 預設）還是有 logging、shadow 端是否能辨識 mirrored request（X-Envoy-Internal / custom header）、side effect（payment / notification / webhook）是否走 dry-run

四件事任一缺失、就是 9.10 Production-Side 驗證 shadow traffic 治理的待補項目。

定位

Service mesh mirroring 適合平台已經有 proxy control plane 的團隊。當 service-to-service traffic 都經過 sidecar 或 gateway，mirror policy 可以把部分 production request 複製到新版本，不需要在 application code 中加 capture / replay 邏輯。

這個定位讓 service mesh mirroring 接到 9.10 Production-Side 驗證 的 shadow traffic 與 canary perf check。它比 host capture 更貼近 service routing，但也依賴 mesh 的觀測、policy、資源隔離與治理能力。

適用場景

新版本 shadow validation 適合 service mesh mirroring。平台可以把 1%、5% 或特定 route 的流量 mirror 到 shadow deployment，觀察新版本 CPU、memory、latency、DB read 與 error。

Service-to-service migration 適合 service mesh mirroring。當下游服務準備換 runtime、framework、DB client 或 cache client，mirror 可以讓新路徑吃到 production upstream pattern。

多 region / 多 version 對照適合 service mesh mirroring。Mesh policy 能按 namespace、host、route、header 或 subset 控制 mirror target，讓平台在小 blast radius 下收集 production-shaped evidence。

選型判準

Proxy 層控制價值來自一致性。當所有 service 都走 mesh，mirror policy 可以用同一套控制面管理，避免每個 application 自行實作 replay。

Mesh observability 價值來自對照能力。Shadow service 的 latency、error、resource saturation 與 dependency call 可以直接跟 primary path 對比，但 dashboard 要清楚標記 mirrored traffic，避免混入正式 SLO。

跟其他方式的取捨

Service mesh mirroring 和 GoReplay 的主要差異是控制面。Service mesh mirroring 依賴既有 proxy / mesh，適合服務間流量；GoReplay 適合 HTTP capture artifact、離線 replay 與沒有 mesh 的環境。

Service mesh mirroring 和 AWS VPC Traffic Mirroring 的主要差異是語意層級。Mesh 在 L7 routing 層，能按 route、host、header 與 subset 控制；VPC mirroring 在網路層，能見度更底層但應用語意控制較少。

Service mesh mirroring 和 canary 的主要差異是使用者影響。Mirrored request 的回應不回給使用者，適合 capacity / correctness observation；canary 會讓真實使用者走新版本，適合最終放量。

操作成本

Service mesh mirroring 的主要成本是下游容量。Shadow traffic 雖然不回應使用者，但仍會消耗 shadow service、DB、cache、third-party mock、queue 與 observability pipeline 的資源。

Policy 成本來自控制面治理。Mirror rule、route、subset、namespace、owner 與 rollout window 都要可審查；錯誤的 mirror policy 可能把過大比例流量導到未準備好的 target。

Side effect 成本來自 application 行為。Shadow service 要能辨識 mirrored request，並把 write、external API call、notification、payment 與 queue publish 導到 sandbox、mock 或 dry-run。

Evidence Package

Service mesh mirroring 結果應回寫到 evidence package。最小欄位包括 mesh policy version、source service、route、mirror ratio、target subset、time range、shadow target resource、data / side effect isolation、p95 / p99、error rate、dependency saturation、known gap 與 owner。

Evidence package 的核心用途是讓 mirror 實驗可關閉。Reviewer 要能看到 mirror policy 何時啟動、何時停止、覆蓋哪些 route、消耗哪些下游資源，以及 shadow target 是否接近 production。

進階主題

Istio VirtualService mirror / mirror_percent：Istio 用 VirtualService 的 mirror 欄位指定 shadow destination、mirrorPercentage（v1.7+；舊版 mirror_percent）控制比例。production 操作慣例是從 1% 起步、每 30-60min 觀察 shadow target latency / error / saturation 再放大、達到 100% 後維持一週收 evidence 才 promote。route-level config 比 mesh-wide policy 安全、blast radius 限定在指定 host / path。

Linkerd traffic split：Linkerd 用 SMI TrafficSplit CRD 或 native HTTPRoute 分流、走 active-active shadow 模式而非 fire-and-forget。Linkerd mirror 預設較輕量、proxy overhead 比 Istio 低、適合資源敏感的 K8s cluster；但 L7 policy 表達力不如 Istio EnvoyFilter。

Envoy MirrorPolicy：直接寫 Envoy config（不透過 Istio control plane）時、route.RouteAction.request_mirror_policies 是底層 primitive。多 cluster 邊緣 gateway（Contour / Emissary-Ingress / Gloo）都是這層的 abstraction、適合不想引入 full Istio 但要 mirror 能力的場景。

跟 Argo Rollouts canary 整合 — shadow deployment：Argo Rollouts 的 analysis step 可以接 mesh mirror — shadow stage 先用 mirror 收 evidence、canary stage 才放真實流量。對應 9.10 Production-Side 驗證 的「shadow 先於 canary」原則、避免把使用者當小白鼠。

跟 Datadog APM trace correlation：mirrored request 應該有獨立的 trace tag（env:shadow 或 traffic.mirror:true）、讓 Datadog APM / observability stack 能 filter 出 shadow path 的 p95 / error rate、不混入 primary SLO dashboard。trace propagation header 要保留、否則 distributed trace 斷在 mesh 邊界。

排錯與失敗快速判讀

• Mirror target capacity 不足 / shadow service OOM：shadow deployment 沒獨立 HPA、跟 primary 共用 node pool — 拆 node pool、shadow 設獨立 resource request、mirror_percent 從 1% 起步
• Mirrored response 漏處理（fire-and-forget 副作用）：Istio 預設丟棄 mirrored response、shadow 端的 error 沒被 collect — shadow service 自己 emit metric / log、不依賴 mirror response、加 X-Shadow-Request header 讓 shadow 端可辨識並走 dry-run 路徑
• PII / sensitive data 進 staging：mirrored request 帶真實 user token / payment info 打到 staging — header / body filter 走 EnvoyFilter 做 PII redaction、或在 mesh 邊界跑 data masking proxy 再 mirror
• Side effect 真的發生（payment double charge / notification 真寄）：shadow service 沒辨識 mirrored request 就走正式邏輯 — 強制 shadow 端用 sandbox credential、external API client 走 mock / dry-run mode、write 改 read-only replica
• Mesh control plane 飽和 / mirror policy drift：mirror rule 散落各 namespace 沒 owner、policy version 不一致 — 走 GitOps（Argo CD / Flux）+ policy as code、定期 audit kubectl get virtualservice -A
• Cross-cluster mirror blast radius 失控：mirror destination 指向其他 cluster 導致跨 cluster 流量爆增 — mirror destination 限 same-cluster、跨 cluster 要走獨立的 gateway 並設 quota
• Shadow trace 混進 SLO dashboard：APM 沒分 primary / shadow tag、p95 看起來變差但其實是 shadow 拖累 — trace tag env:shadow 強制、observability dashboard filter

何時改走其他服務

不在本頁內的主題

• Istio / Linkerd / Envoy 完整 install / 升級 / control plane HA 細節
• Service mesh 安全模型（mTLS / SPIFFE / authorization policy）— 屬 7 security 邊界
• Mesh-level retry / timeout / circuit breaker 等 resilience pattern
• Multi-cluster mesh federation（Istio multi-primary、Linkerd multicluster）

案例回寫

Service mesh mirroring 適合回寫平台遷移與新版本 shadow validation 案例。它可接 Miro managed EKS migration、Tradeshift self-managed K8s to EKS、9.C28 FanDuel 雙峰 workload 的逐步驗證需求、9.C12 Riot Games 246 EKS cluster 的 single-tenant per game 跨 cluster 流量 shadow，以及 9.C7 Lyft 100+ 微服務 跨服務的 mirror 範圍治理。

這些案例的重點是 routing policy 與 blast radius。Service mesh mirroring 頁引用案例時，要把 case 轉成 route、mirror ratio、target subset、dependency isolation 與 abort condition — 例如 Riot Games 的 single-tenant 模式下、mirror policy 必須限制在 同遊戲 cluster 內、不能跨 game 否則 blast radius 失控。

下一步路由

• 上游：9.10 Production-Side 驗證
• 上游：5.6 Traffic, Config and Control Plane Boundary
• 平行：GoReplay
• 平行：AWS VPC Traffic Mirroring
• 知識卡：Shadow Traffic

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 解的問題不同