Published June 15, 2026 by

How to Fix Wazuh Certificate Errors

Wazuh certificate errors typically occur when secure TLS communication breaks down between core components of the Wazuh security platform.

These components include the Wazuh manager, agents, indexer, and dashboard, all of which rely on mutual certificate validation to establish trusted communication channels.

When certificates are misconfigured, expired, or not properly distributed, the system cannot verify identities, resulting in failed connections and degraded security monitoring capabilities.

Brief Overview of Wazuh Architecture (Manager, Agents, Indexer, Dashboard)

The Wazuh architecture is composed of several tightly integrated components:

  • Wazuh Manager: Central brain that processes alerts and rules
  • Wazuh Agents: Installed on endpoints to collect logs and telemetry
  • Wazuh Indexer (based on OpenSearch): Stores and indexes security events
  • Wazuh Dashboard: Web interface for visualization and management

Each of these components communicates over TLS using certificates to ensure integrity and authenticity of data.

For more context on how components connect, see:

Why Certificates Are Critical (TLS Encryption Between Components)

Wazuh uses TLS encryption to secure:

  • Agent-to-manager communication
  • Manager-to-indexer communication
  • Dashboard authentication sessions

Certificates provide:

  • Identity verification (mutual TLS authentication)
  • Data confidentiality (encryption in transit)
  • Integrity protection (prevents tampering)

Without valid certificates, Wazuh cannot establish trusted communication channels, effectively breaking the SIEM pipeline.

Common Impact of Certificate Issues

Certificate-related failures can severely disrupt Wazuh operations:

  • Agents failing to connect: Endpoints appear inactive or “never connected”
  • Dashboard login errors: Authentication loops or SSL trust failures
  • Cluster communication breakdown: Indexer or manager nodes stop syncing data

These issues often cascade, leading to blind spots in threat detection and delayed alerting.

Common Wazuh Certificate Errors and Symptoms

 

x509: certificate signed by unknown authority

This error indicates that the certificate chain is not trusted by the receiving component. It usually happens when:

  • The CA certificate is missing
  • Self-signed certificates are not properly installed
  • The trust store is incomplete

certificate has expired or is not yet valid

This occurs when:

  • Certificates are past their expiration date
  • System time is incorrect (future or past skew)
  • New certificates were generated but not deployed correctly

TLS handshake failed

A generic but critical error indicating that secure communication could not be established. Common causes include:

  • Cipher mismatch
  • Invalid certificates
  • Hostname mismatch during verification

unable to verify the first certificate

This typically means the certificate chain is incomplete.

The intermediate CA certificate is missing or not properly bundled.

Agent status showing disconnected or never connected

From a monitoring perspective, this is one of the most visible symptoms:

  • Agents remain in “disconnected” state in the dashboard
  • No logs are received from endpoints
  • Heartbeat communication fails silently

For deeper troubleshooting of agent connectivity, see:

Root Causes of Wazuh Certificate Issues

 

Expired or rotated certificates not updated across components

One of the most common causes is partial certificate rotation:

  • Manager certificate updated but agents not re-enrolled
  • Indexer certificates replaced without dashboard sync
  • CA certificate changed without redeployment

This leads to trust mismatch across the ecosystem.

Incorrect hostname or FQDN mismatch

TLS validation strictly checks hostname identity. Errors occur when:

  • Certificate CN/SAN does not match actual hostname
  • IP address used instead of FQDN
  • Load balancer or proxy alters expected hostname

Misconfigured ossec.conf or indexer settings

Improper configuration can break certificate validation:

  • Wrong CA path in configuration files
  • Missing SSL/TLS parameters
  • Incorrect cluster endpoints in indexer config

 Time drift between nodes (NTP issues)

TLS certificates rely on accurate system time. If nodes are out of sync:

  • Certificates may appear “not yet valid”
  • Expired certificates may still appear valid on other nodes

Best practice is enforcing NTP synchronization across all Wazuh nodes.

Missing CA certificate on agents

