Background Information:
I have a single Window VPS at example.com.
I have it running IIS and SQL Server.
I have a certificate for example.com that works fine with IIS.
I want to use the same certificate for SQL Server to allow encrypted connections with clients.
SQL Server Configuration Manager does not present the certificate in the drop down.
I believe the problem is that SQL Server does not think the certificate is valid, because what SQL Server thinks the server name is does not match the certificate (example.com).
How do I check what SQL Server thinks the server name is? If it is wrong how would I change it?
Okay I found out the issue.
The hostname on my machine was wrong. It wasn't "example.com", but some name randomly generated by windows. You can set this in the computer's properties window.
The certificate was not registered to be used on port 1433. I had to use netsh to enable the certificate to be used on port 1433. Instructions here: http://msdn.microsoft.com/en-us/library/ms186362(v=SQL.100).aspx
Those two steps where complete I got the certificate to show up in SQL Server Configuration Manager, but I still had a problem went I attempt to run SQL Server. It would not start with a message from the logs saying it could not find or read the SSL Certificate.
The last step was making sure the account running SQL Server had permission to read the certificate. I went into the certificate snap-in and then went to properties under the certificate, then on the Security tab I gave the Network Services account read permission on the certificate. (NOTE: I did not find any tutorials online reference this step. It was just some dumb luck that I found this.)
After those steps where complete the SQL Server Service start up with out any problem.
Related
I created an Azure SQL Server. I have set the firewall, added my IP address to the rules. I tried to log in using SQL Server Managment Studio but got the network error every time. I am using the Server Admin Login and password created while creating the SQL server. Are there any more steps required to log into the SQL Server?
Note: I also enabled port 1433 for inbound connections on my PC.
According to the error message, we should check the server name of the database.
We can select the database here, and SQL Server Managment Studio will type the server name automatically:
Another way, we can find the information via azure portal, then type the server name manually:
It seems you are using named pipes to connect to SQL database. What happens if you specify TCP/IP protocol in advanced properties tab?
Thanks Everyone for your inputs. The only issue was, the firewall was blocking the port 1433. After opening it, I could connect to the SQL Server hosted in Azure. The link below mentions the requirement to open the said port. https://learn.microsoft.com/en-us/azure/sql-database/sql-database-develop-direct-route-ports-adonet-v12
I recently created a self-signed certificate and turned encryption on in SQL Server 2014:
The problem is that now the SQL Server service won't start:
This article from 2010 identifies the problem as a permissions issue: The SQL Server service does not have the necessary permission to read the SSL cert's private key.
The problem is that I am stuck on step 4 of the solution proposed in the article:
There is no group or user name matching the proposed format when I bring up the window shown in the article.
Is there another way I can determine the account that SQL Server service runs under, so that I can give it permissions to read the SSL cert?
An entirely different solution is welcome too.
If you specify the certificate, which should be used for TLS by SQL Server, then the SQL Server windows service have to read the certificate and the private key (the file from the folder %ProgramData%\Microsoft\Crypto\RSA\MachineKeys), which corresponds the certificate. The problem is: the SQL Server Configuration Manager in not comfortable and it makes not all the required work.
Thus first of all one should localize the Account used by SQL Server. One should start services.msc, find the account of SQL Server service. It's typically a build-in account like Local System, Network Service a local or domain account like .\SQLServer, DOMAIN\SQLServerAccount or an service account like NT Service\NT Service\MSSQL$SQL2012 on the picture below:
To grant permission on the private key to the account one can use Certificate Snap-In of mmc. One can start mmc.exe, choose "Add/Remove Snap-in" in the "File" menu, choose "Certificates" Snap-in and to choose "Computer account" of the Local computer. Then one should select the SSL certificate of Personal store and then use context menu "Manage Private Keys...".
and to add account like NT Service\NT Service\MSSQL$SQL2012, found above, and to set "Read" permission to the account on the private key:
If you would like to establish connection to the SQL server inside of the domain (both the client and the server have to belong to the same Active Directory or to the directories connected via the trust) then one should to create SPNs for the SQL server. If I correctly understand your requirements, you want to allow remove connection to SQL Server over HTTPS. One have to active mixed security to be able to connect to the server via SQL Server Authentication:
After creating SQL Login, making all above changed and restarting SQL Server service one will be able to establish TLS (encrypted) connection to the SQL server. In case of attempting to connect via Windows Account without creating SPN previously one get the error:
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.) (Microsoft SQL
Server, Error: -2146893022)
The target principal name is incorrect
If one forget to change Windows Authentication to Mixed authentication () then one will get the error like
Login failed for user 'OlegKi'. (Microsoft SQL Server, Error: 18456)
If all above steps done one can establish TLS connection using SQL Management Studio for example, but one still have to choose some options:
One should check "Encrypt connection"
and to set additional connection property TrustServerCertificate=true
Typically one use Encrypt=true;TrustServerCertificate=true; as the part of connection string in the application which establish the connection to SQL server. We set Encrypt=true property by the checkbox "Encrypt connection" describe above. More detailed about the meaning of the properties and different combinations of the options can be read in "Enabling Encryption" section of the MSDN article.
If one do all the above steps and check "Encrypt connection" without setting TrustServerCertificate=true property then one will get the error:
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.) (Microsoft SQL
Server, Error: -2146893022)
The target principal name is incorrect
which I already described above in a little another situation (connection with Windows account).
I described all above steps because configuration of TLS connection to the server is really not so easy and one can get strange errors, which direct description gives no direct tips how to fix the problem.
One other note: If you are entering the certificate thumbprint into the registry manually by copying and pasting from the certificate manager, you must remove the leading character. It is an invisible unicode character, but it will cause the SQL Server service to be unable to start if it is present. This is in addition to making it ALL CAPS, and removing all spaces.
I ran into this issue as well. What i was doing was:
Importing the certificate from the sql server protocol properties dialog, using the 'import' button. I imported the public key, then another open dialog opened to import the private keys. I then set the private key permission to the sql server service.
When importing a key pair directly, such as a .pfx bundle, the application crashed.
All permissions to MachineKeys were granted as well for the sql serive, but I could not find through process monitor any access denied for that path.
In order to solve my issue, i imported the pfx directly from the explorer. I first removed the key pair from the store, then I ran through the wizard to import the pfx in the local machine store, personal folder. I checked the permissions on the private key, they were still set for the sql service. I checked the protocol properties, the certificate was already selected. Only then the server started.
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.
I have a SQL Server 2008R2 running on a Windows 7 Home Premium, I access the database from a remote PC over the internet. This works but the data are transmitted in plain text.
Now I want to enable SSL.
I tried several tutorials.
What I can do in the moment is the following:
Create a self-signed certificate in IIS 7
(Steps one to four of the following tutorial)
http://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-in-iis-7.html
Assign the certificate to the SQL Server instance
A. Open SQL Server Configuration Manager
B. Right click on 'Protocol on ' (for the instance which we need, here it is STANDARD)
C. In the certificate tab and select the certificate we created earlier.
D. Click on Apply and restart the SQL Server instance to get this change applied.
This works for localhost: if I connect with SQL Server Management Studio running on the same machine as SQL Server it works with the option "Encrypted Connection" activated.
Before I imported the self created certificate It did not work to connect with the option "Encrypted Connection" activated.
If I want to connect with SQL Server Management Studio with the option "Encrypted Connection" activated from a remote PC outside the local network I get this error:
Cannot Connect to home2server.de,50021\SQLServer Additional Information: A Connection was established, but the Certificate was signed from a not trustworthy certification center.
I exported the certificate to SQL_cert.pfx with IIS and copied this file on the remote PC who wants to access the database. Then I double clicked on it and imported it.
Now I get a new error:
The CN Name of the Certificate does not match with the given value.
My guess is that the certificate is issued for database-pc (the computer name of the PC where SQL Server is running). This is the reason it works for "localhost" as the server name.
I think I have to issue a certificate which is issued for home2server.de because this is the domain that redirects the connection to database-pc.
Is my thought true ? And if yes how can I issue a certificate like this?
Add an entry to your hosts file that maps home2server.de to 127.0.0.1 (or ::1), then use home2server.de when connecting locally.
...or don't encrypt local communications.
I have read a number of articles on how to configure mirroring on SQL Server 2012. I went through the steps and everything worked until hitting the final step, which didn't work.
When I run this on the Principal:
ALTER DATABASE MyDBName SET PARTNER = 'TCP://1.2.3.4:5022';
I get this error:
The server network address "TCP://1.2.3.4:5022" can not be
reached or does not exist.
When I run the counterpart ALTER statement shown above, but on the Mirror, it works fine.
I have tried all the steps in this troubleshooting article.
Important points:
The Primary and Mirror servers are in different datacenters, not on the same network at all. Not connected by VPN. Completely untrusted by each other.
I can connect to the Mirror via SSMS on the Primary and run queries. And vice versa.
I configured certificates on each server to establish the trust relationship. Everything worked during the setup and config, no errors.
I configured the endpoints on both servers and verified they're active/enabled.
I opened port 5022 on both servers by configuring incoming and outgoing windows firewall rules. I can telnet to the Mirror from the Principal and vice versa - ports appear open, no problems.
In the troubleshooting guide mentioned above, I tried steps 1-6. I didn't try 7, deleting the endpoints and re-creating, because they look perfectly valid and active to me.
Looking for some ideas on this one.
If you can telnet that port from the principal machine everything is fine with TCP/IP and firewall settings.
I can remember that I had a similar issue in the past. Unfortunatly I dont remember the exact solution but it was related to security/authentication of the endpoints and the SQL Server service account not having enough permission on the mirror machine. Unfortunatly the error message is pretty misleading in this case. Script the endpoints and verify their settings, SSMS has no UI for that.
Another thing that you could check is that you have the possibility to also connect to port 5022 from the mirror to the principal machine. You will get the same error message if the connection is not possible from both instances.
Sorry that I cant provide you a proper solution, but maybe that points you to the right direction.
Unfortunately there are quite non-informative error messages in MS SQL. The problem might be an authorization issue and the server still will be saying "network address can not be reached".
Considering "servers are in different datacenters", how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.
There can be multiple reasons for this to happen.
In your SQL Server Management Studio, if you see a White bubble next to the server instance name, instead of the Green bubble, then you can try the following:
"Allow an app through firewall" and add "Windows Management Instrumentation (WMI)" for Windows Server 2012. If it is Windows Server 2008, you can allow "Remote Administration" through firewall.
Is it meant to be a semi colon?
ALTER DATABASE MyDBName SET PARTNER = 'TCP://1.2.3.4;5022'
The semi colon is used when connecting to IP / Port when using management studio.