Solved: SQL Server Key Vault Connector: Error code 2058

Jul 30, 2018 | Tarun Arora

Azure KeyVault

Today I spend all afternoon trying to troubleshoot why the SQL Azure KeyVault Connector fails to connect with my SQL 2016 instance hosted in Azure IaaS only to realise that there is a known bug in the february release of the SQL Azure KeyVault connector… If this is what you are seeing, read on for the fix…

Msg 33049, Level 16, State 2, Line 4
Key with name 'xxx' does not exist in the provider or access is denied. Provider error code: 2058.  (Provider Error - No explanation is available, consult EKM Provider for details)

This issue will affect you if you are using the version 15.0.300.96 of the SQL Server Connector for Microsoft Azure Key Vault, refer the screen shot below…

Sql Server connector for Microsoft Azure Key Vault v15.0.300.96

This error will manifest when you try to create the Asymmetric key… The error message is dubious and this specific error code isn’t even documented on the Microsoft Docs.

Msg 33049, Level 16, State 2, Line 4
Key with name 'xxx' does not exist in the provider or access is denied. Provider error code: 2058.  (Provider Error - No explanation is available, consult EKM Provider for details)

You’ll probably see the following crop up in the event log…

The following information was included with the event:
 
Vault Name: EKM Operation
Operation: SqlCryptGetKeyInfoByName
Key Name: N/A
Message: Error when accessing registry:5

Resolution

Like me, you’ll obviously ignore the message in the event log! Go back and read it again, as indicated in the message - it fails because ‘error when accessing registry’…

Well it turns out there is a new undocumented requirement for a registry key. The only problem is neither the SQL connector installer nor the connector DLL or SQL Server has the rights to create it!

To fix this do the following:

  • Open regedit
  • Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
  • Create a new Key called “SQL Server Cryptographic Provider” (without quotes)
  • Right click the key, from the context menu select ‘permissions.

Give Full Control permissions to this key to the Windows service account that runs SQL Server

That’s it! Run the operation to create the assymetric key again, it will work…

Hopefully Microsoft will fix this error in an upcoming release, but for now, you have a workaround.

Tarun

About author
Author Image
Tarun Arora
Tarun Arora is obsessed with high-quality working software, DevOps, Continuous Delivery and Agile. His core strengths are Azure, VSTS, PowerShell, SQL and WPF. He is a Microsoft MVP in Visual Studio Development Tools and the author of 'DevOps & ALM with TFS 2015'.
Comments