Agents must trust the same CA used by the manager. If missing:

  • TLS handshake fails immediately
  • Agent cannot register or communicate

 Improper cluster certificate distribution

In distributed setups:

  • Indexer nodes must share consistent certificates
  • Dashboard and manager must trust the same CA chain
  • Partial rollout causes intermittent failures

References

 

How Wazuh Certificate Architecture Works (Quick Overview)

Understanding how Wazuh certificates are used throughout the platform makes troubleshooting significantly easier.

Most certificate-related issues occur because one component no longer trusts another component’s certificate or because a certificate has expired.

Role of the Root CA

At the center of Wazuh’s TLS infrastructure is the Root Certificate Authority (CA).

The Root CA serves as the trusted authority that signs certificates used throughout the environment.

Every component must trust this CA in order to establish secure communication.

The Root CA is responsible for:

  • Signing manager certificates
  • Signing indexer certificates
  • Signing dashboard certificates
  • Verifying the authenticity of participating nodes

If the Root CA changes and components are not updated accordingly, certificate validation errors will occur immediately.

According to the National Institute of Standards and Technology (NIST), a properly managed certificate authority is a foundational component of secure TLS deployments and trust management.

Manager Certificates vs Agent Certificates

Wazuh managers and agents use certificates differently.

Manager Certificates

The manager presents its certificate to agents so they can verify they are communicating with a legitimate server.

These certificates are used for:

  • Agent registration
  • Secure event transmission
  • Authentication of management services

Agent Certificates

Depending on your deployment model, agents may also use certificates or enrollment keys to authenticate themselves to the manager.

Certificate issues affecting agents commonly result in:

  • Registration failures
  • Disconnected agent status
  • TLS handshake errors
  • Event forwarding failures

If agents are completely unable to connect, you may also want to review:

Dashboard and Indexer TLS Communication

The Wazuh dashboard communicates with the Wazuh indexer over encrypted TLS connections.

During startup:

  1. The dashboard validates the indexer certificate.
  2. The indexer validates incoming requests.
  3. Both components establish a trusted TLS session.

If either side cannot validate the certificate chain, you may encounter:

  • Dashboard login failures
  • “Unable to connect to Indexer” errors
  • SSL verification exceptions
  • Failed API requests

This is particularly common after certificate renewals or migrations.

Common Wazuh Certificate Locations

Depending on the deployment type and version, certificates are typically stored in several locations.

Wazuh Manager

/var/ossec/etc/

Common files include:

root-ca.pem
manager.pem
manager-key.pem

Filebeat (Legacy Deployments)

Some deployments still utilize Filebeat for forwarding data.

Certificate locations may include:

/etc/filebeat/

Examples:

root-ca.pem
filebeat.pem
filebeat-key.pem

 Wazuh Indexer

Indexer certificates are commonly stored in locations such as:

/etc/wazuh-indexer/certs/

Files often include:

root-ca.pem
indexer.pem
indexer-key.pem
admin.pem
admin-key.pem

Wazuh Dashboard

Dashboard TLS assets are commonly stored under:

/etc/wazuh-dashboard/certs/

Examples:

dashboard.pem
dashboard-key.pem
root-ca.pem

Always verify paths against your installed Wazuh version since directory structures may vary between releases.

For official certificate deployment guidance, consult the Wazuh documentation.

Step-by-Step Fix for Wazuh Certificate Errors

 

 Verify Current Certificate Status

Before replacing certificates, determine whether the existing certificates are still valid.

Check Certificate Expiration

Use OpenSSL to view certificate validity dates:

openssl x509 -in cert.pem -noout -dates

Example output:

notBefore=Jan 10 00:00:00 2025 GMT
notAfter=Jan 10 00:00:00 2026 GMT

Pay close attention to the notAfter field, which indicates expiration.

Validate the Certificate Chain

Verify that the certificate was issued by a trusted CA:

openssl verify -CAfile root-ca.pem cert.pem

Successful output:

cert.pem: OK

Failures often indicate:

  • Missing CA certificates
  • Broken certificate chains
  • Incorrectly signed certificates

 Inspect Certificate Details

