ALB 掛在 public subnet、引用專屬的 security group，security group 的入站通常只開 80 和 443 對 0.0.0.0/0（這是少數合理出現全開的位置，因為 ALB 的工作本來就是接收公開流量）。後端運算節點住在 private subnet，它們的 security group 入站只允許來自 ALB security group 的流量 — 這個 group-to-group 引用讓規則跟著成員身分走，不跟著 IP 走（見模組三：網路地基）。

ALB 與 listener 設定

ALB 資源本身描述的是它掛在哪些 subnet、用哪個 security group、是對外（internal = false）還是內部。Listener 則是掛在 ALB 上的監聽端點，每個 listener 綁定一個 port + protocol 的組合。

1resource "aws_lb" "api" {
2  name               = "api-${var.env}"
3  internal           = false
4  load_balancer_type = "application"
5  security_groups    = [aws_security_group.alb.id]
6  subnets            = [for s in aws_subnet.public : s.id]
7}

HTTP 到 HTTPS 的強制跳轉

正式服務通常同時建兩個 listener：port 443 接受 HTTPS 流量並轉發到後端，port 80 接收 HTTP 流量後直接回一個 301 redirect 到 HTTPS — 確保使用者即使用 http:// 開頭訪問也會被導到加密連線。

 1resource "aws_lb_listener" "https" {
 2  load_balancer_arn = aws_lb.api.arn
 3  port              = 443
 4  protocol          = "HTTPS"
 5  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
 6  certificate_arn   = aws_acm_certificate.api.arn
 7
 8  default_action {
 9    type             = "forward"
10    target_group_arn = aws_lb_target_group.api.arn
11  }
12}
13
14resource "aws_lb_listener" "http_redirect" {
15  load_balancer_arn = aws_lb.api.arn
16  port              = 80
17  protocol          = "HTTP"
18
19  default_action {
20    type = "redirect"
21    redirect {
22      port        = "443"
23      protocol    = "HTTPS"
24      status_code = "HTTP_301"
25    }
26  }
27}

ssl_policy 決定 ALB 接受哪些 TLS 版本與密碼套件。選擇以安全與相容性為取捨 — ELBSecurityPolicy-TLS13-1-2-2021-06 只接受 TLS 1.2 和 1.3，能阻擋過時協定的降級攻擊，但會拒絕仍在使用 TLS 1.0/1.1 的極舊用戶端。對面向公眾的 API 或網站，TLS 1.2 以上是合理的底線；如果有明確的舊用戶端需求（例如嵌入式設備），再往下調但要知道代價。

多服務共用 ALB

一個 ALB 可以掛多個 listener rule，用 host header 或 path 把流量分到不同的 target group。這讓多個微服務共用一個 ALB（省成本），而不需要每個服務各開一個：

 1resource "aws_lb_listener_rule" "auth" {
 2  listener_arn = aws_lb_listener.https.arn
 3  priority     = 10
 4
 5  condition {
 6    path_pattern { values = ["/auth/*"] }
 7  }
 8
 9  action {
10    type             = "forward"
11    target_group_arn = aws_lb_target_group.auth.arn
12  }
13}

一個常見的收斂機會：如果每個服務都各自開了一個 ALB，但流量都從同一個入口進來、只是路徑不同，可以收斂成一個 ALB 加 listener rule。每個 ALB 有固定的小時費，少開幾個月費就少幾筆。反過來，當不同服務的安全等級或流量特性差異大到需要獨立的 security group 和 WAF 規則時，分開 ALB 才合理。

target group 與健康檢查

Target group 定義一組接收流量的後端（ECS task、EC2 instance 或 IP），以及判斷這些後端是否健康的檢查邏輯。它是 ALB 和實際運算之間的橋樑。

 1resource "aws_lb_target_group" "api" {
 2  name        = "api-${var.env}-tg"
 3  port        = 8080
 4  protocol    = "HTTP"
 5  vpc_id      = aws_vpc.main.id
 6  target_type = "ip"
 7
 8  health_check {
 9    path                = "/healthz"
10    interval            = 15
11    healthy_threshold   = 2
12    unhealthy_threshold = 3
13    timeout             = 5
14    matcher             = "200"
15  }
16}

健康檢查的閾值設計

