mTLS 双向认证实战：为微服务通信加上客户端证书校验

在微服务架构中，服务之间的通信安全至关重要。传统的 TLS 单向认证只能保证客户端验证服务端的身份，但服务端无法确认客户端的合法性。这在零信任安全模型下显然不够——任何能访问网络的人都可以向你的服务发起请求。mTLS（Mutual TLS）双向认证正是为解决这一问题而生。

什么是 mTLS

TLS 握手过程中，通常只有客户端验证服务端证书。而 mTLS 要求双方都出示证书并互相验证：

• 服务端：向客户端出示证书，证明自己的身份
• 客户端：也向服务端出示证书，证明自己是受信任的调用方
• 双向校验：只有双方证书都通过验证，加密通道才建立成功

这意味着即使攻击者能连通服务端口，没有合法客户端证书也无法完成握手，更无法发送任何业务请求。

证书体系设计

在动手之前，先规划好证书层级。推荐使用一套简单的 PKI 结构：

Root CA（根证书，离线保存）
├── Server Certificate（服务端证书，CN=orders.svc.local）
└── Client Certificate（客户端证书，CN=payment-client）

关键原则：

1. 根 CA 私钥绝不放在业务服务器上，只用于签发下级证书
2. 服务端和客户端使用不同的证书，便于独立吊销
3. 证书的 SAN（Subject Alternative Name）必须包含实际使用的域名或服务名
4. 为微服务场景设置合理的有效期，建议 90 天到 1 年，配合自动轮换

使用 OpenSSL 生成证书

以下命令快速搭建一套测试用证书链。

生成根 CA：

openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/CN=MyInternalCA/O=MyOrg"

生成服务端证书：

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr \
  -subj "/CN=orders.svc.local/O=MyOrg"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365 \
  -extfile <(printf "subjectAltName=DNS:orders.svc.local,DNS:localhost,IP:127.0.0.1")

生成客户端证书：

openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr \
  -subj "/CN=payment-client/O=MyOrg"
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out client.crt -days 365 \
  -extfile <(printf "extendedKeyUsage=clientAuth")

注意客户端证书的 extendedKeyUsage=clientAuth，服务端证书应为 serverAuth，这是区分用途的关键扩展字段。

Nginx 配置服务端 mTLS

如果微服务前面有 Nginx 作为入口网关，配置如下：

server {
    listen 443 ssl;
    server_name orders.svc.local;

    ssl_certificate     /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;

    # 开启客户端证书校验
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    location / {
        # 将客户端证书信息传递给后端
        proxy_set_header X-Client-CN $ssl_client_s_dn_cn;
        proxy_set_header X-Client-Verify $ssl_client_verify;
        proxy_pass http://orders-backend;
    }
}

ssl_verify_client on 是核心指令，表示强制校验客户端证书。如果设为 optional，则允许无证书连接，但会标记验证状态——适合灰度迁移阶段。

Go 服务端实现

对于直接用 Go 编写的微服务，标准库 crypto/tls 原生支持 mTLS：

package main

import (
    "crypto/tls"
    "crypto/x509"
    "log"
    "net/http"
    "os"
)

func main() {
    // 加载 CA 证书池，用于验证客户端证书
    caCert, err := os.ReadFile("/etc/certs/ca.crt")
    if err != nil {
        log.Fatal(err)
    }
    caPool := x509.NewCertPool()
    caPool.AppendCertsFromPEM(caCert)

    tlsConfig := &tls.Config{
        ClientCAs:  caPool,
        ClientAuth: tls.RequireAndVerifyClientCert,
        MinVersion: tls.VersionTLS12,
    }

    server := &http.Server{
        Addr:      ":8443",
        TLSConfig: tlsConfig,
        Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            // 从证书中提取客户端身份
            if len(r.TLS.PeerCertificates) > 0 {
                cn := r.TLS.PeerCertificates[0].Subject.CommonName
                w.Write([]byte("Hello, " + cn))
            }
        }),
    }

    log.Fatal(server.ListenAndServeTLS(
        "/etc/certs/server.crt",
        "/etc/certs/server.key",
    ))
}

tls.RequireAndVerifyClientCert 确保每个连接都必须携带有效客户端证书，且证书链能被 ClientCAs 验证通过。

客户端调用示例

Go 客户端发起 mTLS 请求：

cert, _ := tls.LoadX509KeyPair("/etc/certs/client.crt", "/etc/certs/client.key")
caCert, _ := os.ReadFile("/etc/certs/ca.crt")
caPool := x509.NewCertPool()
caPool.AppendCertsFromPEM(caCert)

client := &http.Client{
    Transport: &http.Transport{
        TLSClientConfig: &tls.Config{
            Certificates: []tls.Certificate{cert},
            RootCAs:      caPool,
        },
    },
}

resp, err := client.Get("https://orders.svc.local:8443/")

如果使用 curl 调试：

curl --cert client.crt --key client.key --cacert ca.crt \
  https://orders.svc.local:8443/

在 Kubernetes 中的实践

Kubernetes 生态中，推荐使用 cert-manager 自动管理证书生命周期。定义 Certificate 资源即可自动签发和续期：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: payment-client-cert
spec:
  secretName: payment-client-tls
  duration: 2160h    # 90 天
  renewBefore: 360h  # 提前 15 天续期
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer
  commonName: payment-client
  usages:
    - client auth

服务间通信如果使用 Istio 或 Linkerd，它们默认就启用了 mTLS，无需手动配置证书，但理解底层原理对于排查问题和设计安全策略仍然必要。

常见坑与注意事项

• 证书链不完整：客户端或服务端只提供叶子证书，缺少中间 CA，导致对方验证失败。确保 fullchain 正确拼接。
• CN 与 SAN 混淆：现代 TLS 库已不再依赖 CN 做主机名验证，必须在 SAN 中写入正确域名。
• 时间不同步：证书验证依赖系统时间，容器时间漂移会导致验证失败。确保 NTP 同步。
• 吊销机制缺失：mTLS 本身不处理吊销。生产环境应结合 CRL 或 OCSP，或使用短有效期证书降低风险。
• 性能开销：mTLS 握手比单向 TLS 多一次证书验证，高频短连接场景建议启用会话复用（session resumption）。

总结

mTLS 为微服务通信提供了一种强身份保证：不仅加密传输内容，还确保通信双方都是受信任的实体。实施路径可以概括为——设计好 CA 层级、为每个服务签发独立证书、在服务端开启强制校验、在客户端正确加载证书、最后用 cert-manager 等工具实现自动化轮换。掌握这套机制后，你的微服务架构在零信任方向上就迈出了扎实的一步。

未经允许不得转载：任鹏个人博客 » mTLS 双向认证实战：为微服务通信加上客户端证书校验