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.