健康檢查的路徑與閾值是最常被忽略的判讀點。各參數之間的交互作用決定了兩個時間窗口：新後端多久後開始接流量、壞後端多久後被移出。

healthy_threshold = 2 配 interval = 15 代表一個新啟動的後端要等 30 秒（兩次通過）才開始接流量。unhealthy_threshold = 3 代表連續三次失敗（45 秒）才被移出。閾值太寬鬆會把壞掉的後端留在輪替裡，讓部分使用者持續收到錯誤；太嚴格會在部署瞬間 — 新容器啟動、應用還在初始化 — 就判定不健康，反覆移出移入，使用者看到間歇性失敗。

健康檢查路徑的選擇

path 指向的端點應該能反映應用是否確實能服務請求，而不只是 process 還活著。一個只回 200 的空端點（所謂 liveness check）證明 HTTP server 在跑，但不代表它能連到資料庫、能讀到必要的 config。較合理的做法是讓 /healthz 至少檢查核心依賴的連線（例如 ping 一下 DB），失敗時回 503。代價是健康檢查會跟著核心依賴一起報不健康 — 如果 DB 暫時斷了，所有後端都會被判定不健康，ALB 會回 503 給使用者。這是正確的行為：如果應用確實無法服務請求，把它標成不健康比假裝健康好。

判讀方式：部署後觀察 target group 裡的 healthy / unhealthy 轉換次數。如果每次部署都看到新 target 在 healthy 與 unhealthy 之間跳動，代表初始等待不夠 — 應用的啟動時間超出 healthy_threshold * interval，考慮加大 healthy_threshold 或設定 ECS 的 startPeriod（啟動寬限期）讓健康檢查在應用初始化期間暫停。

TLS 憑證：ACM 簽發、DNS 驗證與自動續期

HTTPS listener 引用的 TLS 憑證也屬於 ALB 的接線。用 ACM（AWS Certificate Manager）簽發的憑證在 IaC 裡完整描述 — 涵蓋網域與 DNS 驗證方式 — 讓「憑證存在、驗證、掛載」整條鏈都進版本控制，而非在 Console 手動上傳一份會過期沒人盯的憑證。

ACM 簽發的憑證使用 DNS 驗證時，ACM 要求在指定的 DNS 記錄上放一段驗證值。Terraform 可以自動建立這段記錄並等待驗證通過：

 1resource "aws_acm_certificate" "api" {
 2  domain_name       = "api.${var.domain}"
 3  validation_method = "DNS"
 4
 5  lifecycle { create_before_destroy = true }
 6}
 7
 8resource "aws_route53_record" "cert_validation" {
 9  for_each = {
10    for dvo in aws_acm_certificate.api.domain_validation_options : dvo.domain_name => dvo
11  }
12  zone_id = data.aws_route53_zone.main.zone_id
13  name    = each.value.resource_record_name
14  type    = each.value.resource_record_type
15  records = [each.value.resource_record_value]
16  ttl     = 60
17}
18
19resource "aws_acm_certificate_validation" "api" {
20  certificate_arn         = aws_acm_certificate.api.arn
21  validation_record_fqdns = [for r in aws_route53_record.cert_validation : r.fqdn]
22}

create_before_destroy 的必要性

create_before_destroy = true 確保憑證更新（例如加 SAN 或續期觸發重建）時先建新的再刪舊的，避免 listener 在交接期間沒有可用憑證。Terraform 預設行為是先刪後建，會造成一個短暫的 HTTPS 中斷窗口 — listener 找不到憑證、所有 HTTPS 連線失敗直到新憑證簽發並驗證完畢。

ACM 簽發的憑證自動續期：只要 DNS 驗證記錄還在（由 Terraform 管理，所以會一直在），ACM 在到期前 60 天自動續期。這是把憑證管理成本降到接近零的做法 — 不需要排程提醒、不需要手動下載上傳。判讀訊號：如果 CloudWatch 出現 DaysToExpiry 降到 30 以下的 alarm，代表自動續期失敗，通常是 DNS 驗證記錄被手動刪了或 Route 53 zone 變了。

多網域憑證（SAN）

一張 ACM 憑證可以涵蓋多個網域（Subject Alternative Names），例如 api.example.com 和 admin.example.com 共用一張。在 IaC 裡用 subject_alternative_names 列舉：

