Envoy项目中UpstreamTLSContext客户端证书配置问题解析

2025-05-07 19:58:30作者：殷蕙予

在Envoy代理的实际应用中，配置上游服务的TLS连接是一个常见需求，特别是当上游服务要求客户端证书认证时。本文将深入分析一个典型的配置问题及其解决方案，帮助开发者更好地理解Envoy的TLS工作机制。

问题现象

在使用Envoy的OAuth客户端凭据注入器时，开发者遇到了一个TLS认证问题。配置中虽然指定了客户端证书，但在实际请求上游服务时，Envoy并未正确发送这些证书，导致服务端返回"400 No required SSL certificate was sent"错误。

配置分析

从日志中可以清晰地看到，Envoy成功建立了到上游服务的连接，但在TLS握手阶段未能提供客户端证书。上游服务因此拒绝了请求，返回了HTTP 400状态码。

关键的错误日志显示：

Oauth response body: <html>
<head><title>400 No required SSL certificate was sent</title></head>

根本原因

经过深入分析，发现问题出在UpstreamTLSContext的配置上。虽然配置中正确指定了客户端证书，但缺少了两个关键参数：

auto_host_sni: 控制是否自动设置SNI（Server Name Indication）扩展
auto_sni_san_validation: 控制是否自动验证SAN（Subject Alternative Name）

这两个参数对于现代TLS握手过程至关重要，特别是在需要客户端证书认证的场景中。

解决方案

修正后的配置应包含以下关键部分：

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
    auto_host_sni: true
    auto_sni_san_validation: true
    common_tls_context:
      tls_certificate_sds_secret_configs:
      - name: client_cert
      validation_context:
        trusted_ca:
          filename: /path/to/ca.pem

技术原理

SNI扩展：现代TLS握手过程中，客户端通过SNI扩展告知服务器它正在连接的主机名。这对于服务器选择正确的证书链非常重要。
SAN验证：Subject Alternative Name是X.509证书中的一个扩展，允许证书保护多个主机名。自动验证可以确保连接的主机名与证书中的SAN匹配。
客户端证书流程：当服务器要求客户端证书时，客户端需要在TLS握手期间提供有效的证书链。这个过程依赖于正确的SNI和SAN配置。