You can also inspect certificate metadata:

openssl x509 -in cert.pem -text -noout

Review:

  • Common Name (CN)
  • Subject Alternative Names (SAN)
  • Issuer
  • Validity dates

Hostname mismatches are a frequent cause of TLS failures.

 Check System Time Synchronization

TLS validation depends on accurate system clocks.

If one node’s time is incorrect, certificates may appear expired or not yet valid.

Verify Current Time

timedatectl

Review:

  • Current system time
  • Time zone
  • NTP synchronization status

Confirm NTP Synchronization

On most Linux distributions:

timedatectl status

You should see:

System clock synchronized: yes

Correct Time Drift

If synchronization is disabled:

sudo timedatectl set-ntp true

In larger environments, ensure all:

  • Managers
  • Agents
  • Dashboard nodes
  • Indexer nodes

are synchronized to the same trusted NTP source.

Regenerate Wazuh Certificates

If certificates are expired, corrupted, or improperly configured, regeneration is usually the fastest solution.

 Use the Wazuh Certificate Generation Tool

Modern Wazuh deployments provide certificate generation utilities that automate certificate creation.

Common workflow:

  1. Generate a new Root CA.
  2. Generate manager certificates.
  3. Generate indexer certificates.
  4. Generate dashboard certificates.
  5. Generate agent certificates when necessary.

Always back up existing certificates before proceeding.

Regenerate the Root CA

A new Root CA establishes a fresh trust chain across the environment.

Because all certificates depend on the Root CA, replacing it typically requires updating every participating component.

 Regenerate Manager Certificates

Manager certificates should contain:

  • Correct hostname
  • Proper FQDN
  • Current IP information

Failure to include the correct host identity often results in hostname validation errors.

Regenerate Agent Certificates (If Required)

In environments using agent-side certificates, regenerate and redistribute certificates to affected endpoints.

This is particularly important when:

  • Rotating the Root CA
  • Migrating managers
  • Rebuilding infrastructure

Replace Certificates on All Components

After generating new certificates, deploy them consistently.

Update the Wazuh Manager

Replace:

manager.pem
manager-key.pem
root-ca.pem

Verify ownership and permissions afterward.

 Update the Wazuh Indexer

Replace:

indexer.pem
indexer-key.pem
root-ca.pem

Ensure every node in the cluster receives the correct files.

Improper distribution is a common source of cluster communication failures.

Update the Wazuh Dashboard

Replace:

dashboard.pem
dashboard-key.pem
root-ca.pem

Confirm that dashboard configuration files reference the new certificate locations.

 Verify Permissions

Certificates should typically be readable only by the services that require them.

Example:

chown wazuh:wazuh cert.pem
chmod 640 cert.pem

Incorrect permissions can cause startup failures that resemble certificate problems.

Restart Wazuh Services

After replacing certificates, restart affected services.

Restart the Wazuh Manager

systemctl restart wazuh-manager

Check service status:

systemctl status wazuh-manager

 Restart the Wazuh Indexer

systemctl restart wazuh-indexer

Verify:

systemctl status wazuh-indexer

Restart the Wazuh Dashboard

systemctl restart wazuh-dashboard

Confirm successful startup:

systemctl status wazuh-dashboard

After restarting, review logs for any remaining TLS or certificate validation errors.

Fixing Agent-Specific Certificate Errors

Agent-related certificate issues are among the most common Wazuh connectivity problems.

These usually appear after certificate rotation, manager migration, or enrollment key changes.

Re-Enrolling Agents Using a New Key

When manager certificates change significantly, existing agent trust relationships may no longer be valid.

Re-enrolling the agent establishes a new trusted connection.

Typical workflow:

  1. Generate a new enrollment key.
  2. Deploy the key to the endpoint.
  3. Re-register the agent.
  4. Verify successful authentication.

Removing Old Agent Entries

Sometimes the manager retains outdated agent information that conflicts with new certificates.

List agents:

/var/ossec/bin/manage_agents

