TDE using EKM RRS feed

  • Question

  • hi,

    I am having some problems loading my CSP from SQL Server 2008 R2 SP1 on Win Server 2003 R2 SP2.

    I wrote basic CSP as desribed here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa388213%28v=vs.85%29.aspx

    the mycsp.dll has been signed and registry has been updated. advapi32 has been also patched so that I do not require MS signing.

    however, when I try to create cryptographic provider in SSMS I get the following error (ERRORLOG):

    Failed to load cryptographic provider 'c:\mycsp\debug\mycsp.dll' due to an invalid Authenticode signature or invalid file path.  Check previous messages for other failures.

    I wonder if patching advapi32 is not enough in order to test/load customer CSP into sqlserver.

    is there any way CSP could be loaded in DEV environment?


    the sql statement is:

    create cryptographic provider mycsp
    from file = 'c:\mycsp\release\mycsp.dll'


    ssms error msg:

    Msg 33027, Level 16, State 1, Line 1
    Cannot load library 'c:\mycsp\release\mycsp.dll'. See errorlog for more information.


    all coments welcome


    Monday, November 7, 2011 2:14 PM

All replies

  • Well, one thing to check is that the SQL Server service account (whatever it may be) actually has access to the c:\mycps\release folder.   Although it probably does, there is nothing that requires the SQL Server service account to have rights to the entire C: drive. 

    Just worth checking.


    Tuesday, November 8, 2011 6:10 PM
  • Hi John,

    SQL Server was unable to use the cryptographic provider listed in the error message, because SQL Server could not load the DLL. Either the name is invalid or the Authenticode signature is invalid.

    Check that the file is present and that SQL Server has permission to access that location. Check the error log for additional related messages. Otherwise, contact the cryptographic provider for more information.

    For more information, you could refer:



    Please remember to mark the replies as answers if they help and unmark them if they provide no help. This can be beneficial to other community members reading the thread.
    Wednesday, November 9, 2011 5:05 AM
  • Hi all, I can ensure that SQL Server service account has got all necessary privileges and that DLL file also exists. I have also checked the meaning of the error message. According to http://msdn.microsoft.com/en-us/library/bb677184.aspx the DLL file needs to by digitally signed using any certificate. However, would it possible to use self signed certificate in DEV environment? Or do I really have to get it signed by Trusted Authority? Also, is there any chance to get any information about SQLEKM interface. or is it just another name for MSCAPI. thanks
    Wednesday, November 9, 2011 12:19 PM
  • As I understand it, yes the dll needs to be digitally signed and ideally by a Trusted Authority.  However the SQL Protocols blog has instructions on a do-it-yourself certificate for DEV systems.


    You will notice that it has instructions on how to include it in the Trusted Root Certification Authorities as well.

    In regard to the EKM interface, this post indicates that it is not publicly available, but the answerer to the following post may be able to help connect you to the information.


    All the best,

    Wednesday, November 9, 2011 1:42 PM
  • Hi

    quick update, I generated my own certificate and imported it through mmc->Certificates.

    Now, according to ERRORLOG, my DLL is successfully loaded into memory:

    Attempting to load library 'c:\mycsp\release\mycsp.dll' into memory. This is an informational message only. No user action is required.
    Cryptographic provider library 'c:\mycsp\release\mycsp.dll' loaded into memory. This is an informational message only. No user action is required.


    But 'CREATE CRYPTOGRAPHIC PROVIDER mycsp' statement fails with:

    Msg 33085, Level 16, State 1, Line 1
    One or more methods cannot be found in cryptographic provider library 'c:\mycsp\release\mycsp.dll'.


    Which suggests that SQLEKM interface is different from CSP.

    Also, when digitally signed, my DLL cannot be verified with cspsign.exe any longer. so I guess that tool is not needed.


    please comment



    Wednesday, November 9, 2011 10:04 PM
  • John,

    I really have nothing else on EKM since I am not in the number of those who know the interface.  (Do you actually have an EKM device you are interfacing with?)   I don't know why CSP did not work for you if not, but you don't need to justify yourself to me.

    But, I gave you a link that referenced a person who expressed willingness to help. ilsung@microsoft.com

    Did you try to contact him?


    Friday, November 11, 2011 9:13 PM
  • Hi Russell,

    is there any way I could contact you off the forum?


    Sunday, November 13, 2011 9:49 PM
  • I don't know if this old thread is still being monitored, however the link to the basic CSP you provided leads to a Content Removed page.  If you have a link on how to create a custom CSP DLL it would be appreciated. I came up empty. Thanks.
    Thursday, May 31, 2018 9:01 AM