1resource "aws_acm_certificate" "multi" {
2  domain_name               = "api.${var.domain}"
3  subject_alternative_names = ["admin.${var.domain}", "*.internal.${var.domain}"]
4  validation_method         = "DNS"
5
6  lifecycle { create_before_destroy = true }
7}

共用一張還是分開簽取決於生命週期：如果這幾個網域總是一起上下線、一起變更，共用一張省維護；如果各自獨立演進，分開簽讓變更範圍更小。

DNS zone 管理與 ALB 的銜接

Hosted zone：DNS 記錄的容器

Route 53 的 hosted zone 是一個網域下所有 DNS 記錄的容器。public hosted zone 管理對外可見的網域（如 example.com），private hosted zone 管理只在 VPC 內可解析的內部網域（如 internal.example.com），讓服務之間用 DNS 名稱互連而不靠 IP。

多環境的 DNS 管理常用子網域 delegation：production 用 example.com（主 zone），dev 和 staging 各用 dev.example.com 和 staging.example.com（子 zone）。子 zone 可以放在不同帳號、由不同團隊管理，主 zone 只需要一組 NS 記錄指向子 zone。這讓環境之間的 DNS 邊界跟帳號邊界對齊。

 1resource "aws_route53_zone" "main" {
 2  name = var.domain
 3}
 4
 5resource "aws_route53_zone" "staging" {
 6  name = "staging.${var.domain}"
 7}
 8
 9resource "aws_route53_record" "staging_ns" {
10  zone_id = aws_route53_zone.main.zone_id
11  name    = "staging.${var.domain}"
12  type    = "NS"
13  ttl     = 300
14  records = aws_route53_zone.staging.name_servers
15}

hosted zone 也是 ACM 憑證 DNS 驗證的依賴 — ACM 簽發憑證時需要在對應的 zone 寫入一條驗證記錄，zone 不存在或不在同帳號就接不上。把 zone 的建立排在 ACM 之前，讓依賴圖自然正確。

ALB 的穩定 DNS 記錄

ALB 重建後 DNS 名稱會改變。穩定對外的方式是在 Route 53 建一條 alias 記錄指向 ALB，使用者連的是 api.example.com，DNS 自動解析到 ALB 目前的位址：

 1resource "aws_route53_record" "api" {
 2  zone_id = data.aws_route53_zone.main.zone_id
 3  name    = "api.${var.domain}"
 4  type    = "A"
 5
 6  alias {
 7    name                   = aws_lb.api.dns_name
 8    zone_id                = aws_lb.api.zone_id
 9    evaluate_target_health = true
10  }
11}

evaluate_target_health = true 讓 Route 53 在 ALB 所有 target 都不健康時把這條記錄標為不健康。如果有多個 region 的 ALB 做了 failover routing，這個設定能讓 DNS 層自動切換到健康的 region — 屬於跨區域容災的地基，在 devops 模組展開。

WAF 與下一步

ALB 支援掛載 AWS WAF（Web Application Firewall），在流量進到應用之前先過一層規則 — 擋已知惡意 IP、防 SQL injection / XSS 的常見模式、限制單一 IP 的請求速率。WAF 的規則也可以寫進 IaC，讓「哪些流量被擋」成為可審查的程式碼而非 Console 上的設定。WAF 的詳細設計屬於安全層的範圍（見 backend 模組七：資安與資料保護），這裡只確認它的掛載點是 ALB。

四類核心服務的 IaC 描述到此完成。下一步是讓這些服務可被觀測——log、metric、alarm 跟資源同生命週期建立，見模組六：可觀測性與 log。

跨分類引用

• → 模組三：網路地基：ALB 的 security group 設計，group-to-group 引用
• → 模組五：stateful 資源的保護策略：ALB 是 stateless，但它引用的 ACM 憑證和 DNS 記錄有自己的生命週期考量
• → devops 模組一：負載平衡：ALB 的運行期調校 — 跨 AZ 流量分配、connection draining、sticky session
• → backend 模組七：資安與資料保護：WAF 規則設計

Route 53 Hosted Zone

Hosted zone 是 Route 53 用來管理某個網域的 DNS 記錄集合。建立 zone 後，Route 53 會分配一組 NS（Name Server）記錄，網域的 DNS 解析就由這組 NS 負責。

Public vs Private Zone

