IndexerConnector initialization failed for all wazuh-states- indices — Vulnerability Detection not working for Amazon Linux agents

51 views
Skip to first unread message

Rahul Manoj

unread,
May 27, 2026, 5:11:03 AM (11 days ago) May 27
to Wazuh | Mailing List
Description
Vulnerability Detection is not generating alerts or populating the vulnerability inventory for Amazon Linux agents. Ubuntu agents appear to show results. Upon investigating ossec.log on the manager, all wazuh-states-* indexer-connector indices are failing to initialize, including the vulnerability states index.
The CTI feed is confirmed fresh (last_snapshot_at: 2026-05-25), so the feed is not the issue.

Environment
Wazuh version: 4.14.5
Component: Vulnerability Detection / IndexerConnector
Install type: Distributed (Manager and Indexer on separate servers)
Manager OS: Ubuntu
Indexer OS: Separate server ( cluster setup)
Agent OS affected: Amazon Linux 2 / Amazon Linux 2023
Agent OS working: Ubuntu


Logs from /var/ossec/logs/ossec.log
2026/05/27 04:32:15 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-packages-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:15 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-system-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:19 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-processes-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:19 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-ports-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:20 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-hotfixes-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:20 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-hardware-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:21 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-protocols-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:21 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-interfaces-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:21 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-networks-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:22 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-users-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:22 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-groups-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:23 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-browser-extensions-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:23 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-services-siem-log-collector', retrying until the connection is successful.
2026/05/27 04:32:28 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-vulnerabilities-siem-log-collector', retrying until the connection is successful.

Current ossec.conf indexer block
xml<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://a.b.c.d:9200</host>
  </hosts>
  <ssl>
    <certificate_authorities>
      <ca>/etc/filebeat/certs/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
    <key>/etc/filebeat/certs/filebeat-key.pem</key>
  </ssl>
</indexer>
Current vulnerability-detection block
xml<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Miguel Ángel De la Vega Rodríguez

unread,
May 27, 2026, 8:51:40 AM (11 days ago) May 27
to Wazuh | Mailing List
Root cause: IndexerConnector cannot initialize any wazuh-states-* index

  All states indices fail, not just vulnerability. That means the issue is at the connection or
  authentication layer, not package-specific logic.

  Diagnose the actual connection error. The warning you see is a retry loop, the real error is logged earlier. Run:

  grep -i "indexer-connector" /var/ossec/logs/ossec.log | grep -v "retrying" | tail -50

  Look for TLS handshake errors, authentication failures, or connection refused messages.

  Most common causes in distributed setups

  1. Certificate mismatch: The filebeat cert CN or SAN does not include the manager's hostname/IP. The
  indexer rejects the TLS handshake. Verify:
  openssl x509 -in /etc/filebeat/certs/filebeat.pem -noout -text | grep -A1 "Subject Alternative"
  1. The indexer's hostname or IP must appear there.
  2. Wrong CA: The root-ca.pem used by the manager must be the same CA that signed the indexer's
  certificate. Cross-check fingerprints:
  openssl x509 -in /etc/filebeat/certs/root-ca.pem -noout -fingerprint -sha256
  2. Compare with the CA on the indexer node.
  3. No credentials: Your <indexer> block has no <username>/<password>. If the indexer requires basic
  auth alongside mutual TLS, add them:

  <indexer>
    <enabled>yes</enabled>
    <hosts><host>https://a.b.c.d:9200</host></hosts>
    <username>admin</username>
    <password>your_password</password>
    <ssl>...</ssl>
  </indexer>
  4. Index template not loaded — Run this from the manager to check if templates exist:
  curl -k --cert /etc/filebeat/certs/filebeat.pem \
       --key /etc/filebeat/certs/filebeat-key.pem \
       --cacert /etc/filebeat/certs/root-ca.pem \
       https://a.b.c.d:9200/_cat/templates?v | grep wazuh-states
  4. If empty, the index templates were never pushed. Re-run the Wazuh indexer template installation.

  Amazon Linux agents not showing results

  This is almost certainly a consequence of the indexer failure, not a CTI gap. Once
  wazuh-states-vulnerabilities-* initializes successfully, vulnerability inventory will populate for
  Amazon Linux too. Confirm by checking wazuh-modulesd logs after fixing connectivity:

  grep -i "amazon\|vulnerab" /var/ossec/logs/ossec.log | tail -30

  Fix the indexer connection first, then reassess.

