Error Ssl Context Is Not Usable Without Certificate And Private Key

 admin

YouTube Video (Better Quality)

2016-05-09T20:47Z 0 ERROR SSL error: Unable to get private key from 'server-key.pem' 2016-05-09T20:64Z 0 Warning Failed to set up SSL because of the following SSL library error: Unable to get private key. Rivate key is normally encrypted and protected with a passphrase or password before the private key is transmitted or sent. When you receive an encrypted private key, you must decrypt the private key in order to use the private key together with the public server certificate to install and set up a working SSL, or to use the private key to decrypt the SSL traffic in a network protocol.

The new CSR will not be the same since the private key must be different. You may not use the same CSR again, even if it seems convenient. You can test a CSR by using the decoder in the Managed SSL Tab of your GlobalSign accounts. Should you not have that available, you can safely use online resources to check your CSR, as long as you do not. 2016-04-28T20:45Z 0 Warning Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key. I was under the impression it was supposed to auto generate one. Keys and SSL Certificates. SSL/TLS use public and private key system for data encryption and data Integrity. Public keys can be made available to anyone, hence the term public. Because of this there is a question of trust, specifically: How do you know that a particular public key belongs to the person/entity that it claims.

I was approached with a case where the customer was trying to create a Data Source within the Power BI Admin Center and received the following error when trying to test the connection and having Encrypt Connection selected.

Failed to test connection. [DBNETLIB][ConnectionOpen(SECDoClientHandshake()).]SSL Security error.

When we get an SSL error, we are talking about Certificates and trying to encrypt traffic between the client and the Data Source. The client in this case will be the Data Management Gateway.

While we are using Power BI, this is a great example of just a regular connectivity issue. This is not a Power BI specific issue. We would get a failure in a different application as well, such as Management Studio.

They were using the Microsoft OLE DB Provider for SQL Server as the provider. This is a really old provide and we should move to the .NET Provider or SQL Server Native Client if possible. Although depending on how you pulled information into Excel, that may be the provider listed and we need to match that as I’ve described in other blogs.

One of the reasons I recommend moving off of it is due to the error message itself. The OLE DB Provider error is fairly generic and not overly helpful. With the .NET Provider and SQL Server Native Client, the messaging has been updated and can give you more details. Here is what the error is from the SQL Server Native Client.

SSL Provider: The certificate chain was issued by an authority that is not trusted.

This is due to the certificate that SQL Server is presenting. Based on the information in the certificate, and the certificate is invalid. This can happen for multiple reasons. In this case the error indicates that it was because we don’t trust the certificate, which is a fairly specific error versus the generic error from the OLE DB Provider.

How to correct it

To correct this, we have to deal with certificates. In our case, the certificate used by the SQL Server is not within the Trusted Root Certification Authorities store of the machine running the Data Management Gateway.

To review the Trusted Root store, we can use MMC to do this. Open MMC and add the Certificates Snap In.

When you add that, you’ll presented with a dialog about how you want to manage certificates. In what context? You have three options: My user account, Service account and Computer account.

I always use the Computer account context. This will cover everything on the machine. If you use My user account, it will be for your specific user. So, Management Studio would start working, but the Data Management Gateway would still fail as that doesn’t run under your user account. There are reasons why you would want to do either a service account or your user, but you need to know what you are doing and what your scenario is to understand how things will be affected. For the purposes of this walk through, I’m going with Computer account.

After we add the Snap In within MMC, we will see several folders. There are two we want to focus on. Personal and Trusted Root Certification Authorities.

Key

The Personal store is where the certificates reside that you can actually use. The Trusted Root store are the items that we trust that could be part of the certificate chain.

For our purposes, and to correct the issue, we are interested in the Trust Root store. When we select the Certificates folder under the Trusted Root, these are all of the Certification Authorities (CA) that we trust. So, if any certificate originates from any of these, they will be trusted by the system. VeriSign is an example of one that is in this folder. So, any certificate that comes from VeriSign, we will trust because it is a known organization.

What is missing here is the item that will cause us to trust the certificate that is being presented by SQL Server. There are different ways to create a certificate. You can generate a self signed certificate. You can get a certificate from a known CA such as VeriSign. Or your organization may have their own Certification Authority. In my case, I did a self signed certificate. There are also different ways to do that. You can create it through IIS, but in my case I used makecert to generate it. This can be found in the Windows SDK.

Here is the makecert command I used to generate the server certificate.

makecert -r -pe -n 'CN=guyinacubesql.guyinacube.com' -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp 'Microsoft RSA SChannel Cryptographic Provider' -sy 12

There are a couple of things that are required here. The eku parameter I used indicates it is a Server Certificate. Also, the sky parameter indicates exchange. These are both required. This was run on the SQL Server.

I created the certificate and then exported it to a PFX file. PFX includes the private key. We really only need the public cert which could just be a CER file. I always include Extended Properties on the export.

Error Ssl Context Is Not Usable Without Certificate And Private Key West

I then go to the machine running the Data Management Gateway, and within the MMC/Certificates window, we can right click on the Certificates folder under the Trusted Root store, right click, go to All Tasks and select Import. We can enter the password for the PFX package and Include all extended properties.

We then want to place the certificate within the Trusted Root Certification Authorities store.

Once all of that is done, we should see our certificate listed within the Trust Root store.

The key symbol on the Cert icon indicates that it has the Private key. You will notice that the others don’t have the private key, and that’s fine. So, now if we go back and test the connection on the Data Source, it will connect successfully because we trust the CA.

If we change the provider over to SQL Server Native Client 11, we will actually get another error.

SSL Provider: The target principal name is incorrect.

SQL Server Native Client is a little more strict in its certificate validation. We used the NetBIOS name for the server name. However the name in the Certificate is the Fully Qualified Domain Name (FQDN). So, they don’t match. If we change the server name to the FQDN, it will then work correctly.

Error Ssl Context Is Not Usable Without Certificate And Private Keyboard

We care about the Certificate Path

The reason this failed is because we didn’t trust the root CA. This comes down to the Certification Path. When you open a certificate, there will be a Certification Path tab. For a self signed certificate, you will only have that certificate listed.

Error Ssl Context Is Not Usable Without Certificate And Private Key Bank

You may have multiple items listed. If there is a red X on any item here, then the certificate will not be trusted. Here is an example of one that isn’t trusted.

That’s when we need to add that to the Trusted Root store, like we just did, to get it to be trusted.

Domain Certificate

I mentioned that you could have a Certification Authority within your organization (such as your Domain). I can create a Domain Certificate multiple ways, but the easiest way for me is to just do it on a machine that has IIS installed. When you go to the server, and look at Server Certificates, an option on the left says Create Domain Certificate.

When you create that certificate, you will see the CA Certificate as a root within the Certification Path tab.

Error Ssl Context Is Not Usable Without Certificate And Private Keys

From the domain perspective, every machine joined to the domain will have that CA Certificate in the Trusted Root store, so no action is needed. It would just work.

Adam W. Saxton | Microsoft Business Intelligence Support – Escalation Services@GuyInACube | Mixes | YouTube | Facebook.comguyinacube