Public hosted zone 對應的是可從網際網路解析的網域（如 example.com），用於對外服務的 A / CNAME / MX 記錄。Private hosted zone 只在指定的 VPC 內可解析，用於內部服務發現（如 db.internal.example.com 解析到 RDS 的 private IP）。多數專案兩者都需要：public zone 給對外流量、private zone 給內部服務互連。

 1resource "aws_route53_zone" "public" {
 2  name = "example.com"
 3  tags = { Environment = "production" }
 4}
 5
 6resource "aws_route53_zone" "private" {
 7  name = "internal.example.com"
 8
 9  vpc {
10    vpc_id = aws_vpc.main.id
11  }
12
13  tags = { Environment = "production" }
14}

子網域 delegation

當 dev / staging / prod 各用獨立帳號時，每個帳號建自己的 hosted zone 管理子網域（如 dev.example.com）。父網域的 zone 需要加一組 NS 記錄指向子網域的 zone，這個動作叫 delegation。

1resource "aws_route53_record" "dev_ns" {
2  zone_id = aws_route53_zone.public.zone_id
3  name    = "dev.example.com"
4  type    = "NS"
5  ttl     = 300
6  records = aws_route53_zone.dev.name_servers
7}

delegation 的 NS 記錄指向子帳號 zone 的 name server。子帳號內的所有 DNS 記錄（如 api.dev.example.com）由子帳號的 zone 管理，父帳號不需要逐條設定。跨帳號 delegation 需要兩邊的 Terraform 各自管理自己的 zone，NS 記錄在父帳號的 state 裡。

判讀設定是否正確：用 dig dev.example.com NS 查回的 name server 應該是子帳號 zone 的 NS，不是父帳號的。如果查回父帳號的 NS，代表 delegation 沒生效，子網域的 DNS 記錄不會被解析。

ACM 憑證申請與 DNS 驗證

AWS Certificate Manager（ACM）提供免費的 TLS 憑證，條件是透過 DNS 或 email 驗證網域所有權。DNS 驗證是 IaC 友善的方式——ACM 要求在指定網域下建一條 CNAME 記錄，記錄值由 ACM 提供，驗證通過後憑證自動簽發。

 1resource "aws_acm_certificate" "main" {
 2  domain_name               = "example.com"
 3  subject_alternative_names = ["*.example.com"]
 4  validation_method         = "DNS"
 5
 6  lifecycle {
 7    create_before_destroy = true
 8  }
 9
10  tags = { Environment = "production" }
11}

subject_alternative_names 加 *.example.com 讓同一張憑證涵蓋所有子網域（如 api.example.com、admin.example.com），省去為每個子網域各申請一張。

DNS 驗證記錄

ACM 簽發後會產出一組驗證用的 CNAME 記錄。用 Terraform 自動在 Route 53 建立這些記錄，讓驗證流程不需要手動操作：

 1resource "aws_route53_record" "cert_validation" {
 2  for_each = {
 3    for dvo in aws_acm_certificate.main.domain_validation_options : dvo.domain_name => {
 4      name   = dvo.resource_record_name
 5      record = dvo.resource_record_value
 6      type   = dvo.resource_record_type
 7    }
 8  }
 9
10  zone_id = aws_route53_zone.public.zone_id
11  name    = each.value.name
12  type    = each.value.type
13  ttl     = 300
14  records = [each.value.record]
15
16  allow_overwrite = true
17}
18
19resource "aws_acm_certificate_validation" "main" {
20  certificate_arn         = aws_acm_certificate.main.arn
21  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
22}

aws_acm_certificate_validation 資源會等到 ACM 確認驗證通過才算 apply 成功。如果 DNS 記錄設錯或 zone 的 NS delegation 有問題，這個資源會卡住直到 timeout——排查方向是先確認驗證 CNAME 記錄能被公網 DNS 解析。

create_before_destroy

lifecycle { create_before_destroy = true } 在憑證需要替換時（如增加 SAN、更換網域），讓 Terraform 先建新憑證、再刪舊憑證。沒有這個設定，預設行為是先刪後建——刪除的瞬間 ALB listener 失去憑證，HTTPS 連線全部中斷直到新憑證驗證通過（可能要幾分鐘到幾十分鐘）。

ALB HTTPS Listener