Rahul Manoj

unread,
May 28, 2026, 4:20:26 AM (10 days ago) May 28
to Wazuh | Mailing List
Hi Miguel,
i have checked the following suggestions you had provided:
1.  openssl x509 -in /etc/filebeat/certs/filebeat.pem -noout -text | grep -A1 "Subject Alternative" - ran this command in wazuh manager server and it was pointing to indexer IP. made cert changes and now it shows manager IP. restarted wm service and filebeat service after changes.

2. compared CA that is all good.

4. curl -k --cert /etc/filebeat/certs/filebeat.pem \

       --key /etc/filebeat/certs/filebeat-key.pem \
       --cacert /etc/filebeat/certs/root-ca.pem \
       https://a.b.c.d:9200/_cat/templates?v | grep wazuh-states
   
   Regarding the above command, it was giving an empty response. i checked in GUI's settings:  dashboard managemnet > index pattern > wazuh-states-inventory-* and refreshed it and the below error came up:
Error fetching fields for index pattern wazuh-states-inventory-* (ID: wazuh-states-inventory-*)

Error: No matching indices found: No indices match pattern "wazuh-states-inventory-*"
    at https://a.b.c.d.com/414501/bundles/plugin/data/data.plugin.js:3:133662
    at async index_patterns_IndexPatternsService.refreshFields (https://a.b.c.d.com/414501/bundles/plugin/data/data.plugin.js:1:1000349)
    at async https://a.b.c.d.com/414501/bundles/plugin/indexPatternManagement/indexPatternManagement.chunk.1.js:1:236071  



is there any documentation regarding setting up the Wazuh indexer template? can you provide appropriate steps?


Also after the mentioned checks and changes, ossec.log was checked for errors and the issue still persists:


grep -i "amazon\|vulnerab" /var/ossec/logs/ossec.log
2026/05/28 04:32:05 wazuh-modulesd:vulnerability-scanner: INFO: Stopping vulnerability_scanner module.
2026/05/28 04:32:13 wazuh-modulesd:vulnerability-scanner: INFO: Starting vulnerability_scanner module.
2026/05/28 04:32:25 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-vulnerabilities-siem-log-collector', retrying until the connection is successful.
2026/05/28 04:32:26 wazuh-modulesd:vulnerability-scanner: INFO: Vulnerability scanner module started.
2026/05/28 07:37:55 wazuh-modulesd:vulnerability-scanner: INFO: Stopping vulnerability_scanner module.
2026/05/28 07:38:08 wazuh-modulesd:vulnerability-scanner: INFO: Starting vulnerability_scanner module.
2026/05/28 07:38:19 indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-vulnerabilities-siem-log-collector', retrying until the connection is successful.
2026/05/28 07:38:20 wazuh-modulesd:vulnerability-scanner: INFO: Vulnerability scanner module started.

Miguel Ángel De la Vega Rodríguez

unread,
May 29, 2026, 3:48:57 AM (9 days ago) May 29
to Wazuh | Mailing List
The "No matching indices found" and empty curl response are expected symptoms. The wazuh-states-* indices are created automatically by the Wazuh Manager once a successful connection is established.

Here are the steps to resolve the connection issue:

1. Correct the credentials (Wazuh Keystore)
The <indexer> block in ossec.conf does not support <username> and <password> tags. You must store these credentials in the Wazuh keystore instead:

/var/ossec/bin/wazuh-keystore -f indexer -k username -v admin
/var/ossec/bin/wazuh-keystore -f indexer -k password -v 'your_actual_password'

2. Verify certificate permissions
Since the certificates are in /etc/filebeat/certs/, ensure the wazuh user has read permissions to them. If they are restricted to root or filebeat, the Manager won't be able to read the keys:

# Verify permissions
ls -l /etc/filebeat/certs/filebeat-key.pem

# Grant read permission to wazuh group if needed
chown root:wazuh /etc/filebeat/certs/filebeat-key.pem
chmod 640 /etc/filebeat/certs/filebeat-key.pem

3. Enable Debug Mode to see the exact error
If the loop persists after restarting the manager, enable debug mode to see the exact connection error:

- Add this line to /var/ossec/etc/local_internal_options.conf:
wazuh_modules.debug=2

- Restart the manager:
systemctl restart wazuh-manager

- Check the logs for the actual error:
grep -i -E "indexer-connector|vulnerability" /var/ossec/logs/ossec.log | head -n 100

Let me know what exact error appears in the logs after doing this!

Rahul Manoj

unread,
Jun 1, 2026, 2:09:39 AM (6 days ago) Jun 1
to Wazuh | Mailing List
Hi Miguel,
i added the creds to key store and restarted wazuh manager and checked ossec.log:

2026/06/01 04:35:50 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-packages-siem-log-collector.
2026/06/01 04:35:51 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-system-siem-log-collector.
2026/06/01 04:35:56 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-processes-siem-log-collector.
2026/06/01 04:35:56 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-ports-siem-log-collector.
2026/06/01 04:35:56 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-hotfixes-siem-log-collector.
2026/06/01 04:35:56 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-hardware-siem-log-collector.
2026/06/01 04:35:57 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-protocols-siem-log-collector.
2026/06/01 04:35:57 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-interfaces-siem-log-collector.
2026/06/01 04:35:57 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-networks-siem-log-collector.
2026/06/01 04:35:57 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-users-siem-log-collector.
2026/06/01 04:35:57 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-groups-siem-log-collector.
2026/06/01 04:35:58 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-browser-extensions-siem-log-collector.
2026/06/01 04:35:58 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-inventory-services-siem-log-collector.
2026/06/01 04:36:09 indexer-connector: INFO: IndexerConnector initialized successfully for index: wazuh-states-vulnerabilities-siem-log-collector.



i have added a screenshot regarding the vulnerability module events that comes up for amazon linux 202. Regardless of the vulnerability index not being initialized, some events have popped up once in a while; and when checked it was coming up in the alerts index.
could you please explain how vulnerability detection module works along with the syscollector?
does this mean the error we tried to solve is not answering the amazon linux 2023 vulnerability detection issue?
at what intervals are checks for vulnerabilities taking place?
in the screenshot attached logs have popped up on random days but at 00:00 AM and 12:00 PM, but i see no such 12 hour window conf in ossec.conf.
i have added the configurations for vulnerability detection and syscollector here:


  <vulnerability-detection>
    <enabled>yes</enabled>
    <index-status>yes</index-status>
    <feed-update-interval>60m</feed-update-interval>
  </vulnerability-detection>

  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>
    <packages>yes</packages>
    <ports all="yes">yes</ports>
    <processes>yes</processes>
    <users>yes</users>
    <groups>yes</groups>
    <services>yes</services>
    <browser_extensions>yes</browser_extensions>

Please provide some insights.

Thanks & Regards,
Rahul
vuln.png

Miguel Ángel De la Vega Rodríguez

unread,
Jun 2, 2026, 1:44:41 AM (5 days ago) Jun 2
to Wazuh | Mailing List
Hi Rahul,

Great news on the indexer connection being fixed!

To answer your questions, here is a quick overview of how Vulnerability Detection works:
https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html

**Syscollector** collects the agent's package and OS inventory and sends it to the manager every hour (per your config). **Vulnerability Detection** then cross-references that inventory against the CTI feed to find matching CVEs.

- On the **first scan or reconnection**, vulnerabilities are written to the inventory but **no alerts are generated**.
- Alerts are only triggered by **changes** (new packages, OS updates, or newly published CVEs matching existing inventory).

This explains why you saw occasional events in the alerts index, those were change-triggered.

Regarding the **00:00 / 12:00 pattern**, there is nothing in your `ossec.conf` that sets a 12-hour window. Check if there is a cron job or systemd timer restarting the agent or manager on those Amazon Linux hosts at those times.

Now that the `wazuh-states-vulnerabilities-*` index initializes correctly, the vulnerability inventory should populate for Amazon Linux agents within the next Syscollector cycle (~1 hour). Let us know if you still see no results after that!

Best regards,
Miguel
Reply all
Reply to author
Forward
0 new messages