locked
InitializeSecurityContext(SChannel) Fails with SEC_E_WRONG_PRINCIPAL RRS feed

  • Question

  • I am trying to use SChannel to secure a socket connection. I was not able to find an SChannel example but I did find this

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa380537(v=vs.85).aspx, which uses the Negotiate package.  I thought I could use this as a base and convert it to SChannel.

    Although that sample was not quite correct, I was able to get it built and working for Negotiate.

    I made the following changes to match what I think SChannel requires:

    Change the package name in the client & server from "Negotiate" to "Schannel"

    Provide an X.509 certificate context to AcquireCredentialsHandle.  The certificate is located in the Root store of the local computer account.

    Set the TargetDataRep parameter to InitializeSecurityContext to 0 in the client.

    The result is SEC_E_WRONG_PRINCIPAL on the second call to InitializeSecurityContext - after receiving a message back from the server.

    Any suggestions on where I've gone wrong would be most appreciated.


    • Edited by MikeS.uis Monday, March 23, 2015 11:55 PM
    Monday, March 23, 2015 11:54 PM

All replies

  • The differences between using Negotiate and Schannel are very different due to what you have to pass to the SSPI APIs.

    You would only be passing a cert to AcquireCredentialsHandle() if you were required to do client auth.  Do you need to do client auth? 

    SEC_E_WRONG_PRINCIPAL would indicate that you are passing something to the 3rd param in InitializeSecurityContext().  This parameter should be NULL (target name).  It is typically used by Negotiate to use Kerberos or if you were using Kerberos directly.

    thanks

    Frank K [MSFT]

    Follow us on Twitter, www.twitter.com/WindowsSDK.

    Tuesday, March 24, 2015 4:33 PM
  • Thank you for the reply.  It pointed me in the right direction to resolve that problem.  But I've run into something else now.

    My reference to AcquireCredentialsHandle was on the server side, creating a cert to pass the context to ACH via the SCHANNEL_CRED parameter.

    My problem was misreading the documentation and passing the wrong value (not the common name of the cert above) to InitializeSecurityContext as TargetName in the client program. 

    The SChannel server & client programs now work on my development machine, running 64-bit Win7.  I take them to a test machine, running Win 2008 R2, and the Client fails, now with InitializeSecurityContext returning SEC_E_DECRYPT_FAILURE.  Searching through the forums, I found some information that TLS does not work on Win Srv 2008 and ISC could get this error.

    My server program had set grbitEnabledProtocols to 0 in SCHANNEL_CRED on the call to AcquireCredentialsHandle.  On the Win7 machine this yielded TLS protocol as reported by the Win7 client.  I changed the server to set grbitEnabledProtocols to SP_PROT_SSL2 and now the Client works on both Win7 and Win Srv 2008 R2.

    That's good, but SSL2 is not the requirement.  What is needed to get TLS working on Win Srv 2008 R2?


    • Edited by MikeS.uis Friday, March 27, 2015 2:30 AM
    Thursday, March 26, 2015 8:59 PM
  • You may need to enable TLS on Windows Server 2008 R2.

    https://technet.microsoft.com/en-us/library/dn786418.aspx

    thanks

    Frank K [MSFT]

    Follow us on Twitter, www.twitter.com/WindowsSDK.

    Monday, March 30, 2015 11:09 PM
  • I was able to enable TLS1.2 with:-

    SchannelCred.grbitEnabledProtocols = SP_PROT_ALL;

    instead of

    SchannelCred.grbitEnabledProtocols = SP_PROT_CLIENTS;

    Dallas

    www.ekkkysoftware.com

    Monday, September 21, 2015 4:26 AM
  • Thank you for the reply.  It pointed me in the right direction to resolve that problem.


    Hi Mike,

    could you tell me what exactly have you done ? I have the same problem.

    Thanks,

    Regards,

    Yuriy

    Monday, May 20, 2019 10:26 AM