Clarification on MSOLEDBSQL19 Behavior with TrustServerCertificate=True

Question

Clarification on MSOLEDBSQL19 Behavior with TrustServerCertificate=True

Abhishek Modi (amodi) 20

Hello Team,

We are currently using the MSOLEDBSQL19 driver on Windows systems and would like to better understand its connection behavior related to encryption and certificate validation.

While testing SQL Server connectivity, we observed that a connection can be established when TrustServerCertificate=True is specified, even when the following prerequisites have not been explicitly performed on the client or server:

Installing a CA-trusted TLS certificate on the SQL Server.
Importing the server's self-signed certificate into the client machine's trusted certificate store.

Our understanding is that TrustServerCertificate=True should bypass certificate chain validation, allowing an encrypted connection to proceed even if the certificate is not trusted. However, we would like clarification on the following:

If neither of the above prerequisites is configured on the server (i.e., no CA-trusted TLS certificate is installed and the server certificate is not trusted by the client), will a connection still be established when using MSOLEDBSQL19 with TrustServerCertificate=True specified in the connection string?
If the connection succeeds, could you please explain the underlying behavior of MSOLEDBSQL19 and how the driver handles encryption and certificate validation in this scenario?
Which certificate, driver, or provider behavior enables the connection to be established?
Are there any changes in MSOLEDBSQL19 compared to previous drivers/providers regarding certificate validation and encryption?
Could you explain the rationale behind the additional recommendations to install a trusted certificate or import the server certificate, given that SQL Server appears to allow the connection when TrustServerCertificate=True is specified?

Any clarification on the underlying behavior and best practices would be greatly appreciated.

Thanks,

Abhishek Modi

0 comments

4 answers

Your answer

Answer 1

sudhir kumar 0

When using MSOLEDBSQL19, setting

TrustServerCertificate=True forces the client to bypass certificate chain and host name validation, allowing an encrypted connection over self-signed or untrusted server certificates. Unlike older driver versions, MSOLEDBSQL19 evaluates this property in all encrypted scenarios, but it does not disable encryption itself.

0 comments

Answer 2

Erland Sommarskog 136.7K MVP Volunteer Moderator

Deepesh has already answered your questions, but I like to fill in that this is nothing that is unique to the OLE DB driver, but this is a change that Microsoft has done across the board with all drivers. That is, all drivers now default to require an encrypted connection by a trusted certificate

Trusting the server certificate is acceptable if you are connecting to an SQL Server instance on the same machine - the risk for a man-in-the-middle attack is minimal. Likewise it can be OK, if there is no real production data on the server. But for a connections to a production system with sensitive data, you should have a trusted certificate in place.

Also, note that depending on which OLE DB interface you use, it is either TrustServerCertificate=yes or Trust Server Certificate=true. (The fact that there are two sets of connection keywords are just plain lunacy.)

Abhishek Modi (amodi) 20 Reputation points

2026-07-14T14:45:49.6433333+00:00

Hello @Erland Sommarskog ,

Thank you for providing your input, and thank you, Deepesh Dhake, for your valuable insights.

Could you please clarify in which scenarios we should use TrustServerCertificate=yes (without space) and in which scenarios Trust Server Certificate=true (with space) should be used?

Understanding the distinction between these two formats and any driver-specific requirements would help us better understand the expected behavior and ensure our implementation follows the recommended approach.

Thank you for your assistance.

Thanks,

Abhishek Modi
Erland Sommarskog 136.7K Reputation points MVP Volunteer Moderator

2026-07-14T21:32:14.38+00:00

Could you please clarify in which scenarios we should use TrustServerCertificate=yes (without space) and in which scenarios Trust Server Certificate=true (with space) should be used?

Deepesh touched at this in one of his responses. In OLE DB, there are two ways to create connections, as discussed here: https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-ver15#ole-db-driver-connection-string-keywords. So the answer is: it depends on how you create your connections.

The problem here is that not very many program directly against the OLE DB interface, but use something that sits on top and hides how the connection is created. It's complete madness. If I would happen to meet the person who designed this, I would strangle him.
Abhishek Modi (amodi) 20 Reputation points

2026-07-15T12:27:33.8266667+00:00

Hello @Erland Sommarskog ,

Thank you for the response.

