Bogus "The target principal name is incorrect" on connecting to "."

[jhudsoncedaron]

Describe the bug

With a connection string that reads "Server=.;Database=...", trying to connect to SQL Server with a fully valid certificate does not work.

If you are seeing an exception, include the full exceptions details (message and stack trace).

Microsoft.Data.SqlClient.SqlException
  HResult=0x80131904
  Message=A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The target principal name is incorrect.)
  Source=Core Microsoft SqlClient Data Provider
  StackTrace:
   at Microsoft.Data.SqlClient.Connection.SqlConnectionInternal.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)

Inner Exception 1:
Win32Exception: The target principal name is incorrect.

To Reproduce

1. Have SQL Server
2. Have loaded SQL Certificate

Expected behavior

Any certificate that is valid for the current hostname is valid for .

My certificate is issued for hostname.domain.name , hostname, and localhost. The certificate should pass.

Further technical details

Microsoft.Data.SqlClient version: 7.0.0
.NET target: .NET 10
SQL Server version: SQL 16 (why? to load backup files from SQL 16 of course)
Operating system: Windows 11

Additional context

Changing . to localhost does work; assuming nobody tampered with DNS lookup for localhost. But I shouldn't have to depend on that. . exists as an alias for a reason.

It is not possible to issue a certificate for . as that will be interpreted as a certificate that's valid for the root domain.

[cheenamalhotra]

Server=. and TLS certificate hostname validation are fundamentally at odds here and this behavior is by design in the driver.

MDS validates the certificate against the server name as provided, and when that name is ., hostname validation fails with:

The target principal name is incorrect.

That is expected from a certificate-matching perspective, because . is not a meaningful DNS name you can reasonably issue a server certificate for. Even if . is accepted as a local SQL Server alias for connectivity, it does not automatically become a valid TLS identity.

For a local SQL Server with encryption enabled, the practical options are:

• Use a real hostname in the connection string, such as localhost, the machine name, or the FQDN, and ensure that name is present in the certificate SAN/CN
• If supported for this scenario, use HostNameInCertificate=<expected-hostname>
• Use certificate pinning via ServerCertificate=... with Encrypt=Mandatory or Encrypt=Strict
• If you explicitly want to skip hostname validation, use TrustServerCertificate=true

[jhudsoncedaron]

"Use a real hostname in the connection string" that's a bad idea. . is almost always better. Installed instances move around

"HostNameInCertificate=" who knows what that is. See above.

"ServerCertificate=" really? See first item again. Also, most installs are using a junky internal certificate you can't get a copy of because your API doesn't provide a way to export it.

"TrustServerCertificate=true" I shouldn't have to set that manually.

I added a workaround locally, but it's a pill. It's necessary to

1. parse the connection with the base connection parser to verify that TrustServerCertificate is not set. (Because the one in Microsoft.Data.SqlClient won't do it. I would be complaining about TryGetValue being busted except for this is the only time this has come up and really shouldn't come up again.
2. Reparse the connection string with the client parser to extract the server name
3. Hand parse the server name property to remove the instance name and port
4. And only if TrustServerCertificate wasn't explicitly set, if it's . or (local) set TrustServerCertificate=false

It's really bad code, and it would be much better if I didn't have to do it.