Envoy代理升级后自签名证书验证失败问题分析

在Envoy代理从1.27.1版本升级到1.31.3版本后，用户报告了一个关于自签名证书验证失败的问题。当尝试通过TLS连接到使用自签名证书的服务时，Envoy返回了"Certificate Verify Failed"错误，导致连接中断。

问题现象

升级后的Envoy在尝试建立TLS连接时，日志中显示以下错误信息：

"POST /X1/NE HTTP/1.1" 503 URX,UF upstream_reset_before_response_started{remote_connection_failure|TLS_error:|268435581:SSL_routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED:TLS_error_end}

通过openssl工具在容器内测试连接时，也观察到类似的证书验证问题：

depth=2 C = US, ST = Denial, L = Springfield, O = Dis, CN = litest.com
verify error:num=19:self-signed certificate in certificate chain

技术背景

自签名证书是由证书持有者自己签发的证书，而不是由受信任的证书颁发机构(CA)签发的。在TLS握手过程中，客户端需要验证服务器证书的有效性。对于自签名证书，通常需要：

1. 在客户端配置信任该自签名证书
2. 或者禁用严格的证书验证（不推荐用于生产环境）

Envoy作为代理，在建立上游连接时也会执行类似的证书验证过程。

问题排查

用户尝试了以下排查步骤：

1. 怀疑可能与TLS 1.3版本有关，尝试将max_tls_version设置为TLS_1_2，但问题依旧
2. 检查证书链，确认是自签名证书
3. 对比Envoy 1.27.1和1.31.3的行为差异

最终发现这是由于Istio配置中启用了'auto_sni'功能导致的。SNI(Server Name Indication)是TLS协议的扩展，用于在握手初期指定要连接的主机名。当启用auto_sni后，Envoy会自动设置SNI字段，这可能会影响证书验证过程。

解决方案

对于使用自签名证书的环境，可以考虑以下解决方案：

1. 在Istio配置中禁用auto_sni功能
2. 将自签名证书添加到Envoy的信任存储中
3. 为自签名证书配置适当的验证策略

最佳实践建议

1. 在生产环境中，建议使用由受信任CA签发的证书
2. 如果必须使用自签名证书，确保正确配置信任链
3. 在升级Envoy版本前，充分测试TLS相关功能
4. 关注Envoy和Istio的版本兼容性说明

总结

这个案例展示了Envoy版本升级可能带来的兼容性问题，特别是在TLS/SSL配置方面。对于使用自签名证书的环境，需要特别注意证书验证相关的配置。通过理解TLS握手过程和Envoy的证书验证机制，可以更好地诊断和解决这类问题。