I agree with your assessment. From our the Microsoft documentation, we did not observe any functional difference between using the parameter with spaces and without spaces; the difference appears to be limited to the naming convention.

As Microsoft documentation references the parameter with spaces (Trust Server Certificate), we will proceed with that format going forward. This approach aligns with the current documentation and should help ensure compatibility and consistency with future provider versions.

If you have any suggestions, feedback, or additional insights, they would be greatly appreciated and are always welcome.

The above conclusion is based on the reference documentation you shared earlier in the discussion thread.

https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-ver15#ole-db-driver-connection-string-keywords.

Thanks,

Abhishek Modi
Erland Sommarskog 136.7K Reputation points MVP Volunteer Moderator

2026-07-15T21:35:28.3033333+00:00

Again, there are two sets of keywords on that page:

https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-ver15#using-idbinitializeinitialize

https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-ver15#use-idatainitializegetdatasource

You should use the set of keywords that match how you make your connections in your OLE DB application. Which you may not be exact aware of, if you are connecting through something that sits on top of OLE DB. But you should always use keywords from the same set, you cannot pick and choose.
Abhishek Modi (amodi) 20 Reputation points

2026-07-20T09:32:14.21+00:00

Hi @Erland Sommarskog ,

I agree with your assessment. I conducted an initial analysis of the connection mechanism and methods used within the application and found that all native engine layer connections currently utilize ATL::CDataConnection::Open(<init string>). (GetDataSource())

Based on the implementation and available references, the behavior appears to align more closely with the approach described below, which uses connection string keywords in the spaced format:

https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-ver15#use-idatainitializegetdatasource

If you have any suggestions, feedback, or additional insights regarding this behavior, they would be greatly appreciated and are always welcome.

Thanks,

Abhishek Modi
Erland Sommarskog 136.7K Reputation points MVP Volunteer Moderator

2026-07-20T09:44:51.4366667+00:00

So I have not worked with the OLE DB Consumer Templates myself; I've only used the OLE DB interface directly. But when trying to read between the lines, it seems reasonable to assume that it uses IDataInitialize::GetDataSource, and thus you should use that set of connection keywords. This also aligns with your initial observation that TrustServerCertificate=true had no effect.

I just wanted to make sure that you are looking at the correct set of keywords, and with no knowledge how you use OLE DB, I had to leave both doors open. (The fact that the API has two different sets of keywords is nothing but criminal!)
Abhishek Modi (amodi) 20 Reputation points

2026-08-19T11:21:34.79+00:00

Hi @Erland Sommarskog ,

Could you please clarify the expected behavior when Trust Server Certificate is set to False and use of data encryption is enabled/mandatory? In this configuration, should the application be able to establish a connection to the SQL Server?

Thanks,

Abhishek Modi
Erland Sommarskog 136.7K Reputation points MVP Volunteer Moderator

2026-08-19T13:28:45.1866667+00:00

As they say. It depends. If you install SQL Server locally and try to connect with that setup it will fail. On the other hand, if you connect to Azure SQL Database it will work. I will explain more.

In SQL Server Configuration Manager, click on the node SQL Server Network Configuration, and on the left side, right-click Protocols for.... You should see this:

Select Properties. With a default install, you see this:

This means that SQL Server runs with a self-signed certificate. That is, it creates a certificate when it starts up, and when you connect, you get the public key of that certificate and the client API uses that for encryption. With this setup, you must use Trust Server Certificate=True, for the connection to work. There is no way there can be any automatic trust of that certificate.

Here is how it looks on one my VMs:

Here I have made the effort to install an explicit certificate. (Oops! It expires next week. Thanks for reminding me. :-)

Furthermore, on my main machine I have this is in my Trusted Certificate Store:

Because these certificates are trusted on my machine, I can connect with mandatory or strict encryption without trusting the server certificate.

What I have done, is a little bit on the non-standard side, but at least it's cheap - zero cost. (For details how I achieved this, see this article by Phillip Steifel: https://codekabinett.com/rdumps.php?Lang=2&targetDoc=create-install-ssl-tls-certificate-sql-server)

