配置Istio的AKS Pod通过AD ID连接Azure SQL遇证书名称不匹配问题

针对你遇到的问题，核心原因是Istio在处理AD认证的SQL连接时，未正确传递TLS流量的SNI（Server Name Indication）信息，或者TLS配置错误导致证书验证失败。以下是具体解决步骤：

1. 修正Service Entry配置，精准识别Azure SQL端点 #

使用具体的数据库FQDN而非泛型域名配置Service Entry，确保Istio正确路由流量：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: azure-sql-db
spec:
  hosts:
    - "<你的数据库名称>.database.windows.net" # 替换为实际数据库FQDN
  ports:
    - number: 1433
      name: tcp-sql
      protocol: TCP
  resolution: DNS
  location: MESH_EXTERNAL

2. 配置Destination Rule启用TLS透传 #

禁用TLS的配置会破坏Azure SQL的强制TLS要求，需将Istio设置为透传TLS流量，让客户端与Azure SQL直接完成TLS握手，确保SNI正确传递：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: azure-sql-db
spec:
  host: "<你的数据库名称>.database.windows.net" # 与Service Entry的host一致
  trafficPolicy:
    tls:
      mode: PASSTHROUGH # 关键：透传TLS流量，不终止

3. 确认.NET 6应用连接字符串配置 #

明确指定加密和证书验证参数，确保客户端发送正确的SNI：

Server=tcp:<你的数据库名称>.database.windows.net,1433;Initial Catalog=<数据库名>;Authentication=Active Directory Default;Encrypt=True;TrustServerCertificate=False;

注：TrustServerCertificate=False会强制验证证书名称，必须确保连接字符串中的服务器FQDN与Azure SQL证书完全匹配。

4. 排查Istio Sidecar日志 #

查看Pod的Istio代理日志，确认TLS握手和SNI传递情况：

kubectl logs <你的Pod名称> -c istio-proxy | grep -i "1433\|tls\|sni\|cert"

如果日志中显示SNI与数据库FQDN不匹配，需检查Service Entry和Destination Rule的host是否正确。

5. 确保Azure AD认证的出站流量正常 #

AD认证需要访问Azure AD端点，若Istio拦截了这些流量，需添加对应的Service Entry：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: azure-ad-endpoints
spec:
  hosts:
    - "login.microsoftonline.com"
    - "login.windows.net"
  ports:
    - number: 443
      name: https
      protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL

为什么之前的配置无效？ #

• 禁用TLS的Destination Rule会让Istio以明文发送流量，而Azure SQL强制要求TLS连接，导致证书验证逻辑混乱；
• 泛型的*.database.windows.net Service Entry可能无法让Istio正确识别特定数据库的SNI需求，进而导致证书名称不匹配。

内容的提问来源于stack exchange，提问作者Techie1888