Wazuh agent enrollment failed with SSL error

[Gabriel Alvito]

Hello Wazuh Community,

I have an issue when registering a Wazuh agent from AWS to my Wazuh Manager On Premise using agent-auth.

Environment

• Wazuh Manager: 4.14.5
• Deployment: Docker
• Agent: Linux
• Agent enrollment is performed through a public endpoint with port 1515 exposed.

Command:

/var/ossec/bin/agent-auth -m siem.example.com -p 1515 -A test-agent -P PASSWORD

---

Error

Agent registration fails with:

agent-auth: INFO: Requesting a key from server agent-auth: ERROR: SSL error (5). Connection refused by the manager. SSL routines::unexpected eof while reading

---

Checks performed

• TCP connection to port 1515 is reachable.
• wazuh-authd service is running.
• Port 1515 is listening.
• SSL certificate files exist and are valid.
• Authentication password has been configured correctly.
• Wazuh auth configuration:

<auth> <disabled>no</disabled> <remote_enrollment>yes</remote_enrollment> <port>1515</port> <use_password>yes</use_password> <ssl_auto_negotiate>no</ssl_auto_negotiate> </auth>

Testing with:

openssl s_client -connect siem.example.com:1515

returns:

no peer certificate available SSL handshake has read 0 bytes and written 323 bytes unexpected eof while reading

The TCP connection is established, but the TLS handshake is closed immediately.

---

Question

What could cause wazuh-authd to close the TLS connection immediately during agent enrollment?

Are there any specific Wazuh 4.14.5 configurations required when exposing port 1515 through NAT/reverse forwarding?

Is there any known issue related to Docker deployment and agent-auth SSL handshake?

Thank you.

[Marcel Kemp]

Hi Gabriel,

Firstly, have you followed the Docker installation guide? If not, please check the documentation to ensure everything is set up correctly:

• Deployment on Docker

Next, regarding the issue you’ve reported:

The key piece of information in your report is the openssl s_client output:

SSL handshake has read 0 bytes and written 323 bytes no peer certificate available unexpected eof while reading

Those 323 bytes written are the ClientHello. 0 bytes read means nothing ever answered with a ServerHello — the TCP connection was accepted by something, and that something closed it before sending a single TLS byte. SSL error (5) is SSL_ERROR_SYSCALL, which is consistent with that.

This tells us the failure happens before the TLS handshake, which rules out everything you already checked:

• Password / use_password — validated after the handshake; it would return Invalid password over TLS.
• Manager certificates — if wazuh-authd cannot load its certificate and key, the daemon does not start at all.
• ssl_auto_negotiate no — this only disables SSLv3, TLS 1.0 and TLS 1.1; TLS 1.2 and 1.3 remain available. And a version or cipher mismatch would return a TLS alert, so you would read more than 0 bytes.

So the certificates, the password and the <auth> block are almost certainly not the problem.

Why your reachability test is inconclusive

With the default Docker userland proxy, docker-proxy binds the published port on the host and accepts the TCP connection before connecting to the container. If the backend is not reachable, it closes the accepted connection. That produces exactly what you are seeing: connection established, 0 bytes, EOF.

The same applies to your NAT/reverse forwarding: port 1515 is raw TLS, not HTTP. An nginx server {} block, an ALB, or any L7 proxy will accept the connection and close it as soon as it sees non-HTTP bytes. Per the load balancer documentation, 1515 must be plain TCP passthrough — stream in nginx, mode tcp in HAProxy — with no TLS termination.

Troubleshooting steps

1. Separate the network path from wazuh-authd. Run this from inside the manager container:

docker exec -it wazuh-manager openssl s_client -connect 127.0.0.1:1515

• Returns the manager certificate → wazuh-authd is healthy and the problem is entirely in the path (Docker port publishing, NAT, or the proxy/LB).
• Same EOF → the problem is on the manager itself; continue with steps 2–4.

2. Confirm what is actually listening inside the container:

docker exec wazuh-manager ss -lntp | grep 1515 # expect 0.0.0.0:1515, wazuh-authd docker exec wazuh-manager /var/ossec/bin/wazuh-control status

3. Check the manager log:

docker exec wazuh-manager grep -iE "authd|SSL" /var/ossec/logs/ossec.log | tail -50

4. Enable verbose authd debugging (see internal options):

echo "authd.debug=2" >> /var/ossec/etc/local_internal_options.conf # restart the manager, then retry the enrollment

Then retry and watch ossec.log. This is the step that settles it:

• New connection from <agent public IP> → the ClientHello is reaching wazuh-authd, and the log line right after it (SSL handshake failed for socket=N: <reason>) gives you the exact OpenSSL reason.
• No such line → wazuh-authd never saw the connection. The TCP session is being terminated by docker-proxy, the NAT, or the proxy/load balancer in front, and that is where to fix it.

Possible solutions

1. Use strict L4 passthrough on whatever fronts port 1515 — stream in nginx or mode tcp in HAProxy. No TLS termination, no HTTP proxying. If you are running a cluster, point 1515 at the master node.
2. Verify the Docker port publishing actually reaches the container (-p 1515:1515 on the manager container, and confirm with step 1 above).
3. Do not expose 1515 to the whole internet. Restrict it with a security group / firewall to the networks your agents come from. If your agents are in AWS and the manager is on-premise, an alternative is to enroll through the Wazuh server API on 55000, or to pre-generate and deploy keys, and keep 1515 closed entirely.
4. Raise the idle timeout on the load balancer above the handshake time, and avoid bare TCP health checks against 1515.

Once step 1 or step 4 tells you which side is closing the connection, the fix is usually straightforward. Let us know what you find.