hostname in certificate not honoring SAN list

[swageblock]

We are having trouble getting ADO.NET to trust a name in the TLS Encryption Certificate for our DB Servers. We are able to set TrustServerCertificate as a workaround, but our security folks are not entirely happy with this option as it removes the server identification from the connection negotiation. We are connecting through an Envoy Proxy currently to add some network connectivity controls to the K8's namespace that our client is running within, which makes the hostname inconsistent with the servers hostname.

We have a rather large environment and would prefer to use a SAN entry to make connections consistent across applications and environments.

My question: Is using a SAN in the hostnameincert stanza supported functionality?

[JRahnama]

@swageblock, The short answer is yes. HNIC (HostNameInCertificate) is intended to accommodate SANs. The subject of a SQL SSL/TLS certificate must be a FQDN (Fully-Qualified Domain Name). However, if you have defined a Subject Alternative Name (SAN) in your certificate, you can pass that through the connection string as HNIC. This name is then used in the RCV (RemoteCertificateValidation) callback.

[swageblock]

What we have found: in our testing if we have an
FQDN
serv1.uat.company.local
SAN list of
serv1.uat.company.local
serv1
dbservers.company.local

The only HNIC value that will work is the serv1 value. Any help is appreciated.