Error changing the selected API - wazuh-dashboard

[Denis Grilli]

Hi all, 

My installation of wazuh includes 2 indexer server and 4 wazuh manager servers.
Dashboard is installed on the wazuh indexer server and it used to work fine.

Recently, when I try to switch the API server (top right corner) between wazuh manager servers I got the following error:

Error changing the selected API
Error: 1000 - Unexpected error at ApiCheck.returnErrorInstance (https://wazuh-dashboard.gmsl.gasops.co.uk/414303/bundles/plugin/wazuh/wazuh.plugin.js:1:553660) at ApiCheck.checkApi (https://wazuh-dashboard.gmsl.gasops.co.uk/414303/bundles/plugin/wazuh/wazuh.plugin.js:1:553372) at async https://wazuh-dashboard.gmsl.gasops.co.uk/414303/bundles/plugin/wazuh/wazuh.chunk.2.js:1:3302099
Only 1 of the 4th wazuh manager server works, anyone can suggest how to troubleshoot this? I couldn't find any obvious error in the indexer / dashboard except for the one above.

Thanks in advance 

[Federico Gustavo Caffieri]

It would help to understand your environment a bit better and gather some diagnostic info in order to help you.

- Which of the 4 manager servers is the one that works? Is it your cluster master node?
- Did anything change recently in your environment — updates, certificate renewals, network/firewall changes, or did you re-add the API entries manually?
- Are the 4 API entries in the dashboard (Mennu > Settings > API) pointing to each manager's individual IP/hostname, or through a load balancer?

Execute these commands on each of the failing manager nodes:

- Check if the Wazuh manager and API are running:
```
systemctl status wazuh-manager
```

- Check if the API is actually listening on port 55000:
```
ss -tlnp | grep 55000
```

- Test the API directly from the dashboard server (replace with each manager's IP):
```
curl -k -X GET "https://<MANAGER_IP>:55000/" \
  -u <USER>:<PASSWORD>
```

- Check the API log for errors on the failing nodes:
```
tail -100 /var/ossec/logs/api.log
```

One thing to check in the meantime:

If the working API entry is your cluster master node, that may be expected behavior — the Wazuh API sits on the master node, and certain cluster-wide operations can only be served from there. Worker nodes do run their own API, but depending on your Wazuh version and how the dashboard plugin handles multi-API setups, connecting directly to a worker may fail for specific checks.
You can check these [discussions](https://github.com/wazuh/wazuh/discussions/14192)

[Denis Grilli]

Thanks for your reply.

My setup is using wazuh 4.14.3 and is formed by
two indexer node in a cluster

4 manager nodes in a cluster

dashboard installed in the indexer nodes

And you are right the only worker node is the master one 

workerX:~# /var/ossec/bin/cluster_control -l
NAME      TYPE    VERSION  ADDRESS
worker1     master  4.14.3 
worker2   worker  4.14.3   
worker3  worker  4.14.3   
worker4   worker  4.14.3

All the test you suggested are successfully so I can connect to any worker on port 55000 correctly. The api log reports only one line when I try to switch node in the dashboard:

2026/02/23 15:38:55 INFO: wazuh-wui <worker2 ip> "GET /manager/info" with parameters {} and body {} done in 0.061s: 200

The error is showing when I am in the overview page (and trying to switch node) but also when I go to the Server APIs page (under Dashboard management section) where it shows the correct API version installed but cannot check if an update is required.

I am sure it was working before but not sure when it stopped (probably after an update).

Please, let me know if you have any other check I can do to provide more information. 

[Federico Gustavo Caffieri]

The fact that `/manager/info` returns 200 on all workers tells us that the basic API connection and authentication are working fine.
The error 1000 is triggered by the dashboard plugin itself after that initial check, which means something is failing in a subsequent step that isn't visible in the manager's api.log.

We need two things:

1. The dashboard server logs, these will show what the plugin is actually failing on:

journalctl -u wazuh-dashboard | grep -i -E "error|warn" | tail -100

2. Browser developer tools — when you try to switch to a failing worker, open DevTools (F12) > Network tab, reproduce the error, and look for any request that returns a non-200 status code after the /manager/info call. Share the failing request URL and response body.

One thing to verify in the meantime, the API configuration file (/var/ossec/api/configuration/api.yaml) is NOT automatically synced from the master to worker nodes; each node keeps its own copy. If any changes were made to the master's api.yaml during or after the upgrade, those changes would need to be manually replicated to each worker. Can you compare the api.yaml file across all four nodes?

[Denis Grilli]

Hi Federico, thanks again for your useful and very detailed reply.

From the wazuh dashboard journal I got the following error:

Mar 02 08:54:55 wazuh-dashboard opensearch-dashboards[1177]: {"type":"error","@timestamp":"2026-03-02T08:54:55Z","tags":[],"pid":1177,"level":"error","error":{"message":"Internal Server Error","name":"Error","stack":"Error: Internal Server Error\n    at HapiResponseAdapter.toError (/usr/share/wazuh-dashboard/src/core/server/http/router/response_adapter.js:127:19)\n    at HapiResponseAdapter.toHapiResponse (/usr/share/wazuh-dashboard/src/core/server/http/router/response_adapter.js:83:19)\n    at HapiResponseAdapter.handle (/usr/share/wazuh-dashboard/src/core/server/http/router/response_adapter.js:79:17)\n    at Router.handle (/usr/share/wazuh-dashboard/src/core/server/http/router/router.js:175:34)\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at handler (/usr/share/wazuh-dashboard/src/core/server/http/router/router.js:140:50)\n    at exports.Manager.execute (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/toolkit.js:60:28)\n    at Object.internals.handler (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/handler.js:46:20)\n    at exports.execute (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/handler.js:31:20)\n    at Request._lifecycle (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/request.js:371:32)\n    at Request._execute (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/request.js:281:9)"},"url":"https://wazuh-dashboard.gmsl.gasops.co.uk/api/check-api","message":"Internal Server Error"}

Which is also confirm by the developers tool which shows a status 500 for the call to "https://wazuh-dashboard.gmsl.gasops.co.uk/api/check-api"

Regards,

Denis

[Federico Gustavo Caffieri]

Thank you for your patience. The error 500 indicates that the problem lies within the dashboard plugin handler itself; that's why we're not seeing any related logs in `api.log`.

There are two possible causes:

- SSL certificate mismatch: each node generates its own self-signed certificate. If the worker's certificate CN/SAN doesn't match the URL configured in `wazuh.yml`, it will throw an unhandled exception. See [Securing the Wazuh server API](https://documentation.wazuh.com/current/user-manual/api/securing-api.html).
- `wazuh.yml` misconfiguration: if `run_as: true` is set for a worker entry but the impersonation user isn't properly configured, the handler will also crash. See [Wazuh dashboard settings](https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/settings.html).

Please run the following:

1. Show the `wazuh.yml` API entries (please avoid sending sensitive information):

```bash
cat /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
```

2. Check the SSL certificate SAN on each failing worker:

```bash
openssl x509 -in /var/ossec/api/configuration/ssl/server.crt -noout -text \
  | grep -A5 "Subject Alternative\|Subject:"
```

3. Test the connection from the dashboard server without skipping SSL verification:

```bash
curl -X POST "https://<WORKER_IP>:55000/security/user/authenticate?raw=true" \
  -u <USER>:<PASSWORD> \
  --cacert /var/ossec/api/configuration/ssl/server.crt
```

If curl fails with an SSL error on the workers but succeeds on the master, that confirms the certificate mismatch. The fix would be to regenerate the API SSL certificate on each worker, including the correct IP/hostname, or configure the `wazuh.yml` entries to match the certificate's CN/SAN exactly.

If the SSL test passes cleanly, share the `wazuh.yml` output, and we'll look at the `run_as` configuration next.

[Denis Grilli]

Hi Federico,

certificates are all issued in the following way:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:4b:28:df:6c:07:3d:a0:28:d2:d2:e0:fa:6f:b9:df:8d:72:6c:1f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = San Francisco, O = Wazuh, CN = wazuh.com
        Validity
            Not Before: Jan 30 11:20:41 2025 GMT
            Not After : Jan 30 11:20:41 2026 GMT
        Subject: C = US, ST = California, L = San Francisco, O = Wazuh, CN = wazuh.com
[....]

            X509v3 Subject Alternative Name:
                DNS:localhost

All the workers included the one is working has a similar certificate and they are all expired.
in the wazuh.yml we are using the ip address instead of a name.

So at this point I was expecting for all worker including the master to fail but I happy to replace all the certificates with a valid one and with the proper Subject Alternative name if you can share some instructions.

As for the curl command I couldn't run it because in the dashboard machine there is no /var/ossec/api/configuration/ssl/server.crt, perhaps the ca cert is stored somewhere else.