Selectively using secure connection to SQL Server

SQL Protocols — Mon, 19 Oct 2009 21:48:00 GMT

Secure connection to SQL Server can be enforced by different ways, e.g. forcing encryption by using “ForceEncryption” property under the Network Configuration in the server. But this setting will force all clients to use encryption and any client that is not able to use an encrypted connection will fail.

If you need to connect to SQL Server selectively here is how to achieve this:

You can take advantage of the two client settings, “Force Protocol Encryption” and “Trust Server Certificate” and two connection string parameters, “Encrypt” and “Trust Server Certificate”. The table below describes different combinations of these flags and the corresponding behavior.

	Force Protocol Encryption client setting	Trust Server Certificate client setting	Connection string/connection attribute Encrypt/Use Encryption for Data	Connection string/connection attribute Trust Server Certificate	Result

1.	No	N/A	No (default)	Ignored	No encryption occurs.
2.	No	N/A	Yes	No (default)	Encryption occurs only if there is a verifiable server certificate, otherwise the connection attempt fails.
3.	No	N/A	Yes	Yes	Encryption always occurs; certificate is not validated by the client.
4.	Yes	No	Ignored	Ignored	Encryption occurs only if there is a verifiable server certificate, otherwise the connection attempt fails.
5.	Yes	Yes	No (default)	Ignored	Encryption always occurs, but certificate is not validated by the client.
6.	Yes	Yes	Yes	No (default)	Encryption occurs only if there is a verifiable server certificate, otherwise the connection attempt fails.
7.	Yes	Yes	Yes	Yes	Encryption always occurs, but certificate is not validated by the client.

If you are not using a server certificate you can go for #5, though #4 with Server certificate is recommended to prevent Man-In-Middle type network attacks. Alternatively you can also use connection string parameters, depending on whether you are using verifiable Server Certificate or self signed server certificate chose #2 or #3. The last two options use both client settings and connection string parameters.

The above connection string values are for OLEDB, for ODBC the connection string values are “true”/”false” instead of “yes”/”no”. For more info please refer to http://msdn.microsoft.com/en-us/library/ms130822%28SQL.90%29.aspx

If you still get error messages like “SSL Security error” and you are using a verifiable server certificate you need to follow the link below to export the server certificate and import it back in the client.

http://support.microsoft.com/kb/316898 (follow the steps for "Enable encryption for a specific client")

Bhaskar Bhattacharyya, SQL Server Protocols
Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights

Understanding “Data Source=(local)” in SQL Server Connection Strings

SQL Protocols — Sat, 20 Sep 2008 01:06:00 GMT

Lately we have noticed many misunderstandings surrounding the usage of the Data Source keyword in connection strings, caused by people generalizing from an example demonstrating a connection string for local connectivity and creating their own connection string for a remote connection. Here is one such example connection string for local connectivity as it would be used in VB.Net:

Public con As New System.Data.SqlClient.SqlConnection("Integrated Security=SSPI;Initial Catalog=TestDatabase;Data Source=(local);")

This connection string's options can be dissected as:

- Integrated Security=SSPI; – This means we want to connect using Windows authentication

- Initial Catalog=TestDatabase; – This means the database we want to first connect to is named “TestDatabase”.

- Data Source=(local); – This means that we want to connect to the SQL Server instance located on the local machine.

The confusion occurs with this last option, since people think that “local” is a keyword referring to the local machine account, when in fact the special keyword is "(local)", including the parentheses. As a result, if they want to use a remote connection, and if their server’s name is, for example, TestServer with IP address 10.1.1.10, they try to use the connection string option: “Data Source=(TestServer)” or “Data Source=(10.1.1.10)”. Since the special keyword here is the whole word “(local)”, the correct connection string option would be: “Data Source=TestServer” or “Data Source=10.1.1.10”. So, as a whole line of code, this would now read:

Public con As New System.Data.SqlClient.SqlConnection("Integrated Security=SSPI;Initial Catalog=TestDatabase;Data Source=TestServer")

or:

Public con As New System.Data.SqlClient.SqlConnection("Integrated Security=SSPI;Initial Catalog=TestDatabase;Data Source=10.1.1.10")

Dan Benediktson
SQL Server Protocols
Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights

SQL Protocols : Connection String

Selectively using secure connection to SQL Server

Understanding “Data Source=(local)” in SQL Server Connection Strings