Getting "Could not establish secure channel for SSL/TLS with authority" and "The request was aborted: Could not create SSL/TLS secure channel" when .NET console application not running as administrator RRS feed

  • Question

  • More and more customers having Windows 10 are reporting us, that they cannot communicate with server and in log they get:

    DateTime = 18. 2. 2020 15:51:02

    Header = General exception - Message Could not establish secure channel for SSL/TLS with authority 'XXX.XXX.XXX'.


    DateTime = 18. 2. 2020 15:51:02

    Header = General exception - InnerException.Message The request was aborted: Could not create SSL/TLS secure channel.


    DateTime = 18. 2. 2020 15:51:02

    Header = General exception - StackTrace Server stack trace: at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason) at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout) at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at ePodatelna.Ardaco.EpoUpvsWebServices.getUnprocessedMessages(getUnprocessedMessages request) at RoTurSoft.eModule.Connector.GetMessagesFromServer() in 


    The strangest thing on it is, that when .NET console application is started as administrator, then communication works fine. 

    We can find records in Windows Event Log produced during execution of our communication module: 

    -System -Provider [ Name] Microsoft-Windows-Security -Auditing [ Guid] {54849625-5478-4994-a5ba-3e3b0328c30d} EventID 5061 Version 0 Level 0 Task 12290 Opcode 0 Keywords 0x8010000000000000

    -TimeCreated [ SystemTime] 2020-02-18T13:12:00.818868200Z EventRecordID 20831 

    -Correlation [ ActivityID] {af466a57-e64c-0001-ba6a-46af4ce6d501} 

    -Execution [ ProcessID] 716 [ ThreadID] 3808 Channel Security Computer ROBERT Security 

    -EventData SubjectUserSid S-1-5-21-3365019420-3031833462-1668593205-1002 SubjectUserName Uzivatel SubjectDomainName ROBERT SubjectLogonId 0x1c684 ProviderName Microsoft Software Key Storage Provider AlgorithmName RSA KeyName {374E39B7-CC18-46D9-867B-CE21E671736F} KeyType %%2499 Operation %%2481 ReturnCode 0x80090010


    It seems to be something permission related stuff, but how to find out what is different to many other Windows 10 computers running the same module find as standard users. 

    Thanks for any hint where to find. 


    Wednesday, February 19, 2020 10:47 AM

All replies

  • Hi,
    Establishing the SSL/TLS communication channel between the client-side and the server-side requires the certificate trust relationship. thereby the client should provide a certificate and has full control to the certificate(read public key of the certificate and access the private key of the certificate).
    Does your WCF server-side authenticate the client with a certificate and we provide a client certificate on the client-side? If indeed, we should place the certificate provided by the client into the Local Machine store of the certificate instead of the Current User store of the certificate. by default, the Current user store of the certificate can only be accessed by the user running the WCF client project, i.e. windows login account.  The secure communication (SSL/TLS) requires that the public key exchange of the certificate and the permission to access the private key of the certificate, or the communication channel will not be established.
    Besides, we had better add EVERYONE user to the private key management group of the certificate.

    Feel free to let me know if the problem still exists.
    Best Regards

    Friday, February 21, 2020 3:52 AM