如何在微服务架构中实现服务间调用的 mTLS 双向认证？

在微服务架构中，实现服务间 mTLS 双向认证最推荐通过服务网格（Service Mesh）如 Istio 自动接管，若无法引入网格，则需在应用层集成 SDK 或通过 Ingress 网关统一处理。无论哪种方案，核心都在于证书生命周期管理和身份识别。

先说结论：生产环境优先选用服务网格方案以降低侵入性，若自建需严格管理证书轮换。

先判断：评估是否必须全链路加密，确认现有架构是否支持 Sidecar 模式或应用改造。
优先做：部署证书管理机构（CA）并配置自动轮换策略，避免手动维护证书过期风险。
再验证：通过抓包或日志确认握手成功，并测试证书失效后的拒绝访问策略。
防风险：切勿直接开启 STRICT 模式，需先在 PERMISSIVE 模式下观察日志至少 24 小时。

方案选型与核心风险

mTLS 涉及复杂的证书分发，没有单一命令可完成，建议按以下路径选择：

1. Kubernetes + 无侵入：启用 Istio PeerAuthentication 策略，将模式设为 STRICT。

2. 无法使用网格：在网关层（如 Nginx Ingress）配置 client_certificate 验证，内部服务暂用单向 TLS。

3. 应用层控制：引入 gRPC 或 Spring Cloud Security 的 mTLS 支持，需修改代码加载证书。

风险提示：传统单向 TLS 只验证服务器身份，客户端无法确认服务端是否可信。mTLS 要求通信双方都持有合法证书。在微服务中，服务实例动态变化，手动管理证书不可行，必须自动化解决证书颁发、分发和轮换问题。

实操案例一：基于 Istio 服务网格（推荐）

若已使用 Kubernetes 且希望无侵入，Istio 是最优解。它内置了 Citadel 组件自动完成证书管理。

步骤 1：配置 PeerAuthentication 策略

创建以下 YAML 文件，先设置为 PERMISSIVE 模式运行一段时间，观察日志是否有握手失败。确认无误后，切换为 STRICT 模式。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: PERMISSIVE  # 初始阶段使用 PERMISSIVE，稳定后改为 STRICT

步骤 2：身份绑定与验证

确保证书中的 SAN（Subject Alternative Name）字段与服务账户或域名匹配。若使用 Istio，执行 istioctl analyze 查看配置冲突，或通过 Kiali 面板观察流量是否标记为 mTLS。

实操案例二：基于 Spring Boot 应用层集成

若需应用层控制，需自行管理证书并在代码中加载。以下是自建 CA 及 Spring Boot 配置的核心步骤。

步骤 1：使用 OpenSSL 生成 CA 和证书

自建 CA 步骤复杂，不能一笔带过。以下是生成根证书和服务器证书的核心命令：

# 1. 生成根证书私钥
openssl genrsa -out ca.key 2048
# 2. 生成根证书
openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt
# 3. 生成服务私钥
openssl genrsa -out server.key 2048
# 4. 生成证书签名请求 (注意 CN 和 SAN 需匹配服务域名)
openssl req -new -key server.key -out server.csr
# 5. 使用 CA 签发证书
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256

步骤 2：Spring Boot 配置 mTLS

在 application.yml 中配置 SSL 上下文，指定密钥库和信任库：

server:
  ssl:
    enabled: true
    client-auth: need  # 开启双向认证
    key-store: classpath:certs/server.p12
    key-store-password: changeit
    trust-store: classpath:certs/truststore.p12
    trust-store-password: changeit

验证与排查

配置完成后，必须通过命令行验证是否生效。

1. 命令行测试

在服务 pod 内或客户端机器使用 curl 测试。不带证书应被拒绝，带合法证书应返回 200 或握手成功。

# 失败案例：不带证书
curl -v https://target-service
# 预期：SSL handshake failure 或 400 Bad Request

# 成功案例：携带证书
curl -v `--cert` client.crt `--key` client.key `--cacert` ca.crt https://target-service
# 预期：HTTP/2 200 或 TLS handshake 成功

2. 日志审计

检查服务端访问日志，确认 TLS 握手版本及 cipher suite，查看是否有因证书验证失败产生的 400 或 503 错误。

常见坑与运维建议

1. DNS 解析不匹配：证书中的 SAN 必须与实际调用的域名一致，否则客户端会报错 hostname mismatch。

2. 证书过期导致雪崩：若自动轮换机制失效，大量服务同时过期会导致集群不可用，务必配置告警监控证书有效期。

3. 性能损耗：mTLS 握手会增加 CPU 消耗和延迟，虽然现代硬件影响较小，但在高频调用场景下需关注 Sidecar 资源限制。

4. 遗留系统兼容：无法改造的老服务可能不支持 TLS，需通过网关代理转换，避免直接阻断业务。

5. 模式切换风险：从 PERMISSIVE 切换到 STRICT 前，务必确认监控中无 TLS 握手错误激增，建议分批次灰度切换。