Jump to content

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


Alec Shaner
 Share

Recommended Posts

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

 

Link to comment
Share on other sites

  • ESET Staff

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.

Link to comment
Share on other sites

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 by Alec Shaner
Link to comment
Share on other sites

  • ESET Staff
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...