憑證驗證通過後，把它掛到 ALB 的 HTTPS listener：

 1resource "aws_lb_listener" "https" {
 2  load_balancer_arn = aws_lb.main.arn
 3  port              = 443
 4  protocol          = "HTTPS"
 5  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
 6  certificate_arn   = aws_acm_certificate_validation.main.certificate_arn
 7
 8  default_action {
 9    type             = "forward"
10    target_group_arn = aws_lb_target_group.app.arn
11  }
12}

ssl_policy 決定 TLS 版本與加密套件。ELBSecurityPolicy-TLS13-1-2-2021-06 支援 TLS 1.2 和 1.3、停用已知不安全的舊版協定。選型判準是相容性與安全性的平衡——TLS 1.3-only policy 最安全但可能排除舊版客戶端，多數場景用 1.2+1.3 的組合。

certificate_arn 引用的是 aws_acm_certificate_validation 而非直接引用 aws_acm_certificate，確保 listener 只在憑證驗證通過後才建立。

HTTP → HTTPS 重導

同時建立一個 HTTP listener，把所有 80 埠流量重導到 443：

 1resource "aws_lb_listener" "http_redirect" {
 2  load_balancer_arn = aws_lb.main.arn
 3  port              = 80
 4  protocol          = "HTTP"
 5
 6  default_action {
 7    type = "redirect"
 8    redirect {
 9      port        = "443"
10      protocol    = "HTTPS"
11      status_code = "HTTP_301"
12    }
13  }
14}

301 永久重導讓瀏覽器記住後續直接走 HTTPS。security group 仍然需要開放 80 埠入站，否則重導不會發生——client 連 80 埠被擋、收到的是連線失敗而非重導回應。

多網域與 SAN 憑證

一張 ACM 憑證最多支援 10 個 SAN（Subject Alternative Name）。多數場景用主網域 + wildcard（example.com + *.example.com）就夠用。如果有多個不同根網域（如 example.com 和 example-app.com），可以加進同一張憑證：

 1resource "aws_acm_certificate" "multi_domain" {
 2  domain_name               = "example.com"
 3  subject_alternative_names = [
 4    "*.example.com",
 5    "example-app.com",
 6    "*.example-app.com",
 7  ]
 8  validation_method = "DNS"
 9
10  lifecycle {
11    create_before_destroy = true
12  }
13}

每個 SAN 網域都需要獨立的 DNS 驗證記錄。如果不同網域在不同的 hosted zone 裡，驗證記錄的建立要分別指向各自的 zone。

當 SAN 數量超過 10、或不同網域的憑證需要獨立管理（不同 team 負責不同網域），改用 aws_lb_listener_certificate 額外掛載：

1resource "aws_lb_listener_certificate" "additional" {
2  listener_arn    = aws_lb_listener.https.arn
3  certificate_arn = aws_acm_certificate.other_domain.arn
4}

ALB 會根據 SNI（Server Name Indication）自動選擇匹配的憑證。

穩定的 DNS 別名記錄

ALB 重建後 DNS 名稱會改變，對外服務不應該直接用 ALB 的 DNS 名稱。用 Route 53 的 alias record 把穩定的網域名指向 ALB：

 1resource "aws_route53_record" "app" {
 2  zone_id = aws_route53_zone.public.zone_id
 3  name    = "api.example.com"
 4  type    = "A"
 5
 6  alias {
 7    name                   = aws_lb.main.dns_name
 8    zone_id                = aws_lb.main.zone_id
 9    evaluate_target_health = true
10  }
11}

alias record 不收費（一般的 A/CNAME 記錄每百萬次查詢 $0.40，alias 到 AWS 資源免費），且支援 zone apex（如 example.com，一般 CNAME 不支援 zone apex）。evaluate_target_health = true 讓 Route 53 在 ALB 不健康時停止回應該記錄，配合 failover routing 使用。

憑證續期監控

ACM 的 DNS 驗證憑證會自動續期——條件是驗證用的 CNAME 記錄仍然存在且可解析。只要那條記錄沒被刪掉，憑證到期前 60 天 ACM 會自動續期。