Remove obsolete entries before re-registering.

This prevents:

  • Duplicate IDs
  • Authentication conflicts
  • Enrollment failures

Re-Registering the Agent with the Manager

After cleanup, register the agent again using the appropriate enrollment method.

Verify:

  • Manager hostname is correct
  • Certificate trust chain is present
  • Required ports are open
  • Agent configuration references the correct manager

Validating Agent Connectivity Logs

Review logs on both sides to confirm successful communication.

Manager logs:

/var/ossec/logs/ossec.log

Agent logs:

/var/ossec/logs/ossec.log

Look for indicators such as:

Connected to manager
Agent started
TLS connection established

Avoid continuing until all certificate-related warnings have been resolved.

For additional troubleshooting guidance, see:

 Fixing Dashboard and Indexer TLS Errors

When certificate problems occur between the Wazuh Dashboard and Wazuh Indexer, users often encounter login failures, API connectivity issues, missing visualizations, or messages indicating that the dashboard cannot communicate with the indexer.

Because the dashboard relies on secure TLS communication with the indexer, even minor certificate misconfigurations can prevent the entire web interface from functioning correctly.

Verify Indexer TLS Settings in opensearch.yml

The Wazuh Indexer (based on OpenSearch) uses TLS settings defined in its configuration file.

Common location:

/etc/wazuh-indexer/opensearch.yml

Review settings such as:

plugins.security.ssl.transport.pemcert_filepath
plugins.security.ssl.transport.pemkey_filepath
plugins.security.ssl.transport.pemtrustedcas_filepath

plugins.security.ssl.http.enabled
plugins.security.ssl.http.pemcert_filepath
plugins.security.ssl.http.pemkey_filepath
plugins.security.ssl.http.pemtrustedcas_filepath

Verify that:

  • All certificate files exist
  • Paths are correct
  • Certificates have not expired
  • The trusted CA matches the certificates being used

A mismatch between the configured CA and the active certificates is one of the most common causes of indexer TLS failures.

 Check Dashboard Configuration

The dashboard must trust the same CA that signed the indexer’s certificate.

Common dashboard configuration locations include:

/etc/wazuh-dashboard/opensearch_dashboards.yml

or

/etc/wazuh-dashboard/config/

Review settings similar to:

opensearch.ssl.certificateAuthorities
opensearch.ssl.verificationMode
opensearch.hosts

Verify:

  • The correct CA certificate is referenced
  • Hostnames match certificate SAN entries
  • Indexer endpoints use the correct FQDN

 Ensure the Correct CA Trust Chain Is Installed

A frequent cause of the error:

unable to verify the first certificate

is an incomplete certificate chain.

Confirm that:

  • Root CA certificates are installed
  • Intermediate certificates are present
  • The full chain is referenced by dashboard and indexer services

You can inspect the chain with:

openssl x509 -in certificate.pem -text -noout

or

openssl verify -CAfile root-ca.pem certificate.pem

Verify Dashboard-to-Indexer Connectivity

Test TLS communication directly from the dashboard server:

openssl s_client -connect indexer.example.com:9200

Successful output should show:

Verify return code: 0 (ok)
Any other result usually indicates a trust, hostname, or certificate chain problem.

Debugging Tools and Commands

When troubleshooting certificate issues, several built-in Linux and OpenSSL tools can quickly identify the root cause.

 Review Wazuh Manager Logs

The Wazuh Manager log file is the first place to look for TLS-related failures.

cat /var/ossec/logs/ossec.log

Common errors include:

TLS handshake failed
certificate verification failed
unable to get local issuer certificate

This log is invaluable when diagnosing agent-to-manager certificate problems.

 Check Systemd Service Logs

Use systemd journals to identify startup failures related to certificates.

Manager:

journalctl -u wazuh-manager -xe

Indexer:

journalctl -u wazuh-indexer -xe

Dashboard:

journalctl -u wazuh-dashboard -xe

Look for:

  • TLS initialization failures
  • Certificate loading errors
  • Permission issues
  • Invalid certificate paths

