SQL Server 2025 on Windows Server 2025 – sqlcmd / ODBC Driver 18 fails with “SSL Provider: The target principal name is incorrect

Hi Agrawal, Pranjal,

I just wanted to follow up and see if you had the opportunity to implement the certificate configuration steps provided above. Were you able to successfully provision a trusted CA certificate with the correct Subject Alternative Names (SAN)—specifically including localhost—and bind it to your SQL Server 2025 instance?

If you are still encountering the "target principal name is incorrect" error, or if you need any further guidance on generating the certificate or adjusting your ODBC connection string parameters, please do not hesitate to reach out. I am always here to help you get your local connections working securely!

Hi Agrawal, Pranjal,

It is completely understandable to be caught off guard by this error on a fresh installation, especially since this exact sqlcmd syntax likely worked flawlessly on older versions of Windows Server and SQL Server.

To answer your first question directly: Yes, this behavior is absolutely expected. What you are experiencing is the direct result of a major architectural shift toward a "Secure by Default" posture in both the latest client drivers and the database engine. By default, ODBC Driver 18 explicitly sets Encrypt=Yes and mandates strict server certificate validation. Simultaneously, SQL Server 2025 introduces stricter TLS 1.3 and TDS 8.0 security enforcement. When you execute sqlcmd -S localhost..., the driver requests the SSL certificate from SQL Server. Because this is a fresh install, SQL Server presents its automatically generated self-signed certificate. The driver then inspects the Subject Alternative Name (SAN) of this certificate. Since the default self-signed certificate is stamped exclusively with the server's actual NetBIOS name and FQDN, but your connection string specifies localhost, the names do not match. Consequently, the driver actively terminates the connection to prevent a potential man-in-the-middle attack, resulting in the "target principal name is incorrect" error.

Regarding your subsequent questions: No, using TrustServerCertificate=Yes (like appending -C to your sqlcmd command) is not the only supported fix. It is merely a recognized workaround intended for non-production development environments.

For a Microsoft-supported, production-ready configuration that succeeds without disabling certificate validation, you must implement the following administrative steps:

Provision a Trusted Certificate: You must deploy a certificate issued by a trusted Certificate Authority (CA), such as your internal Enterprise PKI or a public CA, rather than relying on the default auto-generated self-signed certificate.

Configure the SAN Correctly: This is the most critical step for resolving the name mismatch. During the certificate request process, you must ensure that the Subject Alternative Name (SAN) extension includes every possible DNS name the client might use to connect. This must include the server's FQDN (e.g., server2025.contoso.com), the NetBIOS name (SERVER2025), and crucially, any aliases you intend to use locally, such as localhost or 127.0.0.1.

Bind the Certificate to SQL Server: Open SQL Server Configuration Manager, navigate to SQL Server Network Configuration > Protocols for SQL2025, right-click to open Properties, and select your newly minted CA certificate in the Certificate tab. Restart the SQL Server service to enforce the binding.

Once these requirements are met, ODBC Driver 18 can keep Encrypt=Yes and TrustServerCertificate=No, and your local connections will succeed securely. As an alternative, if you already have a trusted certificate bound but you simply want to connect using an alias without generating a new certificate, you can append the HostNameInCertificate parameter to your ODBC connection string to explicitly tell the driver which name to expect on the certificate.

I hope this answer provided you with a clear understanding of the new secure-by-default architecture and the proper steps to configure your certificates. If it did, please click "Accept Answer". Should you need any further clarification on generating the SAN certificate, feel free to leave a comment!

Tracy Le.

This behavior is expected with newer SQL client drivers and secure‑by‑default configurations, and it is not limited to Windows Server 2025, but it is more visible with SQL Server 2025 because encryption and certificate validation are now on by default in more scenarios.

Key points from the provided guidance:

1. Why the error occurs
   • ODBC Driver 18 enables encryption by default and validates the server certificate.
   • The error SSL Provider: The target principal name is incorrect is a certificate name error: the host name that the client uses (for example, localhost, 127.0.0.1, or localhost\SQL2025) does not match the subject/SAN in the certificate that SQL Server presents.
   • Fresh SQL installations typically use a self‑signed certificate that either is not trusted or does not contain all the names clients use to connect.
2. Behavior expectations with SQL Server 2025
   • SQL Server 2025 introduces secure‑by‑default behavior with TDS 8.0 and TLS 1.3, where encryption is mandatory for several features and certificate validation is stricter.
   • Certificates must be issued by a trusted CA, and self‑signed certificates are no longer accepted by default for some components (for example, with MSOLEDBSQL 19).
   • Certificates must include the FQDN and NetBIOS name in the Subject Alternative Name (SAN) list; missing entries cause validation errors.
   • This aligns with the name‑mismatch error you see when connecting with ODBC Driver 18.
3. Using TrustServerCertificate
   • For ODBC Driver 18, TrustServerCertificate=Yes (for example, sqlcmd -C) is a supported way to bypass certificate validation when encryption is desired but a proper certificate is not yet deployed.
   • This is explicitly documented as an option: TrustServerCertificate can be set to skip server certificate validation when using encryption.
   • However, this is a relaxation of security and is not the long‑term best practice for production.
4. Recommended Microsoft‑supported configuration (without disabling validation)
   To have sqlcmd / ODBC 18 succeed without disabling certificate validation, the server certificate must satisfy the newer requirements:
   • Use a certificate issued by a trusted CA (internal enterprise CA or public CA), not the default self‑signed certificate, for scenarios where strict validation is required.
   • Ensure the certificate’s SAN includes all names that clients use to connect, especially:
     • The server’s FQDN (for example, server2025.contoso.com).
     • The server’s NetBIOS name (for example, SERVER2025).
     • Any service aliases used by clients.
   • Plan SAN entries carefully; adding names later requires issuing a new certificate and restarting SQL Server.
   • Configure SQL Server to use this certificate and restart the instance so that it presents the trusted, correctly named certificate to clients.
   When these requirements are met, ODBC Driver 18 can keep Encrypt=Yes/default and TrustServerCertificate=No, and connections will succeed without bypassing validation.
5. Alternative connection‑string options for name mismatch
   For name‑mismatch scenarios, the following options exist in ODBC Driver 18:
   • HostNameInCertificate can be set to the expected certificate name if the certificate’s subject/SAN is fixed but the client must use a different server name.
   • ServerCertificate (v18.1+) can be used to specify a certificate to match and verify against.
   • These options still require that the certificate be trusted; they only address name mismatches.
6. Summary for the specific questions
   • Is this behavior expected on Windows Server 2025 + SQL Server 2025?
     Yes. With ODBC Driver 18’s default encryption and SQL Server 2025’s stricter TLS/certificate requirements, name and trust errors are expected when using the default self‑signed certificate.
   • Is the only supported fix to use TrustServerCertificate=Yes?
     No. TrustServerCertificate=Yes is a supported workaround to bypass validation, but not the only fix.
   • Recommended Microsoft‑supported way to configure certificates so validation is not disabled:
     Deploy a CA‑issued certificate that is trusted by the client, ensure it includes FQDN and NetBIOS (and any aliases) in SAN, configure SQL Server 2025 to use that certificate, and keep Encrypt enabled with TrustServerCertificate=False. This is the recommended best practice.

References:

• Connection encryption troubleshooting in the ODBC driver
• "The certificate chain was issued by an authority that is not trusted" error after upgrading SNAC applications
• TLS 1.3 support
• Certificate validation failure