If you create a regular Azure SQL database and go to "Connection strings" tab in the portal all the connection strings have TrustServerCertificate=False parameter. Why is that? Microsoft doesn't trust its own certificates?
Update:
I guess it's just poor naming. Found this in the official documentation:
When TrustServerCertificate is set to true, the transport layer will
use SSL to encrypt the channel and bypass walking the certificate
chain to validate trust. If TrustServerCertificate is set to true and
encryption is turned on, the encryption level specified on the server
will be used even if Encrypt is set to false. The connection will fail
otherwise.
TrustServerCertificate=true means the client will trust the certificate it gets from SQL server without fully verifying it. And this is obviously a bad thing so always use TrustServerCertificate=false.
Related
SQL Server instance has force encryption flag enabled and SQL Server has valid certificate imported into SQL instance in SQL configuration manager,
I have seen in the documentation that if the client application doesn't support encryption then the connection will fail if the force encryption flag is enabled. What does this mean? Should the client application string have encrypt=true if the force encryption flag is enabled?
If the server has Force Network Encryption enabled, then it does not matter whether the connection string has encrypt=true set or not. The server will tell the client that it must use encryption to establish the connection.
If the client does not support encryption and the server requires it, no connection will be established.
Setting encrypt=true in the connection string is used when the server has a certificate set up which allows encryption to be used, but does not require it.
I am trying to configure SQL Server 2014 so that I can connect to it remotely using SSL. A valid, wildcard cert is installed on the server, and the cert's domain name (example.com) matches the server's FQDN (test.windows-server-test.example.com).
The problem is that in SQL Server Configuration Manager, the certificate is not listed, so I cannot select it.
That is, I am stuck on step 2.e.2 from this MS tutorial.
After communication in comments I can suppose that your main problem is the CN part of the certificate which you use. To have successful TLS communication for IIS Server one have no such strong restrictions like SQL Server has.
Microsoft require (see here) that The name of the certificate must be the fully qualified domain name (FQDN) of the computer. It means that the Subject part of the certificate looks like CN = test.widows-server-test.example.com, where test.widows-server-test.example.com is the FQDN of your computer. It's not enough that you use for example CN = *.example.com and Subject Alternative Name, which contains DNS Name=*.example.com and DNS Name=test.widows-server-test.example.com, DNS Name=test1.widows-server-test.example.com, DNS Name=test.widows-server-test2.example.com and so on. Such certificate will be OK for TLS, but SQL Server will discard it. See the article, which describes close problems.
I recommend you to create self-signed certificate with CN equal to FQDN of the SQL Server and to verify that the certificate will be seen by SQL Server Configuration Manager.
UPDATED: I analysed the problem a little more with respect of Process Monitor and found out that two values in Registry are important for SQL Server Configuration Manager: the values Hostname and Domain under the key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
If I change Domain and Hostname to the values which corresponds CN of the certificate then the certificate will be already displayed in the SQL Server Configuration Manager. It could be not all problems, but it shows that SQL Server required much more as a web server (IIS for example).
UPDATED 2: I examined the problem once more in details and I think I did found the way how one can configure common SSL certificate which you already have (for example free SSL certificated from Let's Encrypt, StartSSL or some other).
It's important to distinguished what do SQL Server Configuration Manager from the configuration required by SQL Server. The Certificate tab of the properties of the Configuration Manager have more hard restrictions as SQL Server. I describe above only the restrictions of SQL Server Configuration Manager, but one can make configuration directly in the Registry to use more common SSL/TLS Certificate by SQL Server. I describe below how one can do this.
What one need to do one can in the Registry under the key like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL12.SQL2014\MSSQLServer\SuperSocketNetLib, where the part MSSQL12.SQL2014 can be a little different in your case. The SQL Server Configuration Manager help us to set two values in the registry: ForceEncryption and Certificate:
The Certificate value is SHA1 hash which can be found by examining the properties of the certificate:
or extended properties of the certificate, which you see by usage certutil.exe -store My:
One need just copy the "Cert Hash(sha1)" value, remove all spaces and to place as the value of Certificate value in the Registry. After making the settings and restarting SQL Server windows service one will see in file ERRORLOG in C:\Program Files\Microsoft SQL Server\...\MSSQL\Log directory the line like
2016-04-25 21:44:25.89 Server The certificate [Cert Hash(sha1)
"C261A7C38759A5AD96AC258B62A308A26DB525AA"] was successfully loaded
for encryption.
I want to add this for future folks that may stumble on a similar issue I encountered with SQL 2016 SP2 and failover cluster. The certificate thumbprint added to the registry had to be all upper case.
Hope this helps the next guy.
Once I followed steps in Updated 2 section of accepted answer, I can't start the SQL Server service, got those errors in Event Viewer:
Unable to load user-specified certificate [Cert Hash(sha1) "thumbprint of certificate"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.
TDSSNIClient initialization failed with error 0x80092004, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. Cannot find object or property.
got error in SQL Server error log:
The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d. Check certificates to make sure they are valid.
googled it and found out a solution:
Make sure the windows account running SQL Server service (NT Service\MSSQLServer in my case) has full permissions to the following folders/register entry:
C:\Program Files\Microsoft SQL Server[Your Sql Server Instance]\MSSQL\
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
HKLM\System\CurrentControlSet\Services\WinSock2\Parameters
I checked No.1 NT Service\MSSQLSERVER has already had the permission.
I checked No.2, NT Service\MSSQLSERVER has no permission and I added the permission. It popped up an error saying one of files in that folder was denied the operation, but I just ignored it (nothing else I can do)
I didn't check No.3 and tried starting SQL Server, it worked!!
I faced similar issue in SSRS, wherein certificate issued by microsoft active directory CA was not visible in the dropdown in SSRS. After lot of searches, trial and error I could fix it by following this link.
https://learn.microsoft.com/en-us/archive/blogs/sqlserverfaq/can-tls-certificate-be-used-for-sql-server-encryption-on-the-wire
Brief of it is as below:
The Subject property of the certificate must indicate that the common name (CN) is the same as the host name or fully qualified domain name (FQDN) of the server computer.
So in our case we suggested to request the Certificate Authority to change the Subject name to ABC-SQLServer.abc.local (FQDN of SQL Server) instead of abc-corp.abc.com
Once this change was done, we loaded certificate again in MMC and now we could see the certificate loaded in SQL Server Configuration Manager!
Hope it helps someone facing same issue!
I was still having problems even after following the above. This is my fix:
in the certificates mmc right click the certificate All tasks->Manage Pricate Keys. Give the service account full control. In my case I am using NT Service\MSSQL$
SQL Server 2019
I found that the certificate thumbprint had to be entered into the certificate registry key in lower case for Configuration Manager to see it.
SQL Server will read the registry value and use it whether the registry key is in upper or lower case.
But configuration Manager will only display it if it is in lower case
I logged on to the server with SQL Server domain account( had to add the account to local admins temporarily) and imported the certificate in personal folder of the SQL Server service account. rebooted the server, and then SQL Server could see the certificate. Hope it helps someone.
An additional failure mode is key length - SQL requires a minimum keylength of 2048. With DH channel disabled.
I have also run into an issue copying out of the MMC as detailed in the article here. Using the certutil and copying that into the registry value worked perfectly.
My problem was that the Certificate Store was for WebHosting, but to see the certificate in SSRS it must be Personal.
USE UPPER CASE for Certificate in Registry editor LOL
Still not shown in config manager but TLS is working for SQL connections.
Using information from some consultants about 2 years ago we set up a SQL Server 2012 box to always have an encrypted connection (at least we thought so). A week ago the SSL certificate expired and everything continues to work fine which is puzzling.
We forced encryption by doing the following:
Obtain an SSL certificate and install it on the SQL Server via MMC. Explicit instructions for this step are here.
Open SQL Server Configuration Manger and expand the SQL Server Network Configuration node in the left pane.
Right click Protocols for MSSQLServer and choose properties.
Go to Certificate tab and choose the installed SSL cert from the drop down.
Go to the Flags tab and set force encryption to Yes.
Now, since the SSL cert expired, there is no longer any cert selected in the drop down when I visit step 3 above. However, I put WireShark on the DB server and use SSMS to request some data. The TDS (Tabular Data Stream) packets are still encrypted? When I put WireShark on a different DB Server I set ForceEncryption to NO, those TDS packets are not encrypted as expected.
So my questions are:
How are the TDS packets still encrypted if the cert is expired?
Even when the cert was valid, why didn't I have to select Options > Encrypt Connection to connect to my encrypted DB server? I thought setting ForceEncryption=Yes required ALL client connections to specify Encrypt in their connection string (or the SSMS checkbox)?
If Web APIs are the only method of accessing my DB, and they do so over SSL, is it even necessary to encrypt the SQL Protocol?
1)How are the TDS packets still encrypted if the cert is expired?
you don't need a valid certificate in order to encrypt, you can still encrypt using an expired certificate.
2)Even when the cert was valid, why didn't I have to select Options > Encrypt Connection to connect to my encrypted DB server? I thought setting ForceEncryption=Yes required ALL client connections to specify Encrypt in their connection string (or the SSMS checkbox)?
Do not enable the Force Protocol Encryption option on both the client and the server,
if you enabled force encryption on SQL server you don't need to do it on any client-side
3)If Web APIs are the only method of accessing my DB, and they do so over SSL, is it even necessary to encrypt the SQL Protocol?
To enable SSL you need the certificate to be installed on SQL server so in order to access the DBusing SSL you are doing the same job.
Thank you
Is the data transferred between two SQL Servers protected (encrypted) by default? If not, is there a way to accomplish this?
I have two SQL Server 2005 databases running on separate servers, separate machines, separate networks. How can I ensure that data transmitted from one server to another is secure? I have tried researching the subject but am unable to find anything.
Many thanks,
Sebastian
Encrypt Via SQL Server
Provision a certificate on both machines.
Configure any non-server clients to trust the certificate's root signing authority. See How to enable SSL encryption for an instance of SQL Server by using Microsoft Management Console.
Configure the server(s) to force all incoming connections to use SSL so that any clients that do not support this will fail to connect. In SQL Server Configuration Manager, set the ForceEncryption parameter to "Yes" in the Protocols section.
OR, instead of the prior step, you can add Encrypted=yes to the provider/connection string for the connection/linked server. If, for example, you register the linked server using sp_addlinkedserver it might look something like this:
EXEC master.dbo.sp_addlinkedserver
#server = N'LinkedServerName',
#srvproduct = N'',
#provider = N'SQLNCLI',
#datasrc = N'Server\InstanceName',
#provstr = N'Encrypt=yes;',
#catalog = 'DatabaseName'
;
I do NOT recommend that you use the option TrustServerCertificate=True because this will disable the client from validating the identity of the server it is connected to.
Also, if using ODBC, the encryption property can be specified in a DSN.
Note that while servers don't require certificates to be installed since you can configure them to automatically create and sign their own certificates, it is best to manually install them, because you can run into problems with the self-created certificates since they change on each restart.
The best security is when the client specifically requests channel encryption, because this not only encrypts the data but the client also attempts to validate the identity of the server via the certificate, helping to mitigate a man-in-the-middle attack.
Encrypt Via The Network
Another option is to set up a secure tunnel (such as a VPN) between the two servers' networks, and ensure that the routing for traffic between them is entirely through said tunnel. This is 100% secure as well, as long as you are sure the traffic goes over the right route.
I realize this is a very old thread, but there's something in here that I just found out is potentially misleading.
"3. Configure the server(s) to force all incoming connections to use SSL so that any clients that do not support this will fail to connect. In SQL Server Configuration Manager, set the ForceEncryption parameter to "Yes" in the Protocols section."
The ForceEncryption parameter on the SQL server side does not fail clients that do not have Encrypt = True set on the client end. Importantly, you can create insecure connections to the SQL server instance even when ForceEncryption is set to "Yes" on the server.
You can validate this by setting ForceEncryption = Yes on the server side, then by connecting to that SQL server using SSMS and choosing not to encrypt the connection on the client side.
You can check the encryption state of the client connection by visiting the Properties of the server in Object Explorer, then clicking on View Connection Properties (right click on the servername in Object Explorer, then click Properties).
You can then see that the value for the Encypted property is set to No.
You can then do a select or other SQL statement to confirm that you are able to access data from the server side, without encryption. I believe that in order to have full end-to-end encryption, you must set encryption on both the client and the server side.
Here is a Microsoft link explaining this issue.
And a screenshot in case that link doesn't work.
And another Microsoft link saying the same thing.
And another screenshot in case that link doesn't work.
I need to prove that the encryption settings we have in our app's connection string are working.
What would be the simplest way to validate that traffic from our web site to the SQL Server is in fact encrypted?
You could use something like Wireshark to view the packets at they're transmitted over the network
You check the encrypt_option column of the sys.dm_exec_connections DMV. This way you can no only prove that is encrypted, but you can also validate in your application at start up time. To enforce the encryption you follow the methods described in this MSDN How To: Enable Encrypted Connections to the Database Engine. If either the client or the server forces encryption and a certificate is provided and the client accepts the server certificate, the connection will be encrypted. To validate that the traffic is encrypted you can use the built-in netmon.exe tool (must be installed from ad/remove system components), download the improved Microsoft Network Monitor 3.2 or other third party tools.
As an alternative the deployment site can enforce IPSec encryption.
I would set the Force Protocol Encryption to true and Trust Server Certificate to true in the db connection string. The server should fail to establish a connection if it cannot provide you with an encrypted connection as requested. There is an article that covers encryption with sql server 2005 and later.
Simple test is to try a connection with and without encryption and fail when it hands out the undesired type of connection. then its up to the DBA, IT or you to configure the server to match your requirements.
There is another much underrated tool from Microsoft itself: 'Microsoft Network Monitor'. Basically this is very similar to wireshark with the exception that some specific MS protocols have better parser and visualisation support than wireshark itself and obviously it would only run under windows ;-).
The tool is quite old and looks abandoned (havn't seen a newer release so far) but still does an good job and the grammar for defining new protocols is quite neat/interesting - so this still possess a lot of power for the future.
Analysis Example - Recording is filtered for TDS - so the other packets are discared mostly:
This is also true for sql server connections. The MNM can even visualize the resultsets going over the wire - quite neat. Nonetheless wireshark as mentioned above would be sufficient to validate encryption and applied certificates on the wire itself. Means it can understand the TDS-Protocoll fully.
Handling TLS
Also with an extension (so called experts) 'NmDecrypt' and the right certificates (including private keys) - it is possible to decrypt protocolls - quite nice for TDS which uses TLS INSIDE of TDS - no wonder - no one has really implemented that yet as a fully supported protocoll for wireshark ;)
Links for the tools:
Microsoft Network Monitor: http://www.microsoft.com/en-us/download/details.aspx?id=4865
NMDecrypt: http://nmdecrypt.codeplex.com/releases/view/85581
To guarantee that encryption is being used, you need to enable the force encryption option on the server.
Client side encryption is not mandatory. Server side is mandatory.
When the SQL Server service starts, it will stop if it can not read the certificate or there are other obstacles. It will not accept unencrypted connections.
To answer, I used a packet sniffer the first I used encryption to check, then I just relied on the fact that server side encryption is mandatory and SQL won't start.
For SQL 2000, KB 276553
Keep in mind that there is a current
SQL Server limitation if you enable
encryption on the server. Encryption
will be for all incoming connections.
If you enable encryption on the client
computer, all outgoing connections
from that client try to make an
encrypted connection to any SQL
Server.
A KB search for SQL 2005
Late edit:
Use an older version of the MS JDBC client: it can't handle server side encryption...