Test TLS Connectivity with OpenSSL

OpenSSL can verify whether a service presents a valid certificate.

Example:

openssl s_client -connect localhost:9200

Review:

  • Certificate issuer
  • Certificate validity
  • Verification return code

If verification fails, the output often identifies the exact problem.

 Test HTTPS Endpoints Using Curl

Curl provides a quick method for validating HTTPS connectivity.

Example:

curl -k https://localhost:9200

If communication succeeds, the service is running and reachable.

For stricter validation:

curl --cacert root-ca.pem https://localhost:9200

This confirms that the CA trust chain is functioning properly.

 Review Indexer Logs

Indexer logs often contain the most detailed certificate diagnostics.

Common locations include:

/var/log/wazuh-indexer/

or

/usr/share/wazuh-indexer/logs/

Search for messages related to:

SSLException
certificate_unknown
trust anchor not found
hostname verification failed

These messages frequently pinpoint the exact TLS failure.

 Best Practices to Prevent Certificate Issues

Certificate problems are far easier to prevent than to troubleshoot.

Implementing a few operational best practices can eliminate the majority of TLS-related outages.

Automate Certificate Rotation

Manual certificate renewals often lead to missed updates and expired certificates.

Whenever possible:

  • Automate certificate generation
  • Automate deployment
  • Automate renewal notifications

Organizations that automate certificate management typically experience fewer service disruptions and reduced operational risk.

Monitor Certificate Expiration Dates

Many outages occur simply because administrators forget certificate expiration dates.

Consider implementing monitoring that alerts when certificates are approaching expiration:

  • 90 days remaining
  • 60 days remaining
  • 30 days remaining

Tools such as OpenSSL, Prometheus exporters, and enterprise certificate monitoring platforms can automate these checks.

Additional Resources:

Let’s Encrypt Certificate Expiration Monitoring Guidance

Use Consistent FQDNs Across Infrastructure

Certificate validation depends heavily on hostname consistency.

Avoid mixing:

  • IP addresses
  • Short hostnames
  • Fully qualified domain names (FQDNs)

Instead, standardize on FQDNs throughout:

  • Manager configuration
  • Agent configuration
  • Dashboard configuration
  • Indexer configuration

This greatly reduces hostname mismatch errors.

Synchronize Time Using NTP Everywhere

Time drift remains one of the most overlooked causes of certificate failures.

All systems should synchronize against trusted NTP servers, including:

  • Wazuh managers
  • Agents
  • Dashboard nodes
  • Indexer nodes

Document Certificate Lifecycle Procedures

Every production environment should maintain documentation covering:

  • Certificate issuance
  • Certificate renewal
  • Certificate revocation
  • Certificate deployment
  • Emergency recovery procedures

Documented processes reduce operational errors and accelerate troubleshooting when issues arise.

Regularly Validate Certificates

Don’t wait until services fail.

Schedule periodic validation checks:

openssl verify -CAfile root-ca.pem manager.pem

and

openssl x509 -in manager.pem -noout -dates

Routine validation often identifies problems before they impact production systems.

Conclusion

Wazuh certificate errors are typically caused by a handful of common issues, including expired certificates, broken trust chains, hostname mismatches, time synchronization problems, and incomplete certificate deployments.

Fortunately, most of these issues can be resolved through a systematic troubleshooting process:

  • Verify certificate validity
  • Confirm trust chains
  • Check system time synchronization
  • Regenerate certificates when necessary
  • Deploy certificates consistently across all components
  • Validate TLS communication using OpenSSL and Curl

For organizations running Wazuh in production environments, proactive certificate management is essential.

Automated certificate rotation, expiration monitoring, documented procedures, and regular validation checks can significantly reduce the likelihood of outages caused by TLS failures.

To continue improving the reliability and security of your Wazuh deployment, you may also find these guides helpful:

By treating certificate management as an ongoing operational process rather than a one-time setup task, you can ensure secure communication between all Wazuh components and avoid many of the most common connectivity and authentication issues.

DevOps

Wazuh

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *