Choosing between CA-issued certificate validation and TrustServerCertificate for SQL Server TLS in a mixed DNS environment

Our SQL Server 2022 instances serve applications that connect using both fully qualified domain names (FQDNs) and short hostnames, depending on network zone and legacy configuration. We want to enforce encryption with certificate validation (Encrypt=true, TrustServerCertificate=false) in production, but the current self-signed certificate only contains the FQDN in its SAN. Re-issuing a CA-signed certificate with every short name as a SAN entry is operationally cumbersome, while setting TrustServerCertificate=true removes hostname verification entirely and introduces spoofing risk.

The core constraint is that client drivers (Microsoft.Data.SqlClient 5.x, ODBC 18) will reject connections when the connection string hostname does not match the certificate SAN, yet we cannot immediately standardize all connection strings to the FQDN. We need a documented approach that maintains validation for FQDN connections while allowing a controlled transition for short-name clients.

Is there a supported configuration — such as multiple certificates per instance, a wildcard SAN, or a fallback validation path — that lets us keep TrustServerCertificate=false for FQDN clients while safely accommodating short-name clients during migration? What does Microsoft's documentation say about certificate selection when multiple hostnames are in use?