自動續期失敗的常見原因：驗證 CNAME 記錄被手動刪除、hosted zone 的 NS delegation 失效、或 zone 本身被刪除重建導致 NS 改變。用 CloudWatch alarm 監控憑證到期日，在自動續期失敗時提前收到通知：

 1resource "aws_cloudwatch_metric_alarm" "cert_expiry" {
 2  alarm_name          = "acm-cert-expiry-${aws_acm_certificate.main.domain_name}"
 3  comparison_operator = "LessThanThreshold"
 4  evaluation_periods  = 1
 5  metric_name         = "DaysToExpiry"
 6  namespace           = "AWS/CertificateManager"
 7  period              = 86400
 8  statistic           = "Minimum"
 9  threshold           = 30
10  alarm_actions       = [aws_sns_topic.oncall.arn]
11
12  dimensions = {
13    CertificateArn = aws_acm_certificate.main.arn
14  }
15}

這個 alarm 在憑證距離到期不足 30 天時觸發。正常情況下 ACM 在到期前 60 天就會完成續期，收到 30 天警報代表自動續期失敗了、需要人工介入確認驗證記錄。

跨分類引用

• → 入口上 IaC — ALB：ALB listener、target group、健康檢查的完整設定
• → 模組三：網路地基：ALB 所在的 public subnet 與 security group 設計
• → 模組七：infra 走 PR 流程：憑證與 DNS 變更走 PR review

服務定位

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

本文的判讀錨點是：加密要服務於 threat model。若風險是磁碟遺失，at-rest encryption 是重點；若風險是網路攔截，TLS 是重點；若風險是內部濫用，還需要 role、audit、masking 與 SIEM。

官方文件路由的核心責任是固定 MySQL 8.4 security claim。實作前先查 InnoDB data-at-rest encryption、MySQL keyring 與 SHOW BINARY LOG STATUS；本文最後檢查日是 2026-05-22。

Protection Layers

Protection layers 的核心責任是把保護面分層。

這些層級要一起設計。資料檔加密後，backup 若以明文落到 object storage，保護鏈仍然破洞；TLS 開啟後，client 若允許 insecure fallback，也會失去網路保護。

Keyring Boundary

Keyring boundary 的核心責任是定義 MySQL 如何取得與保護 encryption key。MySQL 支援 keyring component / plugin 與外部 KMS 整合；managed MySQL 可能由 provider 接管 key storage。

Keyring 要進入 backup / restore drill。還原 database 時，只有 data file 而沒有對應 key，restore 會失敗；runbook 要保存 key dependency 與 emergency access。

TLS Policy

TLS policy 的核心責任是讓 client connection、replication connection 與 admin connection 都有明確安全等級。

TLS 驗證要包含 certificate rotation。過期憑證造成的 downtime 很常見；runbook 要記錄 CA、server cert、client cert、rotation window 與 reload / restart 條件。

1SHOW VARIABLES LIKE 'require_secure_transport';
2SHOW STATUS LIKE 'Ssl_cipher';

這些查詢只能提供 connection 層 evidence。正式驗證還要從 client 設定確認 ssl-mode 是否驗證 CA / identity。

Backup and Binlog Encryption

Backup and binlog encryption 的核心責任是保護資料離開 primary 後的生命週期。MySQL backup、binlog、logical dump、object storage、replica seed 都可能含敏感資料。

Restore drill 要確認加密 artifact 可被解密並啟動。只有成功產出 encrypted backup，還不足以證明災難時能恢復。

Rotation Runbook

Rotation runbook 的核心責任是讓 key、certificate、password 都可定期更換。

1. Inventory：列出 DB user、TLS cert、KMS key、backup key。
2. Impact：確認哪些 client / replica / backup job 使用它。
3. Staging：先在 staging 旋轉並跑 smoke test。
4. Rollout：使用雙憑證 / 雙 secret window。
5. Validation：查連線、replication、backup、restore。
6. Cleanup：移除舊 key / cert / secret。

Rotation 要設 calendar 與 owner。安全設定長期無人輪替時，incident 後會難以判斷 exposure window。

Failure Modes

Failure modes 的核心責任是提前列出加密常見事故。

安全 runbook 要和 audit log 串接。Key rotation、failed TLS、privilege change、restore access 都應留下可追溯紀錄。

下一步路由

Encryption / TLS / key management 完成後，操作證據讀 Audit Log + SIEM；備份恢復讀 PITR / Backup；資料保護治理讀 Data Protection。

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