Jump to content

kakolukia91

Members
  • Posts

    3
  • Joined

  • Last visited

About kakolukia91

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    U.K.
  1. Thanks for the suggestion. I've tried to turn AMSI off, but unfortunately the same issue persists. For what it's worth, here's what gets written to the console when I run cscript.exe against the VBScript: E0206 21:00:55.058000000 7936 ssl_transport_security.cc:1455] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
  2. It's a proprietary Windows Service and library we develop, so not something that comes out of the box with Windows. The service runs behind a C++ gRPC server. The library is an ATL COM library that allows it to be used from both .NET and VBScript. The library itself makes client calls to the Windows Service. All works fine without Eset SSL/TLS filtering turned on, and only the VBScript client is affected when the option is turned on.
  3. Hi. I've got the following setup that I'm facing a problem with when SSL/TLS filtering is turned on. This is within a Windows 10 environment. Eset Smart Security Premium A local WIndows Service that uses a self-signed SSL/TLS certificate. The certificate is generated on the fly when the service is started. The generation logic uses an installed certificate from the local computer trusted store to generate a self-signed session certificate. A library that communicates with the local Windows Service using the public key of the installed certificate from the trusted store. A VBScript client that makes use of the library above. The VBScript is hosted by the cscript.exe from C:\Windows\Syswow64 The problem I'm facing is that when the VBScript is run, the SSL/TLS handshake fails when communicating with the Windows Service if Eset SSL/TLS filtering is turned on. What's confusing is that if I create a .NET/C# client that makes use of the same library as the VBScript one, the communication does not fail when Eset SSL/TLS filtering is on. The only difference is that the .NET/C# client is its own executable, whereas the VBScript is hosted within the cscript.exe one. I can workaround the issue by telling Eset to ignore filtering cscript.exe or the certificate in question, but I don't understand why Eset is affecting cscript.exe, but not standard .NET/C# apps? The Eset documentation suggests self-signed certificates should be put in the trusted store, and the root certificate that the session one gets generated from is definitely in the trusted store. Any ideas please? Thanks.
×
×
  • Create New...