The more normal procedure, I assume, is that you buy a certificate from a trusted vendor and whose root certificate already is your Trusted Certificate store. You see two examples in the screenshot, and those are nothing I have added; those entries come with Windows. If you install a certificate from such a vendor with SQL Server, that's all you need to do. It will work out of the box on all clients. ...with one classification: The server name is part of the certificate, and the connect must be by that exact name. So if the certificate says MYSERVER, and users connect with MYSERVER.company.com or 10.10.10.10, connection with fail. (But there is a connection-string HostNameInCertificate to deal with this situation.)

And this explains why it work on Azure: You have the root certificate for Microsoft Azure in your trusted certificate store.

Answer 3

1.Will the connection succeed with no certificate configured anywhere?

Yes. SQL Server generates a self-signed certificate at startup if none is installed, so there's always something to complete the TLS handshake with. With TrustServerCertificate=True, MSOLEDBSQL19 skips chain and hostname validation, so the handshake completes and the session is genuinely TLS-encrypted.

2.What enables this behavior?

The combination of the server's auto-generated self-signed certificate and the driver suppressing validation. Encryption still happens but identity verification doesn't.

3.What changed in MSOLEDBSQL19?

The default for Encrypt changed from no to yes/Mandatory, and TrustServerCertificate was decoupled from Encrypt, previously, if Encrypt was no, certificates weren't validated regardless of the TrustServerCertificate setting. Validation now also triggers when either side negotiates encryption, not just the client. New values (Optional/Mandatory/Strict) and the HostNameInCertificate keyword were added. Strict uses TDS 8.0 and always validates, though a ServerCertificate property (19.2+) allows pinning a specific certificate, and it requires Encrypt=Strict.

4.Why install a trusted certificate if the connection works anyway?

TrustServerCertificate=True gives you encryption without authentication. Microsoft's documentation warns that trusting the server certificate can leave you vulnerable to man-in-the-middle attacks, and recommends setting it back to FALSE once a verifiable certificate is deployed. An attacker on the network path can present their own certificate and your client will accept it. Best practice: CA-issued certificate on the server, Encrypt=Mandatory (or Strict on SQL 2022+), TrustServerCertificate=False.

Answer 4

Yes. With MSOLEDBSQL 19, a connection can still be established with encryption when TrustServerCertificate=True is used, even if the server does not have a CA-signed certificate and the client does not trust the server certificate.

How it works depends on the encryption mode:

If encryption is negotiated or required and TrustServerCertificate=True is in effect, the connection can proceed without validating the server certificate.
In that case, the session can still be encrypted, but certificate chain trust and hostname validation are bypassed.
This behavior is why the connection can succeed even when the certificate is self-signed or not present in the client trusted root store.

For MSOLEDBSQL 19 specifically:

TrustServerCertificate was not removed in version 19.
Version 19 evaluates TrustServerCertificate in all encrypted scenarios.
A key change from version 18 is this case: when the client sets Encrypt=no but the server forces encryption, version 18 ignored Trust Server Certificate, while version 19 evaluates it.
Because of that change, version 19 clients using default settings can fail when the server forces encryption and uses an untrusted certificate, unless Trust Server Certificate is updated or a trusted certificate is used.

The underlying behavior is not that SQL Server waives trust requirements on its own. The driver is what allows the connection by choosing to encrypt the channel while skipping certificate validation when TrustServerCertificate=True applies.

The certificate used is still the certificate presented by SQL Server during TLS negotiation. The difference is that, with TrustServerCertificate=True, the driver accepts that certificate without requiring it to chain to a trusted CA.

Why trusted certificates are still recommended:

A valid CA-signed certificate provides certificate validation.
The certificate must match the server FQDN when validation is enforced.
The certificate must be trusted by the client system.
This is the secure configuration and is required in stricter modes.

For example, when Encrypt=True or Encrypt=Mandatory and TrustServerCertificate=Yes is not used, the connection requires a valid CA-signed certificate, FQDN match, and trust on the client. When Encrypt=Strict, TrustServerCertificate is not supported; a valid trusted certificate is required.

So the recommendation to install a trusted certificate or import the server certificate exists because TrustServerCertificate=True is a compatibility/convenience setting that allows encrypted connectivity without certificate validation, whereas trusted certificates provide actual server identity validation and stronger security.

One more MSOLEDBSQL 19 detail: keyword format differs by interface:

Provider connection strings: TrustServerCertificate=yes;
IDataInitialize connection strings: Trust Server Certificate=yes;