Agents cannot connect to ESET Protect server: NodSslWriteEncryptedData: Internal error in the underlying implementations

[Alec Shaner 0]

ESET PROTECT (Server), Version 9.0 (9.0.2144.0)
ESET PROTECT (Web Console), Version 9.0 (9.0.138.0)

I installed ESET PROTECT on a Ubuntu 20.04 server. I created a local deployment all in one installer for Windows using the defaults. I have tried to client PCs, both have successfully installed the ESET AV and the ESET Remote Agent with no errors. The client PCs do not appear in the web console. I don't see anything in the client log files pertaining to this issue, but on my server I keep seeing the following type of entry:

2021-11-22 19:27:12 Error: NetworkModule [Thread 7effebfe6700]: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations., ResolvedIpAddress:xxx.xx.xx.xxx, ResolvedHostname:xxx-xxx-xx-xx-illinois.hfc.comcastbusiness.net, ResolvedPort:50295
2021-11-22 19:27:12 Error: NetworkModule [Thread 7effebfe6700]: Protocol failure for session id 322, error:Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations.

I have opened port 2222 on the server's firewall, and verified that port is accessible. Of course I wouldn't be seeing these errors on the server if it wasn't open.

Other references to this error seem to point to a bad certificate? I just used the default certificates that were created when I installed the remote protect server. The only thing I adjusted was the hostname used by the client to connect (FQDN). Any pointers appreciated.

Thanks

 

[MartinK 384]

Could you please elaborate more on "I adjusted hostname used by the client"? It is crucial that clients are configured to connect to exactly the same hostname as is "signed" in the certificate. This is especially true in case ESET PROTEC's certificate is using specific hostname and not a wildcard (*).

Otherwise this error indicates there is either network error, or TLS handshake is not finished properly - where one of the reasons might be that PROTECT is rejecting client's certificate - therefore more reasonable error might be present in PROTECT's trace.log.

[Alec Shaner 0]

It believe was a case of me being literal with cut & paste in the step by step instructions. I had set the host field of the server certificate in the installation step to "hostname, IP, FQDN".  I created a new server certificate using * as the Host, then changed the server settings to use that custom certificate and now my 2 client computers just showed up in the web console.

Edited November 22, 2021 by Alec Shaner

[MartinK 384]

On 11/22/2021 at 9:48 PM, Alec Shaner said:

It believe was a case of me being literal with cut & paste in the step by step instructions. I had set the host field of the server certificate in the installation step to "hostname, IP, FQDN".  I created a new server certificate using * as the Host, then changed the server settings to use that custom certificate and now my 2 client computers just showed up in the web console.

In that case I would recommend to fetch AGENT's configuration via console and check what hostname they were actually using, so that you can possibly return back or create certificate with specific hostname.