How to Configure Wazuh SSL

Secure communication is a foundational part of a Wazuh deployment. Wazuh components exchange security events, API requests, configuration data, and authentication information across multiple network connections. Without TLS protection, sensitive data moving between these components could be exposed or modified in transit. Although the term Wazuh SSL is commonly used, modern Wazuh deployments primarily use TLS (Transport Layer Security) rather than the older SSL protocols.

TLS provides encryption, certificate-based identity verification, and protection against tampering.

Wazuh’s architecture includes several services that communicate over encrypted connections.

The Wazuh Dashboard communicates with the Wazuh Indexer and Wazuh server API, while components such as Filebeat and the Wazuh indexer connector securely forward data to the Indexer.

Wazuh’s architecture documentation confirms that Dashboard-to-server API communication is encrypted with TLS, while the Indexer API uses HTTPS by default.

Why SSL/TLS is important in Wazuh

TLS protects Wazuh traffic in three important ways:

Confidentiality: Encrypts data so unauthorized parties cannot easily read it while it travels across the network.
Integrity: Helps prevent an attacker from modifying data in transit without detection.
Authentication: Certificates allow systems to verify the identity of the remote service they are connecting to.

This is particularly important for a SIEM/XDR platform because Wazuh can process authentication events, system logs, security alerts, vulnerability information, and other potentially sensitive telemetry.

NIST’s Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations provides formal guidance for securely configuring TLS, including recommendations concerning TLS versions, cryptographic algorithms, certificates, and TLS extensions.

For Wazuh specifically, the official documentation states that HTTPS is enabled for the Wazuh Indexer API by default and recommends CA-signed certificates instead of self-signed certificates, particularly when the Indexer is accessible from the internet.

Components that use SSL/TLS

Depending on the architecture and configuration, TLS can protect communication involving:

Wazuh Manager
Wazuh Agents
Wazuh Indexer
Wazuh Dashboard
Filebeat
Wazuh indexer connector
APIs and HTTPS endpoints
Reverse proxies such as NGINX

The exact certificate requirements depend on which communication path is being secured.

For example, the Dashboard requires certificates for its HTTPS interface and also needs to trust the CA used by the Indexer.

Filebeat can use a CA certificate to verify the Wazuh Indexer’s HTTPS certificate.

Related Guide: How to Fix Wazuh Certificate Errors

What this guide covers

This guide explains the concepts behind Wazuh SSL/TLS before moving into configuration and troubleshooting.

It covers:

What Wazuh SSL/TLS means
How certificates work within Wazuh
The role of certificate authorities
Wazuh Manager, Indexer, and Dashboard certificates
Agent-to-manager encryption
Server and client certificates
Certificate chains and trust relationships
Mutual TLS
SSL/TLS verification
Certificate configuration and replacement
Common Wazuh SSL errors
Certificate testing and troubleshooting
Certificate renewal and security best practices

The goal is not simply to make Wazuh use HTTPS.

A correctly configured Wazuh TLS environment should establish a verifiable chain of trust between the systems communicating with one another.

What Is Wazuh SSL?

Wazuh SSL generally refers to the SSL/TLS certificates and encrypted communication mechanisms used to secure Wazuh components.

Technically, SSL is the predecessor to TLS. SSL 2.0 and SSL 3.0 are obsolete and should not be used.

Therefore, when administrators talk about configuring “Wazuh SSL,” they are generally configuring TLS certificates and TLS-secured connections.

Wazuh’s current documentation uses terms such as SSL certificates, HTTPS, TLS, certificate authorities, and certificate verification depending on the component being configured.

Wazuh SSL and TLS explained

TLS creates a secure channel between two systems.

A simplified TLS connection works like this:

A client connects to a Wazuh service.
The service presents its TLS certificate.
The client checks whether the certificate can be trusted.
The client verifies certificate properties such as validity and identity.
Cryptographic parameters are negotiated.
The systems establish an encrypted session.
Application data is exchanged through that encrypted channel.

The certificate itself does not encrypt all application traffic.

Instead, it helps establish trust and participates in the cryptographic handshake that creates the secure session.

This distinction is important when troubleshooting Wazuh SSL problems.

A connection can fail because of an invalid certificate even when the underlying Wazuh service is running normally.

How Wazuh uses certificates

Certificates provide identity information for Wazuh services and establish a chain of trust.

Wazuh’s certificate deployment documentation describes three important certificate categories used during installation:

Root CA: The certificate authority responsible for signing other certificates.
Node certificates: Certificates used by Wazuh Indexer nodes.
Admin certificate: A client certificate with elevated privileges for certain management and security operations.

Wazuh’s certificate-generation process can create certificates for Indexer nodes, Wazuh server nodes, and Dashboard nodes.

The generated certificates contain identifying information such as node names and IP addresses or DNS names.

This creates a basic trust hierarchy:

                    Root CA
                       |
        +--------------+--------------+
        |              |              |
   Manager cert   Indexer cert   Dashboard cert
        |              |              |
     Manager        Indexer       Dashboard

The exact certificate architecture can vary depending on the Wazuh version and deployment topology, but the underlying principle remains the same: services need certificates and trusted CA material that allow the receiving side to verify those certificates.

Wazuh Manager SSL

The Wazuh Manager participates in several secure communication paths.

One important path involves communication between the manager and the Wazuh Indexer.

Wazuh’s indexer integration supports HTTPS connections and allows the manager’s indexer connector to specify a CA certificate, client certificate, and private key.

For example, an Indexer configuration can contain SSL parameters similar to:

<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>

The important concept is that the manager needs to know which CA it should trust and, where client authentication is required, which certificate and private key it should present.

Manager-side TLS configuration therefore needs to be considered separately from the HTTPS certificate users see when opening the Dashboard.

Wazuh Indexer SSL

The Wazuh Indexer is a particularly important TLS endpoint because it stores and serves security data.

The Indexer exposes an HTTPS API and uses TLS to protect API communication.

Wazuh states that HTTPS is enabled by default and that the certificates generated during installation provide this encryption.

Administrators can replace those certificates with their own certificates.

The Indexer also uses certificates for internal secure communication.

In a multi-node deployment, TLS configuration becomes especially important because the nodes need to establish trusted communication with each other.

Related Guide: How to Build a Wazuh Indexer Cluster

A typical secure architecture looks like:

Wazuh Manager
      |
      | HTTPS / TLS
      v
Wazuh Indexer
      ^
      |
      | HTTPS / TLS
      |
Wazuh Dashboard

In a clustered environment, additional TLS-protected communication exists between Indexer nodes.

Wazuh Dashboard SSL

The Wazuh Dashboard is the component most users associate with SSL because it provides the browser-accessible HTTPS interface.

The Dashboard can use certificates generated during Wazuh installation, or administrators can configure third-party certificates.

Wazuh officially documents using third-party certificates, including Let’s Encrypt certificates, and also documents placing NGINX in front of the Dashboard to handle SSL termination.

For example, a Dashboard configuration can specify:

server.ssl.enabled: true
server.ssl.key: "/etc/wazuh-dashboard/certs/privkey.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/fullchain.pem"

The Dashboard also needs to verify its connection to the Wazuh Indexer. Its configuration can therefore include a CA file for validating the Indexer’s certificate:

opensearch.ssl.certificateAuthorities:
  - "/etc/wazuh-dashboard/certs/root-ca.pem"

Wazuh’s official documentation provides this type of configuration when replacing the default Dashboard certificates with Let’s Encrypt certificates.

Agent-to-manager encryption

Wazuh agents communicate with the Wazuh Manager to send collected security data and receive configuration or management instructions.

The agent connection service uses TCP port 1514 by default, while agent enrollment commonly uses TCP port 1515.

TLS and certificate configuration can become relevant when an agent needs to establish a trusted encrypted connection with its manager.

Common agent-side symptoms of TLS or certificate problems include:

Agent remains disconnected
Agent registration fails
TLS handshake errors appear in logs
Certificate verification fails
Manager hostname cannot be validated
Communication stops after certificate rotation

Certificate problems should be distinguished from enrollment authentication problems.

Wazuh agent enrollment can involve authentication keys and registration mechanisms, while TLS certificates provide cryptographic trust for the communication channel.

Difference between SSL certificates and Wazuh authentication

SSL/TLS and Wazuh authentication are related but are not the same thing.

A useful way to think about the distinction is:

Security mechanism	Primary purpose
TLS certificate	Establishes cryptographic identity and trust
Private key	Proves possession of the private half of a certificate key pair
CA certificate	Establishes which certificate issuers are trusted
Wazuh authentication	Determines whether a user, agent, or service is authorized to connect
RBAC	Determines what an authenticated user can access or modify

For example, a user could successfully authenticate to the Wazuh Dashboard but still experience a TLS problem when the Dashboard attempts to communicate with the Indexer.

Conversely, a TLS handshake can succeed while an application-level authentication request fails because the supplied credentials are invalid.

This distinction is essential when diagnosing Wazuh errors.

TLS answers “Can I establish a trusted encrypted connection?” Authentication answers “Who are you?” Authorization answers “What are you allowed to do?”

How Wazuh SSL/TLS Works

Understanding the TLS trust model makes Wazuh SSL configuration considerably easier to troubleshoot.

A Wazuh deployment can contain several independent TLS relationships rather than one universal SSL connection.

Each relationship has a client, a server, certificates, trusted CA material, and potentially client-side certificates.

A simplified architecture looks like this:

                         Root CA
                           |
             +-------------+-------------+
             |             |             |
          Manager       Indexer       Dashboard
             |             |             |
             +-------------+-------------+
                           |
                      Trusted PKI

The actual traffic paths then depend on the deployment:

Agents
   |
   | Secure communication
   v
Wazuh Manager
   |
   | HTTPS / TLS
   v
Wazuh Indexer
   ^
   |
   | HTTPS / TLS
   |
Wazuh Dashboard

Wazuh Manager, Indexer, and Dashboard communication

The Wazuh Dashboard communicates with both the Wazuh server API and the Wazuh Indexer.

According to Wazuh’s architecture documentation, the Dashboard queries the Wazuh server API for configuration and status information, with that communication encrypted using TLS.

The Dashboard also queries the Wazuh Indexer to visualize indexed security data.

The Wazuh Manager also communicates with the Indexer through secure data-forwarding mechanisms.

Wazuh documents both Filebeat and the Wazuh Indexer connector as components involved in forwarding data from the manager to the Indexer.

This means a Wazuh deployment can have multiple independent TLS failure points.

For example:

Browser
   |
   | HTTPS
   v
Dashboard
   |
   | HTTPS
   v
Indexer

Dashboard
   |
   | TLS
   v
Wazuh Server API

Manager
   |
   | HTTPS / TLS
   v
Indexer

A browser certificate warning therefore does not necessarily mean that Manager-to-Indexer TLS is broken.

Certificate-based authentication

TLS certificates can provide authentication at the cryptographic layer.

Suppose the Dashboard connects to an Indexer. The Indexer presents its server certificate.

The Dashboard examines that certificate and determines whether:

The certificate is currently valid.
The certificate is signed by a trusted CA.
The certificate’s identity matches the hostname being accessed.
The certificate chain is complete.
The cryptographic parameters satisfy the client’s requirements.

If these checks succeed, the client can establish a trusted TLS session.

When mutual TLS is configured, the process goes further: the client also presents a certificate, allowing the server to authenticate the client cryptographically.

CA certificates

A Certificate Authority (CA) is the trust anchor for a certificate hierarchy.

Instead of manually trusting every server certificate individually, a system can trust a CA.

Certificates issued by that CA can then be validated against the trusted CA.

For example:

Root CA
   |
   +---- Manager Certificate
   |
   +---- Indexer Certificate
   |
   +---- Dashboard Certificate

Wazuh’s certificate deployment tooling creates a root-ca certificate and uses it as the authority for signing the other certificates in the deployment.

If a Wazuh component does not have the correct CA certificate, it may reject another component’s certificate with errors such as:

certificate signed by unknown authority
unable to get local issuer certificate
unable to verify the first certificate

This is why copying a server certificate without also establishing the appropriate CA trust relationship can fail.

Server certificates

A server certificate identifies the server participating in a TLS connection.

For example, when the Wazuh Dashboard connects to:

https://indexer.example.com:9200

the Indexer presents a certificate identifying the server.

The certificate should contain an appropriate Subject Alternative Name (SAN) for the hostname or IP address being used.

A common configuration error occurs when the certificate was issued for:

indexer.example.com

but the client connects to:

10.0.0.25

If the certificate does not contain the IP address as a valid SAN, hostname verification can fail even though the certificate was issued by a trusted CA.

Private keys

Every certificate-based identity relies on a corresponding private key.

The private key must remain secret. It should not be copied unnecessarily between systems or exposed through configuration management, source control, public storage, or logs.

A simplified certificate relationship is:

Certificate
    |
    | Public information
    v
Public Key

Private Key
    |
    | Secret
    v
Proof of identity

The certificate can be distributed to systems that need to verify it. The private key should remain under the control of the service that owns that identity.

Incorrect private-key permissions can also prevent Wazuh services from starting after certificate changes.

Certificate chains

A certificate chain establishes a path from the server certificate to a trusted CA.

A simplified chain might look like:

Root CA
   |
   v
Intermediate CA
   |
   v
Wazuh Server Certificate

The receiving system validates this chain to determine whether it can trust the server certificate.

Incomplete chains can produce errors such as:

unable to verify the first certificate
unable to get local issuer certificate
certificate verify failed

When configuring third-party certificates for the Wazuh Dashboard, Wazuh’s documentation specifically demonstrates using fullchain.pem as the Dashboard certificate.

This is an important distinction between a leaf certificate and a complete certificate chain.

Mutual TLS and client certificates

Standard TLS authentication commonly involves the server proving its identity to the client.

Mutual TLS, or mTLS, adds the reverse relationship:

Client --------------------> Server
       Server certificate

Client <-------------------- Server
       Client certificate

Both sides authenticate using certificates.

This can provide stronger machine-to-machine authentication because possession of a valid certificate and private key becomes part of the trust decision.

Wazuh’s certificate architecture includes client certificates for certain administrative and security operations.

Its documentation identifies the admin certificate as a client certificate with special privileges.

mTLS should therefore not be confused with ordinary browser HTTPS.

HTTPS can authenticate the server without necessarily requiring the browser to provide a client certificate.

SSL verification

SSL/TLS verification is the process of determining whether a presented certificate should be trusted.

A simplified verification process is:

Certificate received
        |
        v
Is it within its validity period?
        |
        v
Does the certificate chain to a trusted CA?
        |
        v
Does the hostname match?
        |
        v
Are the cryptographic parameters acceptable?
        |
        v
       YES
        |
        v
Establish trusted TLS connection

When verification fails, administrators should avoid immediately disabling certificate verification.

For example, Wazuh’s Dashboard configuration supports different verification modes for its Indexer connection.

However, bypassing verification can conceal the underlying trust problem and weaken the security of the deployment.

A better approach is to identify the actual cause:

Incorrect CA
Expired certificate
Wrong hostname
Missing intermediate certificate
Incorrect certificate path
Incorrect permissions
Mismatched private key
Unsupported TLS configuration
Incorrect system time

CISA’s communications-infrastructure hardening guidance recommends using modern TLS, strong cryptographic cipher suites, PKI-based certificates instead of self-signed certificates where appropriate, and a robust process for renewing certificates before expiration.

The practical lesson for Wazuh administrators is straightforward: do not treat certificate verification as an obstacle to work around. Treat it as an important security control that should be configured correctly.

Wazuh SSL Certificate Requirements

Before configuring Wazuh SSL, you need to understand which certificates are required, where they are used, and how Wazuh validates them.

A TLS configuration can fail even when the certificate itself is valid if the wrong certificate is assigned to a component, the hostname does not match, or the service cannot access its private key.

Wazuh’s current certificate deployment process uses a root CA and component-specific certificates to establish trust between central components.

Wazuh supports its wazuh-certs-tool.sh utility as the default certificate-generation method, while custom certificates generated with tools such as OpenSSL are also supported.

Required certificates and keys

A typical Wazuh deployment uses several certificate and key pairs.

At a minimum, the certificate architecture includes:

A root CA certificate
A root CA private key
A certificate for each Wazuh Indexer node
A private key for each Indexer node
A certificate for each Wazuh server node
A private key for each Wazuh server node
A Dashboard certificate
A Dashboard private key
An admin client certificate and private key for Wazuh Indexer administrative operations

Wazuh’s certificate deployment documentation identifies the root CA, node certificates, and admin certificate as core elements of its certificate architecture.

The admin certificate is specifically a client certificate used for privileged Indexer management and security operations.

The exact files depend on how the deployment was generated.

For example, Wazuh’s certificate-generation process can produce files such as:

root-ca.pem
root-ca.key

node-1.pem
node-1-key.pem

admin.pem
admin-key.pem

server.pem
server-key.pem

The most important rule is to keep certificates and private keys together as their intended pairs.

Do not accidentally assign one node’s private key to another node’s certificate.

Certificate Authority (CA)

The Certificate Authority (CA) is the trust anchor for the Wazuh TLS environment.

The root CA certificate signs the certificates used by Wazuh components. Services that trust the root CA can then validate certificates issued by that CA.

A simplified structure looks like this:

                    Root CA
                       |
          +------------+------------+
          |            |            |
       Indexer      Wazuh Server  Dashboard
       Certificate   Certificate   Certificate

The root-ca.pem file contains the public CA certificate, while root-ca.key contains the private signing key.

The CA private key is particularly sensitive.

If an attacker obtains it, they may be able to issue fraudulent certificates that trusted Wazuh components would accept.

Do not distribute root-ca.key to every Wazuh node.

Components generally need the CA certificate for verification, not the CA’s private signing key.

Wazuh explicitly recommends conserving the root CA when initially deploying a complete infrastructure because it can subsequently be used to create certificates for additional Wazuh server and Dashboard nodes.

Hostnames and Subject Alternative Names (SANs)

The certificate identity must correspond to how the Wazuh component is accessed.

For example, if a Wazuh Indexer is accessed as:

indexer01.example.com

the certificate should contain that DNS name in its Subject Alternative Name (SAN) extension.

If clients connect using an IP address, the certificate should contain the IP address as a SAN.

For example:

Subject Alternative Name:
    DNS:indexer01.example.com
    IP Address:10.10.10.20

Wazuh explicitly states that node certificates must include either the node’s IP address or DNS name so certificate verification can establish that communication is occurring with the intended node.

This is one of the most common causes of TLS errors.

For example, suppose the certificate contains:

DNS:indexer.example.com

but your Dashboard connects to:

https://10.0.0.20:9200

The certificate may be valid and signed by the correct CA, but hostname verification can still fail because 10.0.0.20 is not included in the certificate’s SANs.

Certificate validity periods

Every X.509 certificate has a validity period containing:

Not Before
Not After

A certificate that has passed its Not After date is expired and should no longer be trusted.

You can inspect these dates with OpenSSL:

openssl x509 -in /path/to/certificate.pem -noout -dates

Example output:

notBefore=Aug 16 00:00:00 2026 GMT
notAfter=Aug 16 00:00:00 2027 GMT

Certificate expiration should be monitored proactively rather than discovered when a Wazuh component stops communicating.

This is particularly important for production environments because certificate expiration can affect multiple services simultaneously.

Supported certificate formats

Wazuh’s documented certificate configurations commonly use PEM-encoded X.509 certificates and private keys.

Typical Wazuh files include:

.pem
.key

For example:

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

A PEM file generally contains Base64-encoded certificate or key data enclosed by delimiters such as:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

or:

-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

Do not assume that a certificate’s filename determines its format. Always inspect the actual contents when troubleshooting.

For example:

openssl x509 -in certificate.pem -noout -subject -issuer

For a private key:

openssl pkey -in private-key.pem -check

File ownership and permissions

Certificate files should be readable by the Wazuh service that needs them while private keys should be protected from unnecessary access.

For example, the Wazuh Indexer certificate directory is commonly:

/etc/wazuh-indexer/certs/

Wazuh’s documentation places Indexer certificates in this directory and references them from /etc/wazuh-indexer/opensearch.yml.

Check ownership with:

ls -la /etc/wazuh-indexer/certs/

You should verify that the Wazuh Indexer process can read the required certificate and key files.

A permissions problem can produce errors that look like certificate failures even though the certificate itself is perfectly valid.

For example:

Permission denied
Unable to load certificate
Unable to read private key

Do not solve this by making private keys world-readable. Instead, assign ownership and permissions appropriate for the service account.

Matching certificates to Wazuh components

Every certificate needs to be deployed to the component that owns its identity.

A simplified mapping is:

Component	Typical certificate	Private key	Trusted CA
Wazuh Indexer	Indexer/node certificate	Indexer key	Root CA
Wazuh Dashboard	Dashboard certificate	Dashboard key	Root CA
Wazuh server/Filebeat	Server/Filebeat certificate	Corresponding key	Root CA
Indexer administration	Admin client certificate	Admin key	Root CA
Wazuh server cluster	Server node certificate	Server node key	Root CA

In a multi-node Indexer cluster, each Indexer node should have its own node certificate and private key rather than sharing the same node identity.

Wazuh’s documentation specifically states that unique certificate/key pairs are generated for each Indexer node in a clustered environment.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

When to use a self-signed CA vs. an internal/public CA

There is an important distinction between a self-signed server certificate and a private CA.

For internal Wazuh infrastructure, a private CA can be a perfectly reasonable solution:

Internal Root CA
       |
       +---- Indexer
       +---- Manager
       +---- Dashboard
       +---- Filebeat

This gives you centralized certificate trust without exposing internal services to a public certificate authority.

A public CA is generally preferable when users access the Wazuh Dashboard through a publicly trusted domain and you want browsers and standard operating systems to trust the certificate without manually installing your internal CA.

Examples include certificates issued by:

Let’s Encrypt
DigiCert
GlobalSign
Sectigo

Wazuh documents the use of third-party certificates, including Let’s Encrypt certificates, for the Dashboard.

For most internal Wazuh deployments, the practical choices are:

1. Use a private/internal CA when:

Wazuh is entirely internal.
You control the client trust stores.
You already operate an enterprise PKI.
You need centralized certificate management.

2. Use a public CA when:

The Dashboard is accessed through a publicly registered domain.
You need browser-native trust.
You want to avoid manually distributing a private CA certificate to client devices.

Use Wazuh’s generated CA when:

You are deploying a new Wazuh environment.
The environment is primarily internal.
You want the simplest supported certificate deployment method.
You do not already have an enterprise PKI.

The important point is that self-signed does not automatically mean insecure.

A private CA can provide strong cryptographic protection when the CA private key is protected and all clients correctly validate the CA chain.

How to Generate Wazuh SSL Certificates

Wazuh provides wazuh-certs-tool.sh to simplify certificate creation for its central components.

The tool uses a config.yml file containing the node names and IP addresses or DNS names used to create the certificates.

Wazuh also supports custom certificates generated with OpenSSL or another PKI system.

For a standard installation, using the Wazuh certificate tool is usually the easiest approach because it generates the certificate set expected by the Wazuh installation process.

Important: preserve the root CA certificate and private key if you plan to add nodes or regenerate individual certificates later.

Wazuh specifically documents using an existing root CA to create new Indexer and Wazuh server certificates.

Generate a Certificate Authority

Start by preparing the Wazuh certificate-generation configuration.

A simplified configuration might look like:

nodes:
  indexer:
    - name: node-1
      ip: "10.10.10.20"

  server:
    - name: wazuh-1
      ip: "10.10.10.10"
      node_type: master

  dashboard:
    - name: dashboard
      ip: "10.10.10.30"

The exact configuration should follow the template supplied with your Wazuh version.

Once the configuration is ready, the Wazuh certificate tool can generate the certificate set:

bash wazuh-certs-tool.sh -A

The resulting directory contains files such as:

wazuh-certificates/
├── admin-key.pem
├── admin.pem
├── root-ca.key
├── root-ca.pem
├── node-1-key.pem
└── node-1.pem

Wazuh documents the -A option as the method for generating the certificates required for the central components.

The most sensitive file in this directory is:

root-ca.key

Protect it carefully and do not routinely copy it to production nodes.

Generate node certificates

For a Wazuh Indexer cluster, generate a unique certificate for each node.

For example:

node-1.pem
node-1-key.pem

node-2.pem
node-2-key.pem

node-3.pem
node-3-key.pem

Each certificate should contain the corresponding node’s DNS name or IP address.

This allows an Indexer node to establish its own identity during TLS communication.

Wazuh recommends unique certificate/key pairs for each Indexer node in a multi-node deployment.

Generate Dashboard certificates

The Dashboard requires a certificate and corresponding private key when HTTPS is enabled directly on the Dashboard.

The Wazuh certificate tool can generate Dashboard certificates as part of the complete central-component certificate set.

For example:

dashboard.pem
dashboard-key.pem

The certificate should identify the hostname or IP address users will use to access the Dashboard.

If users connect through:

https://wazuh.example.com

the certificate should include:

DNS:wazuh.example.com

as a SAN.

If you use a public certificate provider such as Let’s Encrypt, the resulting certificate and private key can instead be configured directly in the Wazuh Dashboard.

Wazuh’s documentation demonstrates this approach using fullchain.pem and privkey.pem.

Generate certificates for the Wazuh Manager

Wazuh server nodes can also receive certificates generated by the Wazuh certificate tool.

For example:

server.pem
server-key.pem

For a Wazuh server cluster, generate an appropriate certificate for each server node.

Wazuh’s server-cluster certificate documentation states that each Wazuh server node certificate should include the node’s IP address or DNS name.

If you already have an existing root CA, Wazuh provides an option to generate Wazuh server certificates using that CA:

bash wazuh-certs-tool.sh -ws /path/to/root-ca.pem /path/to/root-ca.key

The -ws option creates Wazuh server certificates using the supplied root CA.

Generate certificates for the Wazuh Indexer

Indexer certificates can be generated as part of the complete certificate set or using an existing root CA.

When generating certificates from an existing CA, Wazuh documents:

bash wazuh-certs-tool.sh -wi /path/to/root-ca.pem /path/to/root-ca.key

The -wi option creates Wazuh Indexer certificates from the specified CA.

After generation, the Indexer certificate and key need to be placed on the appropriate Indexer node.

For example:

mkdir -p /etc/wazuh-indexer/certs/

mv node-1.pem /etc/wazuh-indexer/certs/indexer.pem
mv node-1-key.pem /etc/wazuh-indexer/certs/indexer-key.pem

Wazuh’s documented default paths use the Indexer certificate directory:

/etc/wazuh-indexer/certs/

and reference those files from /etc/wazuh-indexer/opensearch.yml.

Generate certificates for Wazuh agents

Agent certificate handling deserves a distinction from central-component certificate deployment.

The standard Wazuh central certificate-generation process is primarily concerned with securing communication between central Wazuh components such as the Wazuh server, Indexer, Dashboard, and Filebeat.

Do not assume that every Wazuh agent needs a certificate generated by wazuh-certs-tool.sh.

Agent enrollment and agent authentication use Wazuh’s own registration and key mechanisms, while TLS can be configured for relevant agent-to-manager communication depending on the deployment and Wazuh version.

This is an important distinction when designing your certificate inventory: central-component certificates and agent enrollment credentials are not interchangeable.

Verify certificate contents and expiration dates

Never deploy certificates without first inspecting them.

Use OpenSSL to display the certificate subject, issuer, validity period, and SANs:

openssl x509 \
  -in /path/to/certificate.pem \
  -noout \
  -subject \
  -issuer \
  -dates \
  -ext subjectAltName

For example:

subject=CN = node-1
issuer=CN = Wazuh Root CA
notBefore=Aug 16 00:00:00 2026 GMT
notAfter=Aug 16 00:00:00 2027 GMT
X509v3 Subject Alternative Name:
    DNS:node-1.example.com
    IP Address:10.10.10.20

Verify that:

The issuer is the expected CA.
The certificate has not expired.
The hostname is correct.
The IP address is correct if clients connect using the IP.
The SAN contains every required identity.
The certificate belongs to the expected Wazuh component.

You should also verify that the certificate and private key match.

One useful OpenSSL check is:

openssl x509 -in certificate.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | sha256sum

openssl pkey -in private-key.pem -pubout \
  | openssl pkey -pubin -outform DER \
  | sha256sum

The resulting hashes should match.

This catches a common deployment error: installing a certificate from one node together with the private key belonging to another node.

How to Configure SSL on the Wazuh Indexer

The Wazuh Indexer uses OpenSearch Security’s TLS configuration to secure both its HTTP API and transport-layer communication.

The primary configuration file is:

/etc/wazuh-indexer/opensearch.yml

Wazuh’s current documentation identifies this as the Wazuh Indexer configuration file and provides the SSL parameters used for HTTP and transport connections.

Locate the Indexer SSL configuration

Open the configuration file:

sudo nano /etc/wazuh-indexer/opensearch.yml

Look for parameters beginning with:

plugins.security.ssl

A typical configuration includes:

plugins.security.ssl.http.pemcert_filepath: /etc/wazuh-indexer/certs/wazuh-indexer.pem
plugins.security.ssl.http.pemkey_filepath: /etc/wazuh-indexer/certs/wazuh-indexer-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem

plugins.security.ssl.transport.pemcert_filepath: /etc/wazuh-indexer/certs/wazuh-indexer.pem
plugins.security.ssl.transport.pemkey_filepath: /etc/wazuh-indexer/certs/wazuh-indexer-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem

plugins.security.ssl.http.enabled: true

These settings separately define TLS material for the Indexer’s HTTP layer and transport layer.

Wazuh’s documented configuration uses the same certificate, key, and trusted CA paths for both in a standard installation.

Configure the CA certificate

The trusted CA tells the Indexer which certificate authority it should accept when validating certificates.

Set:

plugins.security.ssl.http.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem

and:

plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem

The file should contain the CA certificate, not the CA’s private key.

Verify the file:

openssl x509 \
  -in /etc/wazuh-indexer/certs/root-ca.pem \
  -noout \
  -subject \
  -issuer \
  -dates

If the CA is incorrect or missing, clients can encounter errors such as:

certificate signed by unknown authority
unable to get local issuer certificate

Configure the node certificate

Set the HTTP certificate:

plugins.security.ssl.http.pemcert_filepath: /etc/wazuh-indexer/certs/wazuh-indexer.pem

Set the transport certificate:

plugins.security.ssl.transport.pemcert_filepath: /etc/wazuh-indexer/certs/wazuh-indexer.pem

The certificate should correspond to the Indexer node on which it is installed.

If you are running multiple Indexer nodes, each node should use its own node-specific certificate and private key.

Related Guide: How to Build a Wazuh Indexer Cluster

Configure the private key

Configure the private key corresponding to the Indexer certificate:

plugins.security.ssl.http.pemkey_filepath: /etc/wazuh-indexer/certs/wazuh-indexer-key.pem

and:

plugins.security.ssl.transport.pemkey_filepath: /etc/wazuh-indexer/certs/wazuh-indexer-key.pem

The private key must correspond exactly to the public key contained in the certificate.

You can test the key itself with:

openssl pkey \
  -in /etc/wazuh-indexer/certs/wazuh-indexer-key.pem \
  -check

Then verify that the certificate and key match before restarting the service.

Configure certificate verification

The Indexer configuration includes TLS verification parameters for transport communication.

A standard Wazuh configuration contains:

plugins.security.ssl.transport.enforce_hostname_verification: false
plugins.security.ssl.transport.resolve_hostname: false

Wazuh’s current Indexer configuration documentation shows these settings in the default configuration.

Do not blindly change TLS verification settings simply because a certificate error appears.

Instead, determine whether the certificate’s SANs, CA chain, node identity, or hostname configuration are incorrect.

For example, if hostname verification fails because the certificate does not contain the address being used, the preferred solution is generally to issue a certificate with the correct SAN rather than permanently weakening verification.

Wazuh also documents plugins.security.nodes_dn, which identifies the distinguished names of certificates belonging to Wazuh Indexer cluster nodes.

For a multi-node cluster, this can look like:

plugins.security.nodes_dn:
  - "CN=node-1,OU=Wazuh,O=Wazuh,L=California,C=US"
  - "CN=node-2,OU=Wazuh,O=Wazuh,L=California,C=US"

The values must correspond to the certificates actually deployed on the cluster nodes.

Restart the Wazuh Indexer

After changing the certificate configuration, validate the configuration files and restart the Indexer:

sudo systemctl restart wazuh-indexer

Then check its status:

sudo systemctl status wazuh-indexer

If the service does not start, immediately inspect the logs:

sudo journalctl -u wazuh-indexer -n 100 --no-pager

You can also inspect the Wazuh Indexer logs under:

/var/log/wazuh-indexer/

Common certificate-related startup errors include:

Unable to read certificate
Unable to load PEM
Permission denied
No such file or directory

These usually indicate a path, permissions, certificate format, or private-key problem rather than a networking issue.

Verify secure Indexer communication

Once the Indexer is running, verify that its HTTPS endpoint responds.

For example:

curl -k https://localhost:9200

The -k option disables certificate verification and should be used only as a diagnostic step.

A better test is to explicitly provide the trusted CA:

curl \
  --cacert /etc/wazuh-indexer/certs/root-ca.pem \
  https://localhost:9200

If hostname verification is enabled and the certificate was issued for a hostname rather than localhost, test using the actual certificate identity:

curl \
  --cacert /etc/wazuh-indexer/certs/root-ca.pem \
  https://indexer.example.com:9200

You can inspect the TLS handshake directly with:

openssl s_client \
  -connect indexer.example.com:9200 \
  -CAfile /etc/wazuh-indexer/certs/root-ca.pem

Look for:

Verify return code: 0 (ok)

A successful verification indicates that OpenSSL was able to validate the server’s certificate against the supplied CA.

Also verify the certificate identity:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/wazuh-indexer/certs/root-ca.pem

This is useful for identifying:

Incorrect SANs
Expired certificates
Incorrect certificate chains
Wrong CA certificates
TLS handshake failures
Incorrect server names

Once the Indexer responds successfully over HTTPS and its certificate validates against the expected CA, the next step is to configure the Wazuh Dashboard and other Wazuh components to trust and use the same certificate infrastructure.

How to Configure SSL on the Wazuh Dashboard

The Wazuh Dashboard is normally the component users access directly from a web browser, making its HTTPS configuration especially important.

Wazuh supports its generated certificates as well as third-party certificates such as Let’s Encrypt.

Wazuh’s documentation also supports terminating TLS with NGINX when you want a reverse proxy in front of the Dashboard.

For a direct Dashboard TLS configuration, the primary configuration file is:

/etc/wazuh-dashboard/opensearch_dashboards.yml

The certificate files are commonly stored under:

/etc/wazuh-dashboard/certs/

Configure the Dashboard HTTPS certificate

The Dashboard’s HTTPS server certificate is configured with:

server.ssl.certificate: "/etc/wazuh-dashboard/certs/wazuh-dashboard.pem"

The certificate should identify the hostname users enter in their browsers.

For example, if users access:

https://wazuh.example.com

the certificate should contain:

DNS:wazuh.example.com

in its Subject Alternative Name extension.

If you use a third-party certificate such as Let’s Encrypt, Wazuh’s documentation uses the fullchain.pem file:

server.ssl.certificate: "/etc/wazuh-dashboard/certs/fullchain.pem"

The fullchain.pem file contains the server certificate together with the intermediate certificate chain required by clients.

You can inspect the certificate before configuring it:

openssl x509 \
  -in /etc/wazuh-dashboard/certs/wazuh-dashboard.pem \
  -noout \
  -subject \
  -issuer \
  -dates \
  -ext subjectAltName

Check that the hostname used by your administrators appears in the SAN list.

Configure the Dashboard private key

The private key corresponding to the Dashboard certificate is configured with:

server.ssl.key: "/etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem"

For a Let’s Encrypt certificate, Wazuh documents:

server.ssl.key: "/etc/wazuh-dashboard/certs/privkey.pem"

The certificate and private key must be a matching pair.

You can verify the private key:

openssl pkey \
  -in /etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem \
  -check

Do not make the private key broadly readable simply to resolve a startup error.

The Dashboard service should have the permissions it needs while other users should not have unnecessary access.

Configure the CA certificate

The CA certificate is used when the Dashboard verifies the Wazuh Indexer’s TLS certificate.

Configure it with:

opensearch.ssl.certificateAuthorities:
  - "/etc/wazuh-dashboard/certs/root-ca.pem"

This is separate from:

server.ssl.certificate

The first setting tells the Dashboard which CA to trust when connecting outbound to the Indexer.

The second identifies the Dashboard when browsers connect inbound to the Dashboard.

That distinction is important:

Browser
   |
   | verifies Dashboard certificate
   v
Dashboard
   |
   | verifies Indexer certificate
   v
Indexer

A valid Dashboard certificate therefore does not automatically mean that the Dashboard can establish a trusted TLS connection to the Indexer.

Enable HTTPS

Enable HTTPS with:

server.ssl.enabled: true

A typical direct HTTPS configuration resembles:

server.host: 0.0.0.0
server.port: 443

server.ssl.enabled: true
server.ssl.key: "/etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/wazuh-dashboard.pem"

opensearch.hosts: ["https://indexer.example.com:9200"]
opensearch.ssl.certificateAuthorities:
  - "/etc/wazuh-dashboard/certs/root-ca.pem"

opensearch.ssl.verificationMode: certificate

Wazuh’s documented Dashboard configuration uses server.ssl.enabled, a server certificate and key, an Indexer CA, and opensearch.ssl.verificationMode.

The exact configuration should match the Wazuh version and certificate architecture you are using.

Configure secure communication with the Wazuh Indexer

The Dashboard must also establish a trusted HTTPS connection to the Indexer.

For example:

opensearch.hosts:
  - "https://indexer.example.com:9200"

opensearch.ssl.certificateAuthorities:
  - "/etc/wazuh-dashboard/certs/root-ca.pem"

opensearch.ssl.verificationMode: certificate

The Indexer address should correspond to the identity contained in the Indexer’s certificate.

For example, if the certificate contains:

DNS:indexer.example.com

prefer:

https://indexer.example.com:9200

over an unrelated hostname or IP address.

If your deployment uses an Indexer cluster, configure the appropriate Indexer nodes according to the Wazuh deployment architecture rather than assuming the Dashboard should always connect to localhost.

Restart the Wazuh Dashboard

After changing the configuration, restart the service:

sudo systemctl restart wazuh-dashboard

Then verify its status:

sudo systemctl status wazuh-dashboard

If it fails to start, inspect the logs:

sudo journalctl -u wazuh-dashboard -n 100 --no-pager

Also inspect the Dashboard logs when necessary:

sudo tail -n 100 /var/log/wazuh-dashboard/wazuh-dashboard.log

Common certificate-related startup errors include:

ENOENT
Permission denied
Unable to load certificate
Unable to load private key
certificate verify failed

These should be resolved at the certificate, path, ownership, or trust-chain level rather than by disabling TLS verification.

Verify HTTPS access

Once the Dashboard restarts successfully, open:

https://<WAZUH_DASHBOARD_HOSTNAME>

You can also test the endpoint from the command line:

curl -I https://wazuh.example.com

For a more detailed TLS test:

openssl s_client \
  -connect wazuh.example.com:443 \
  -servername wazuh.example.com

When using a private CA, explicitly provide it:

openssl s_client \
  -connect wazuh.example.com:443 \
  -servername wazuh.example.com \
  -CAfile /etc/wazuh-dashboard/certs/root-ca.pem

Look for a successful certificate verification result.

If the browser reports a certificate warning, inspect:

Certificate expiration
Certificate SANs
Certificate issuer
Certificate chain
Browser trust store
Dashboard certificate path
Private-key permissions

How to Configure SSL on the Wazuh Manager

Wazuh Manager SSL configuration involves more than one communication path.

In particular, the Manager can use TLS for agent enrollment and identity verification, while its Indexer integration uses HTTPS and certificate-based verification to communicate with the Wazuh Indexer.

The current Wazuh documentation shows the Indexer integration in /var/ossec/etc/ossec.conf and supports a CA certificate, client certificate, and private key for the secure connection.

Manager certificate configuration

For Wazuh Manager identity verification during agent enrollment, the Manager can use an SSL certificate and private key.

The relevant authentication configuration uses:

<auth>
  <ssl_manager_cert>etc/sslmanager.cert</ssl_manager_cert>
  <ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
</auth>

The default paths are relative to the Wazuh installation directory, although Wazuh also supports full paths.

For a standard installation, this corresponds to:

/var/ossec/etc/sslmanager.cert
/var/ossec/etc/sslmanager.key

The Manager certificate should identify the Manager’s IP address or FQDN.

Wazuh’s manager identity verification documentation specifically recommends including the Manager IP address or FQDN in the certificate configuration and using SANs for additional DNS identities.

Secure Manager-to-Indexer communication

The Manager communicates with the Wazuh Indexer through the Indexer integration.

The relevant configuration is in:

/var/ossec/etc/ossec.conf

A current Wazuh configuration can look like:

<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://indexer.example.com: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>

Wazuh documents the CA, certificate, and key parameters for this integration.

If your Wazuh installation uses multiple Indexer nodes, you can specify multiple <host> entries:

<hosts>
  <host>https://indexer-1.example.com:9200</host>
  <host>https://indexer-2.example.com:9200</host>
</hosts>

Wazuh’s installation documentation states that the Manager prioritizes the first Indexer in the list and switches to another when the first is unavailable.

Configure certificates and private keys

The three important SSL parameters are:

<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>

Their roles are different:

root-ca.pem — CA used to verify the Indexer’s server certificate.
filebeat.pem — client certificate presented during certificate-based authentication where required.
filebeat-key.pem — private key corresponding to that client certificate.

The Wazuh documentation identifies these parameters as the CA, end-entity certificate, and certificate key used by the Indexer integration.

Check that the files actually exist:

sudo ls -l \
  /etc/filebeat/certs/root-ca.pem \
  /etc/filebeat/certs/filebeat.pem \
  /etc/filebeat/certs/filebeat-key.pem

Then verify the certificate:

openssl x509 \
  -in /etc/filebeat/certs/filebeat.pem \
  -noout \
  -subject \
  -issuer \
  -dates

And verify the private key:

openssl pkey \
  -in /etc/filebeat/certs/filebeat-key.pem \
  -check

Configure certificate verification

Certificate verification should normally remain enabled.

The CA specified in:

<certificate_authorities>
  <ca>/etc/filebeat/certs/root-ca.pem</ca>
</certificate_authorities>

allows the Wazuh Manager’s Indexer integration to validate the Indexer’s HTTPS certificate.

The hostname used in:

<host>https://indexer.example.com:9200</host>

should correspond to an identity covered by the Indexer’s certificate.

If the certificate contains:

DNS:indexer.example.com

then:

https://indexer.example.com:9200

is preferable to connecting through an unrelated hostname.

Do not treat certificate verification failures as a reason to replace HTTPS with HTTP.

A failed verification normally indicates that the certificate, CA, hostname, or chain needs correction.

Restart the Wazuh Manager

After modifying /var/ossec/etc/ossec.conf, restart the Manager:

sudo systemctl restart wazuh-manager

Wazuh’s documentation explicitly instructs administrators to restart the Manager after changing its SSL-related authentication configuration.

Check the service:

sudo systemctl status wazuh-manager

Then inspect the Manager log:

sudo tail -n 100 /var/ossec/logs/ossec.log

For Indexer-related problems, search for TLS or SSL messages:

sudo grep -Ei 'ssl|tls|certificate|indexer' \
  /var/ossec/logs/ossec.log | tail -n 50

Verify SSL communication

The most useful way to verify Manager-to-Indexer TLS is to test the Indexer endpoint independently first.

From the Wazuh Manager:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/filebeat/certs/root-ca.pem

Then check for:

Verify return code: 0 (ok)

You can also test HTTPS with curl:

curl \
  --cacert /etc/filebeat/certs/root-ca.pem \
  https://indexer.example.com:9200

If the connection fails, investigate the certificate chain and hostname before changing Wazuh configuration.

For Filebeat-based forwarding, also verify its TLS configuration:

sudo grep -A10 -B2 'ssl.certificate' /etc/filebeat/filebeat.yml

The Wazuh documentation shows Filebeat using HTTPS together with a CA certificate, client certificate, and private key for secure Indexer communication.

How to Configure SSL for Wazuh Agents

Agent TLS requires slightly different terminology because Wazuh supports several security mechanisms around agent enrollment and Manager identity verification.

A particularly important feature is Wazuh Manager identity verification.

In this configuration, an agent verifies the Manager’s SSL certificate before sending an enrollment request.

Wazuh also supports the reverse model, where the Manager verifies an agent’s certificate.

These two verification mechanisms are independent and can be combined.

How agent-to-manager encryption works

The Wazuh agent communicates with the Manager over the Wazuh agent communication protocol.

For enrollment, the Manager’s authd service can accept TLS-encrypted connections on port 1515 by default.

Wazuh’s Manager documentation identifies <remote_enrollment> as the setting controlling this enrollment process and documents SSL certificate parameters for Manager identity verification.

The basic trust relationship is:

Wazuh Agent
     |
     | TLS enrollment request
     v
Wazuh Manager
     |
     | Presents Manager certificate
     v
Agent verifies certificate

With Manager identity verification enabled, the agent uses the CA certificate to determine whether the Manager’s certificate is trusted.

This prevents an agent from blindly accepting any server claiming to be the Wazuh Manager.

Agent certificate requirements

For Manager identity verification, the Wazuh Manager and agent certificates must be signed by a CA that the corresponding component trusts.

Wazuh’s official Manager identity verification documentation states that a CA is required to sign certificates for the Manager and agents.

A Manager certificate should identify the Manager using its IP address or FQDN.

For example:

Subject:
    CN = wazuh.example.com

Subject Alternative Name:
    DNS:wazuh.example.com
    IP Address:10.10.10.10

The agent must have access to the CA certificate used to validate the Manager certificate.

For agent identity verification, the reverse relationship is used:

Agent certificate
        |
        v
Signed by trusted CA
        |
        v
Manager verifies agent

This gives administrators the option of verifying both sides of the enrollment relationship.

Configure encrypted agent communication

On the Wazuh Manager, the relevant enrollment configuration is located in:

/var/ossec/etc/ossec.conf

A TLS-enabled enrollment configuration can include:

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

  <ssl_agent_ca>etc/ssl/rootCA.pem</ssl_agent_ca>
  <ssl_verify_host>yes</ssl_verify_host>

  <ssl_manager_cert>etc/sslmanager.cert</ssl_manager_cert>
  <ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
</auth>

Wazuh documents <ssl_agent_ca> as the CA used to verify clients, <ssl_manager_cert> as the Manager server certificate, and <ssl_manager_key> as its private key.

The <ssl_verify_host> option controls source-host verification when a CA certificate is configured.

For Manager identity verification, the agent is configured to trust the CA certificate that signed the Manager certificate.

On Linux/Unix agents, follow the Wazuh agent identity-verification procedure for your installed Wazuh version and place the CA material in the location specified by the agent configuration.

On Windows and macOS agents, the configuration differs, so do not copy Linux file paths directly into those operating systems.

Verify agent connectivity

After configuring the certificates, restart the Wazuh Manager:

sudo systemctl restart wazuh-manager

Then verify that the enrollment service is listening:

sudo ss -lntp | grep 1515

From the agent, test network connectivity to the Manager:

nc -vz wazuh.example.com 1515

On Windows, you can use PowerShell:

Test-NetConnection wazuh.example.com -Port 1515

Network connectivity alone does not prove that TLS validation is working.

You also need to examine the Wazuh agent and Manager logs.

On the Manager:

sudo tail -f /var/ossec/logs/ossec.log

On a Linux agent:

sudo tail -f /var/ossec/logs/ossec.log

Look for successful enrollment and authentication messages as well as certificate-related failures.

Once the agent is enrolled, verify its status from the Wazuh Dashboard or through the Wazuh API.

Troubleshoot certificate validation problems

Certificate validation failures usually fall into a small number of categories.

The CA is not trusted

If the agent does not have the CA certificate that signed the Manager certificate, it cannot establish the expected trust chain.

Check the certificate issuer:

openssl x509 \
  -in sslmanager.cert \
  -noout \
  -issuer \
  -subject

Then compare the issuer against the configured CA.

The Manager hostname does not match the certificate

Suppose the agent connects to:

wazuh.example.com

but the Manager certificate only contains:

DNS:wazuh01.example.com

Hostname validation can fail.

Inspect the SANs:

openssl x509 \
  -in sslmanager.cert \
  -noout \
  -ext subjectAltName

Issue a certificate containing the actual hostname used by the agents rather than disabling verification.

The certificate has expired

Check:

openssl x509 \
  -in sslmanager.cert \
  -noout \
  -dates

If notAfter is in the past, replace the certificate with a renewed certificate signed by a trusted CA.

The private key does not match

Check the private key:

openssl pkey \
  -in sslmanager.key \
  -check

A mismatched certificate/key pair can prevent the Manager’s TLS service from starting correctly.

The certificate path is incorrect

Verify every configured file:

sudo ls -l \
  /var/ossec/etc/sslmanager.cert \
  /var/ossec/etc/sslmanager.key

Also verify the CA:

sudo ls -l /var/ossec/etc/ssl/

A missing file and an invalid certificate can produce very different errors, so check the paths before regenerating certificates.

The certificate chain is incomplete

If the Manager certificate was issued by an intermediate CA, ensure the validation path is available to the agent and that the appropriate CA certificates are configured.

Agent and Manager clocks are incorrect

TLS certificates are valid only within their specified validity periods. A significantly incorrect system clock can make an otherwise valid certificate appear expired or not yet valid.

Check the system time on both systems:

date

Use your organization’s time synchronization mechanism to correct clock drift rather than changing certificate validity settings.

Manager identity verification is confused with agent authentication

This distinction is especially important.

Wazuh documents Manager identity verification and agent identity verification as independent mechanisms.

An agent can verify the Manager, the Manager can verify the agent, or both can be configured.

Therefore, an agent registration failure does not necessarily mean that the TLS certificate is invalid. Other causes include:

Incorrect enrollment credentials
Incorrect Manager address
Port 1515 blocked
Registration service disabled
Agent name or IP conflict
Incorrect CA path
Certificate hostname mismatch
Expired certificate

The most reliable troubleshooting sequence is to verify network connectivity first, certificate validity second, CA trust third, hostname/SAN matching fourth, and Wazuh enrollment authentication last.

This prevents administrators from replacing valid certificates when the actual problem is a firewall, registration, or configuration issue.

How to Verify Wazuh SSL Configuration

After configuring Wazuh SSL, do not assume that a service restart means TLS is working correctly.

A Wazuh deployment can start successfully while a particular certificate chain, hostname, or component-to-component connection remains misconfigured.

The most reliable approach is to verify each TLS relationship independently:

Certificate files
       ↓
Certificate validity
       ↓
SAN / hostname
       ↓
CA trust
       ↓
TLS handshake
       ↓
Application connection
       ↓
Wazuh logs

This makes it easier to identify whether a problem exists at the certificate, network, TLS, or Wazuh application layer.

Check certificate files

Start by confirming that every certificate and private key referenced by your Wazuh configuration actually exists.

1. For the Dashboard:

sudo ls -lah /etc/wazuh-dashboard/certs/

2. For the Indexer:

sudo ls -lah /etc/wazuh-indexer/certs/

3. For Wazuh server certificates:

sudo ls -lah /var/ossec/etc/

4. For Filebeat certificates:

sudo ls -lah /etc/filebeat/certs/

Then compare the actual files against the paths configured in:

/etc/wazuh-dashboard/opensearch_dashboards.yml
/etc/wazuh-indexer/opensearch.yml
/var/ossec/etc/ossec.conf
/etc/filebeat/filebeat.yml

A common mistake is configuring:

server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"

when the actual file is:

/etc/wazuh-dashboard/certs/wazuh-dashboard.pem

The certificate can be perfectly valid and the Dashboard will still fail because it cannot load it.

Inspect certificate expiration dates

Use OpenSSL to inspect the certificate validity period:

openssl x509 \
  -in /path/to/certificate.pem \
  -noout \
  -dates

For more information:

openssl x509 \
  -in /path/to/certificate.pem \
  -noout \
  -subject \
  -issuer \
  -dates

You should see:

notBefore=...
notAfter=...

Check all certificates involved in the TLS path, not just the Dashboard certificate.

For example:

Dashboard certificate
Indexer certificate
Manager certificate
Agent certificate, where applicable
CA certificate

An expired intermediate or leaf certificate can break TLS even when the root CA itself remains valid.

Verify certificate SANs

Subject Alternative Names are particularly important because modern TLS clients use SANs to validate the identity of a server.

Run:

openssl x509 \
  -in /path/to/certificate.pem \
  -noout \
  -ext subjectAltName

Example:

X509v3 Subject Alternative Name:
    DNS:wazuh.example.com
    DNS:wazuh-dashboard.example.com
    IP Address:10.10.10.30

If the Dashboard is accessed as:

https://wazuh.example.com

then wazuh.example.com needs to be represented appropriately in the certificate.

Likewise, if the Dashboard connects to:

https://indexer.example.com:9200

the Indexer certificate should contain indexer.example.com as an appropriate SAN.

Do not solve SAN errors by simply disabling hostname verification. Correct the certificate identity instead.

Related Guide: How to Fix Wazuh Certificate Errors

Test HTTPS connectivity

Use curl to test HTTPS endpoints.

For the Wazuh Dashboard:

curl -I https://wazuh.example.com

For the Wazuh Indexer:

curl \
  --cacert /etc/wazuh-indexer/certs/root-ca.pem \
  https://indexer.example.com:9200

When testing a private CA, --cacert is preferable to -k because it tests whether the certificate can actually be validated against your intended trust anchor.

The following:

curl -k https://indexer.example.com:9200

can demonstrate that an HTTPS service is listening, but it does not prove that certificate validation is working.

Use -k only as a diagnostic comparison.

Test TLS connections

OpenSSL provides considerably more detail than a basic HTTP request:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com

For a private CA:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/wazuh-indexer/certs/root-ca.pem

A successful verification should include:

Verify return code: 0 (ok)

The output also shows the certificate chain, negotiated TLS version, cipher, server certificate, and other handshake information.

Check Wazuh logs

TLS problems frequently leave useful evidence in Wazuh logs.

1. For the Manager:

sudo tail -n 100 /var/ossec/logs/ossec.log

2. For the Dashboard:

sudo journalctl -u wazuh-dashboard -n 100 --no-pager

3. For the Indexer:

sudo journalctl -u wazuh-indexer -n 100 --no-pager

4. For Filebeat:

sudo journalctl -u filebeat -n 100 --no-pager

Search for common TLS-related terms:

sudo grep -Ei \
  'ssl|tls|certificate|x509|handshake|trust|verify' \
  /var/ossec/logs/ossec.log

The exact error message is usually more useful than a generic statement such as “SSL is not working.”

Verify secure communication between components

Test every important TLS path independently.

A typical deployment may contain:

                    HTTPS
Browser ─────────────────────> Dashboard
                                  |
                                  | HTTPS
                                  v
                               Indexer
                                  ^
                                  |
                                  | HTTPS
                               Manager

You should verify:

Browser → Dashboard
Dashboard → Indexer
Dashboard → Wazuh server API
Manager/Filebeat → Indexer
Agent → Manager, where TLS certificate verification is configured
Indexer → Indexer nodes in a cluster

Testing only the browser-to-Dashboard connection is insufficient.

For example, the Dashboard may display its login page successfully while failing to retrieve data because its Indexer TLS configuration is broken.

Confirm that certificates are trusted

A valid certificate is not necessarily a trusted certificate.

Check the certificate issuer:

openssl x509 \
  -in certificate.pem \
  -noout \
  -issuer

Then inspect the CA:

openssl x509 \
  -in root-ca.pem \
  -noout \
  -subject \
  -issuer

For a private Wazuh CA, the issuer of the component certificate should correspond to the CA used by the receiving component.

You can perform an actual trust test with:

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

A successful result should look like:

certificate.pem: OK

If you receive:

unable to get local issuer certificate

or:

unable to verify the first certificate

investigate the CA chain rather than replacing the certificate immediately.

How to Test Wazuh SSL with OpenSSL

OpenSSL is one of the most useful diagnostic tools for Wazuh SSL troubleshooting because it allows you to inspect the TLS connection independently of Wazuh.

This is important because it separates Wazuh configuration problems from TLS and certificate problems.

Check a Wazuh HTTPS endpoint

Start by connecting to the endpoint:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com

For the Dashboard:

openssl s_client \
  -connect wazuh.example.com:443 \
  -servername wazuh.example.com

The -servername option sends the hostname using SNI (Server Name Indication).

This is particularly important when the endpoint is behind a reverse proxy or when multiple TLS virtual hosts share an IP address.

To test using a specific CA:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/wazuh-indexer/certs/root-ca.pem

Inspect the server certificate

The OpenSSL output includes the server certificate.

You can also retrieve the certificate and inspect it separately:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout \
    -subject \
    -issuer \
    -dates \
    -ext subjectAltName

This gives you the most important identity information:

subject=
issuer=
notBefore=
notAfter=
X509v3 Subject Alternative Name:

Check whether:

The subject identifies the expected service.
The issuer is your trusted CA.
The certificate is currently valid.
The SAN contains the hostname or IP used by the client.

Verify the certificate chain

Run:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -showcerts

The command displays the certificates presented during the TLS handshake.

You can then test verification against your CA:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/wazuh-indexer/certs/root-ca.pem

Look for:

Verify return code: 0 (ok)

If the verification fails, common causes include:

Incorrect root CA
Missing intermediate CA
Expired certificate
Incorrect certificate chain
Certificate issued by an untrusted CA

Test supported TLS versions

You can explicitly test TLS versions with OpenSSL.

For TLS 1.2:

openssl s_client \
  -connect indexer.example.com:9200 \
  -tls1_2

For TLS 1.3:

openssl s_client \
  -connect indexer.example.com:9200 \
  -tls1_3

A successful connection tells you that the endpoint accepted that TLS version.

Avoid relying on obsolete protocols such as SSLv3 or TLS 1.0/1.1 in production environments.

NIST’s TLS guidance recommends configuring TLS implementations using current protocol versions and appropriately selected cryptographic algorithms rather than relying on obsolete protocols.

You can determine the negotiated version from:

Protocol  : TLSv1.3

or:

Protocol  : TLSv1.2

The exact versions available depend on your Wazuh/OpenSearch version, operating system, Java/runtime components, OpenSSL version, and TLS configuration.

Identify hostname mismatches

Hostname mismatches are one of the easiest TLS problems to diagnose with OpenSSL.

Inspect the SAN:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

Suppose the output contains:

DNS:indexer.internal.example.com

but the Wazuh Dashboard connects to:

https://indexer.example.com:9200

The certificate does not identify the hostname being used.

The correct fix is normally to:

Use a hostname already covered by the certificate, or
Issue a replacement certificate containing the correct SAN.

Do not treat verificationMode: none or similar verification bypasses as the preferred fix.

Check certificate expiration

Use:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

You can also inspect a local certificate:

openssl x509 \
  -in /etc/wazuh-indexer/certs/wazuh-indexer.pem \
  -noout \
  -dates

If:

notAfter

is in the past, renew or replace the certificate.

For production environments, certificate expiration should be monitored before the expiration date.

Diagnose TLS handshake failures

When a TLS handshake fails, run:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -state \
  -debug

The -state option provides useful handshake-state information, while -debug generates considerably more output.

For normal troubleshooting, start without -debug:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com

Then investigate the specific error.

For example:

verify error:num=20:unable to get local issuer certificate

suggests a trust-chain problem.

Whereas:

handshake failure

can indicate incompatible TLS settings, unsupported cipher suites, certificate requirements, or another negotiation failure.

Use the OpenSSL result together with the corresponding Wazuh service logs rather than diagnosing the handshake from one message alone.

Common Wazuh SSL Errors

Wazuh SSL errors can originate from certificates, private keys, CA trust, hostname validation, TLS negotiation, file permissions, or the underlying Wazuh component configuration.

The most effective troubleshooting process is to identify which component is acting as the TLS client and which component is acting as the TLS server.

Wazuh SSL certificate verification failed

A certificate verification error means the client could not establish sufficient trust in the certificate presented by the server.

Common causes include:

Incorrect CA certificate
Expired certificate
Invalid certificate chain
Hostname mismatch
Missing intermediate CA
Incorrect certificate path
Wrong certificate deployed on the server

Test the certificate directly:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/wazuh-indexer/certs/root-ca.pem

Then inspect:

Verify return code

Do not disable verification until you understand why verification is failing.

Wazuh certificate expired

An expired certificate produces a straightforward failure:

certificate has expired

Check:

openssl x509 \
  -in certificate.pem \
  -noout \
  -dates

Replace the certificate with a renewed one signed by the appropriate CA.

After replacing it, verify that:

The new certificate is installed.
The private key matches.
The correct configuration points to the new file.
The service has been restarted.
Clients trust the issuing CA.
The new certificate contains the required SANs.

Certificate rotation should be treated as an operational process rather than an emergency repair.

Wazuh SSL handshake failed

A TLS handshake failure occurs before normal application data can be exchanged.

Possible causes include:

Unsupported TLS version
Incompatible cipher configuration
Certificate failure
Client-certificate requirement not satisfied
Incorrect private key
Incorrect CA
Protocol mismatch
Server-side TLS configuration error

Start with:

openssl s_client \
  -connect host.example.com:port \
  -servername host.example.com

Then inspect the corresponding Wazuh service logs.

Certificate signed by unknown authority

An error such as:

x509: certificate signed by unknown authority

usually means the client does not trust the CA that issued the server certificate.

Verify the issuer:

openssl x509 \
  -in certificate.pem \
  -noout \
  -issuer

Then verify it against the intended CA:

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

If this fails, determine whether the wrong CA is configured or the certificate chain is incomplete.

Certificate hostname mismatch

A hostname mismatch occurs when the client connects to an identity that is not covered by the server certificate.

For example:

Client connects:
indexer.example.com

Certificate contains:
DNS:indexer01.example.com

Inspect the SAN:

openssl x509 \
  -in certificate.pem \
  -noout \
  -ext subjectAltName

Correct the hostname or issue a new certificate containing the required SAN.

This issue commonly appears after changing Wazuh hostnames, moving components to new IP addresses, or placing Wazuh behind a reverse proxy.

Private key does not match certificate

A certificate and private key must belong to the same cryptographic key pair.

Check the certificate’s public key:

openssl x509 \
  -in certificate.pem \
  -pubkey \
  -noout \
  | openssl pkey -pubin -outform DER \
  | sha256sum

Check the private key:

openssl pkey \
  -in private-key.pem \
  -pubout \
  | openssl pkey -pubin -outform DER \
  | sha256sum

The hashes should match.

If they do not, deploy the correct private key or certificate pair.

Incorrect certificate permissions

A Wazuh service can fail to load a perfectly valid certificate because the service account cannot read the file.

Check:

ls -l /path/to/certificate.pem
ls -l /path/to/private-key.pem

Then verify which account runs the service:

systemctl status wazuh-indexer

or:

systemctl status wazuh-dashboard

Do not respond by using:

chmod 777

on certificate directories.

Private keys should have restrictive permissions appropriate to the service account.

Missing CA certificate

A missing CA often produces errors such as:

unable to get local issuer certificate

or:

certificate signed by unknown authority

Check that the configured CA exists:

sudo ls -l /etc/wazuh-indexer/certs/root-ca.pem

Then verify it:

openssl x509 \
  -in /etc/wazuh-indexer/certs/root-ca.pem \
  -noout \
  -subject \
  -issuer

If you have replaced certificates with a new CA, make sure every client that needs to trust that CA has received the new CA certificate.

Invalid certificate chain

A certificate can be valid by itself while its complete chain is invalid or incomplete.

Inspect the server’s presented certificates:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -showcerts

Look for the expected chain:

Root / Trusted CA
       |
Intermediate CA
       |
Server certificate

For public certificates, ensure the server presents the required intermediate certificates.

For private Wazuh PKI, ensure that clients have the CA required to validate the certificates issued by your internal CA.

Wazuh Dashboard HTTPS connection errors

Dashboard HTTPS problems generally fall into two categories.

Browser → Dashboard

Potential causes:

Expired Dashboard certificate
Wrong SAN
Untrusted CA
Missing intermediate certificate
Incorrect Dashboard certificate path
Incorrect private-key permissions

Test:

openssl s_client \
  -connect wazuh.example.com:443 \
  -servername wazuh.example.com

Dashboard → Indexer

Potential causes:

Incorrect Indexer CA
Indexer certificate hostname mismatch
Expired Indexer certificate
Incorrect Indexer URL
Indexer TLS service unavailable
Incorrect opensearch.ssl.* configuration

Test directly from the Dashboard host:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/wazuh-dashboard/certs/root-ca.pem

If this succeeds but the Dashboard still cannot connect, inspect:

/etc/wazuh-dashboard/opensearch_dashboards.yml

and the Dashboard logs.

Wazuh Indexer SSL connection errors

Indexer problems can affect both HTTP clients and other Indexer nodes.

For the HTTPS API:

curl \
  --cacert /etc/wazuh-indexer/certs/root-ca.pem \
  https://indexer.example.com:9200

For deeper TLS analysis:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /etc/wazuh-indexer/certs/root-ca.pem

If the Indexer service itself fails to start, check:

sudo systemctl status wazuh-indexer
sudo journalctl -u wazuh-indexer -n 100 --no-pager

Common causes include:

Incorrect certificate path
Incorrect private-key path
Private key permissions
Certificate/key mismatch
Invalid YAML configuration
Expired certificate
Incorrect CA
Incorrect node certificate
Incorrect nodes_dn configuration in a cluster

Related Guide: How to Fix Wazuh All Shards Failed Error

Wazuh Manager SSL connection errors

Manager SSL problems can affect agent enrollment, Manager-to-Indexer communication, or other secure integrations.

For the Manager-to-Indexer path, inspect:

/var/ossec/etc/ossec.conf

and verify:

<indexer>
  <ssl>
    <certificate_authorities>
      <ca>/path/to/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/path/to/client.pem</certificate>
    <key>/path/to/client-key.pem</key>
  </ssl>
</indexer>

Then test the Indexer from the Manager host:

openssl s_client \
  -connect indexer.example.com:9200 \
  -servername indexer.example.com \
  -CAfile /path/to/root-ca.pem

For agent enrollment and Manager identity verification, inspect the Manager certificate and CA configuration:

<auth>
  <ssl_manager_cert>etc/sslmanager.cert</ssl_manager_cert>
  <ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
</auth>

Then review:

sudo tail -n 100 /var/ossec/logs/ossec.log

The key to troubleshooting Wazuh SSL is to avoid treating every certificate error as the same problem.

Identify the exact connection that is failing, determine which side is the TLS client and server, validate the certificate chain with OpenSSL, confirm SAN and expiration requirements, and then inspect the corresponding Wazuh service configuration and logs.

How to Fix Wazuh SSL Certificate Errors

Wazuh SSL certificate errors are usually caused by one of a few underlying problems: an incorrect certificate path, insufficient permissions, an untrusted CA, an expired certificate, a hostname mismatch, or a certificate/private-key mismatch.

The fastest way to troubleshoot the problem is to work from the certificate files outward rather than immediately changing Wazuh’s TLS verification settings.

Verify certificate paths

Start by checking the certificate paths configured for the affected Wazuh component.

For the Wazuh Dashboard:

sudo grep -E ‘server.ssl|opensearch.ssl’ \

/etc/wazuh-dashboard/opensearch_dashboards.yml

For the Wazuh Indexer:

sudo grep -nE ‘plugins.security.ssl|pemcert|pemkey|pemtrustedcas’ \

/etc/wazuh-indexer/opensearch.yml

For the Wazuh Manager:

sudo grep -n -A15 ‘<indexer>’ /var/ossec/etc/ossec.conf

Then confirm that every referenced file exists:

sudo ls -l /path/to/certificate.pem

sudo ls -l /path/to/private-key.pem

sudo ls -l /path/to/root-ca.pem

A common error is assuming that a certificate was installed correctly because the file exists somewhere on the server.

Wazuh must be configured to use the actual path where the certificate is stored.

For example, this configuration:

server.ssl.certificate: “/etc/wazuh-dashboard/certs/dashboard.pem”

will fail if the actual certificate is:

/etc/wazuh-dashboard/certs/wazuh-dashboard.pem

Check file permissions

The Wazuh service must be able to read its certificate and private key.

Check permissions:

sudo ls -l /path/to/certificate.pem

sudo ls -l /path/to/private-key.pem

Then determine which user runs the affected service:

1. systemctl status wazuh-dashboard

2. systemctl status wazuh-indexer

3. systemctl status wazuh-manager

A private key should not be world-readable.

Avoid using overly permissive settings such as:

chmod 777 /path/to/private-key.pem

Instead, give the relevant service account the minimum access required.

For example:

sudo chown wazuh-dashboard:wazuh-dashboard \

/etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem

sudo chmod 600 \

/etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem

The exact owner and group should match your Wazuh installation and service configuration.

Verify CA trust

If Wazuh reports:

certificate signed by unknown authority

or:

unable to get local issuer certificate

verify that the client has the CA certificate that issued the server certificate.

Test the certificate manually:

openssl verify \

-CAfile /path/to/root-ca.pem \

/path/to/server-certificate.pem

A successful result should be:

server-certificate.pem: OK

If verification fails, inspect the issuer:

openssl x509 \

-in /path/to/server-certificate.pem \

-noout \

-issuer \

-subject

Then inspect the CA:

openssl x509 \

-in /path/to/root-ca.pem \

-noout \

-subject \

-issuer

Make sure you are using the correct CA for the certificate in question.

This distinction matters in larger Wazuh deployments because the Dashboard, Indexer, Manager, and agents may have different TLS relationships and therefore different certificate requirements.

Check certificate and key matching

A certificate must correspond to its private key.

One reliable way to compare them is to derive the public key from each:

openssl x509 \

-in certificate.pem \

-pubkey \

-noout \

| openssl pkey -pubin -outform DER \

| sha256sum

Then:

openssl pkey \

-in private-key.pem \

-pubout \

| openssl pkey -pubin -outform DER \

| sha256sum

The resulting hashes should be identical.

If they differ, you have deployed the wrong private key or certificate.

You can also validate that the private key itself is structurally sound:

openssl pkey \

-in private-key.pem \

-check

Correct hostname/SAN configuration

A certificate can be correctly signed and unexpired but still fail validation because its identity does not match the hostname used by the Wazuh component.

Inspect the SANs:

openssl x509 \

-in certificate.pem \

-noout \

-ext subjectAltName

For example, if Wazuh connects to:

https://indexer.example.com:9200

the Indexer’s certificate should contain an appropriate SAN such as:

DNS:indexer.example.com

If administrators access the Dashboard through:

https://wazuh.example.com

the Dashboard certificate should contain:

DNS:wazuh.example.com

Do not rely solely on the certificate’s Common Name (CN) to solve modern hostname-validation problems.

Use Subject Alternative Names.

Replace expired certificates

Check the certificate:

openssl x509 \

-in certificate.pem \

-noout \

-dates

If notAfter has passed, generate or obtain a replacement certificate.

Before replacing it, verify that the new certificate contains:

The correct hostname
Required IP SANs, if applicable
The correct issuing CA
A valid expiration period
The appropriate key usage/extensions

You can inspect the replacement certificate before deploying it:

openssl x509 \

-in new-certificate.pem \

-noout \

-subject \

-issuer \

-dates \

-ext subjectAltName

This avoids replacing a bad certificate with another bad certificate.

Restart affected Wazuh services

After correcting certificate files or configuration, restart the affected service.

Dashboard:

sudo systemctl restart wazuh-dashboard

Indexer:

sudo systemctl restart wazuh-indexer

Manager:

sudo systemctl restart wazuh-manager

Filebeat, where applicable:

sudo systemctl restart filebeat

Then immediately check the service:

sudo systemctl status wazuh-dashboard

or:

sudo systemctl status wazuh-indexer

Do not restart every Wazuh component simultaneously unless your maintenance procedure requires it.

Restarting only the affected service makes troubleshooting easier and reduces unnecessary service disruption.

Review Wazuh and OpenSearch logs

If the service does not start or communication still fails, inspect the logs.

Wazuh Manager:

sudo tail -n 100 /var/ossec/logs/ossec.log

Dashboard:

sudo journalctl -u wazuh-dashboard -n 100 –no-pager

Indexer:

sudo journalctl -u wazuh-indexer -n 100 –no-pager

You can search specifically for TLS-related messages:

sudo grep -Ei \

‘ssl|tls|certificate|x509|handshake|trust|verify|key’ \

/var/ossec/logs/ossec.log

For an Indexer cluster, also inspect OpenSearch security-related logs when available.

Look for messages indicating:

certificate expired

certificate verify failed

unknown CA

hostname verification failed

private key

SSL handshake

PKIX path building

The exact error often identifies which part of the TLS configuration needs attention.

Related Guide How to Fix Wazuh Certificate Errors

Test the TLS connection again

After fixing the configuration, test the connection independently with OpenSSL.

For the Dashboard:

openssl s_client \

-connect wazuh.example.com:443 \

-servername wazuh.example.com

For the Indexer:

openssl s_client \

-connect indexer.example.com:9200 \

-servername indexer.example.com \

-CAfile /path/to/root-ca.pem

Look for:

Verify return code: 0 (ok)

Then test the actual application connection.

For example:

curl \

–cacert /path/to/root-ca.pem \

https://indexer.example.com:9200

If OpenSSL succeeds but the Wazuh component still fails, the problem is more likely to be within the component’s configuration, permissions, authentication, or application layer.

How to Renew Wazuh SSL Certificates

Certificate renewal should be treated as a planned maintenance operation.

Wazuh deployments commonly use certificates for several different TLS relationships, so renewing one certificate does not necessarily mean replacing every certificate in the environment.

Before beginning, identify:

Component Certificate Renewal date

Dashboard dashboard certificate YYYY-MM-DD

Indexer node certificate YYYY-MM-DD

Manager manager certificate YYYY-MM-DD

Agent agent certificate YYYY-MM-DD

CA root/intermediate CA YYYY-MM-DD

The exact certificate architecture depends on how your Wazuh environment was deployed.

Determine when certificates expire

Use OpenSSL:

openssl x509 \

-in /path/to/certificate.pem \

-noout \

-enddate

For more information:

openssl x509 \

-in /path/to/certificate.pem \

-noout \

-subject \

-issuer \

-dates

You can inspect multiple certificates:

for cert in /path/to/certs/*.pem; do

echo “=== $cert ===”

openssl x509 -in “$cert“ -noout -subject -enddate 2>/dev/null

done

This provides a quick inventory of certificate expiration dates.

Do not wait until the certificate has expired.

A certificate renewal process should allow enough time to test the replacement and recover if something goes wrong.

Generate replacement certificates

The replacement certificate should preserve the identities required by the service.

For example, a replacement Indexer certificate should contain the appropriate Indexer hostname and any other required SANs.

Before generating it, document the existing certificate:

openssl x509 \

-in old-certificate.pem \

-noout \

-subject \

-issuer \

-ext subjectAltName

Then generate the replacement certificate through your chosen PKI.

For an internal CA, this may involve generating a new private key and CSR:

openssl req \

-new \

-newkey rsa:3072 \

-nodes \

-keyout new-server.key \

-out new-server.csr

The CSR should be signed by the appropriate CA.

If your organization uses an enterprise PKI, use its certificate issuance process instead of creating an ad-hoc certificate with a local OpenSSL command.

For a Wazuh-generated certificate infrastructure, follow the certificate-generation procedure appropriate to your Wazuh version and deployment architecture.

Replace certificates safely

Do not immediately overwrite the only copy of your working certificate.

Create a backup:

sudo cp certificate.pem certificate.pem.bak

sudo cp private-key.pem private-key.pem.bak

Then install the replacement files.

For example:

sudo cp new-certificate.pem /path/to/certificate.pem

sudo cp new-private-key.pem /path/to/private-key.pem

Set appropriate ownership and permissions afterward:

sudo chown <service-user>:<service-group> \

/path/to/private-key.pem

sudo chmod 600 /path/to/private-key.pem

Before restarting the service, verify the replacement certificate:

openssl x509 \

-in /path/to/certificate.pem \

-noout \

-subject \

-issuer \

-dates \

-ext subjectAltName

Also verify that the new key matches the certificate.

Update Wazuh configuration

If the new certificate uses the same filename and path, you may not need to modify the Wazuh configuration.

If the filename or location changes, update the corresponding configuration.

Dashboard:

/etc/wazuh-dashboard/opensearch_dashboards.yml

Manager:

/var/ossec/etc/ossec.conf

Indexer:

/etc/wazuh-indexer/opensearch.yml

Filebeat:

/etc/filebeat/filebeat.yml

After modifying configuration, validate the relevant syntax before restarting where the component provides a configuration-validation mechanism.

Restart services

Restart only the services affected by the certificate change.

For example:

sudo systemctl restart wazuh-dashboard

or:

sudo systemctl restart wazuh-indexer

For Manager certificates:

sudo systemctl restart wazuh-manager

For Filebeat:

sudo systemctl restart filebeat

Check immediately:

sudo systemctl status <service>

If a service fails, inspect its logs before making additional changes.

Verify the new certificate

Use OpenSSL against the live service:

openssl s_client \

-connect wazuh.example.com:443 \

-servername wazuh.example.com

Then inspect the returned certificate:

openssl s_client \

-connect wazuh.example.com:443 \

-servername wazuh.example.com \

</dev/null 2>/dev/null \

| openssl x509 -noout \

-subject \

-issuer \

-dates \

-ext subjectAltName

Confirm that the live endpoint is serving the replacement certificate rather than an old certificate.

This distinction is important when a reverse proxy, load balancer, or other TLS termination point sits in front of Wazuh.

Plan certificate renewal before expiration

Certificate renewal should be part of normal Wazuh maintenance.

A practical process is:

Inventory every Wazuh certificate.
Record the issuing CA and expiration date.
Set an internal renewal deadline before expiration.
Generate replacement certificates.
Validate SANs and certificate chains.
Back up existing certificates.
Deploy replacements.
Restart affected services.
Test TLS connections.
Verify Wazuh component health.
Document the completed renewal.

For larger deployments, automate certificate-expiration monitoring instead of relying on manual checks.

This is particularly important for Wazuh environments with multiple Indexer nodes, because one expired node certificate can create cluster communication problems even when the other nodes remain healthy.

Wazuh SSL Security Best Practices

Correct TLS configuration is only the first step.

The certificate infrastructure itself needs to be secured and maintained.

Wazuh recommends using certificates and trusted CAs for secure communication between its components, while OpenSearch Security provides TLS controls for encrypted and authenticated communication within the Indexer layer.

The OpenSearch documentation also distinguishes between transport-layer TLS used between nodes and REST-layer TLS used for client/API communication.

Use a trusted Certificate Authority

Use a CA that the systems participating in the TLS connection actually trust.

For production Wazuh environments, this could be:

An organization’s internal PKI
An enterprise CA
A public CA for externally exposed services

A private CA is often appropriate for internal Wazuh-to-Wazuh communication because administrators control the trust store.

For a publicly accessible Dashboard, a publicly trusted CA may simplify browser trust.

The important point is that the certificate issuer must be trusted by the systems that validate the certificate.

Use strong private-key protection

Private keys are security-sensitive credentials.

Protect them by:

Restricting filesystem permissions
Limiting administrative access
Avoiding unnecessary copies
Encrypting backups
Protecting configuration repositories
Never committing private keys to Git repositories

A certificate can safely be distributed much more broadly than its corresponding private key.

If an unauthorized party obtains a private key, the security implications can be substantially more serious than simply having access to the public certificate.

Avoid disabling certificate verification

Avoid configurations that effectively turn TLS into encrypted-but-unverified communication.

For example, do not routinely use:

curl -k

as the permanent solution to a certificate error.

Likewise, do not disable Wazuh or OpenSearch certificate verification simply because a hostname or CA is incorrectly configured.

The purpose of certificate validation is to provide authentication in addition to encryption.

If verification fails, identify and correct the underlying problem.

Use correct SANs

Every certificate should contain the identities through which the service is actually accessed.

For example:

DNS:wazuh.example.com

DNS:wazuh-dashboard.example.com

or, where appropriate:

IP Address:10.10.10.20

Before deploying a certificate, inspect:

openssl x509 \

-in certificate.pem \

-noout \

-ext subjectAltName

This is especially important when:

Hostnames change
Nodes are migrated
Load balancers are introduced
Reverse proxies are added
Wazuh Indexer clusters are expanded

Restrict certificate file permissions

Public certificates do not require the same protection as private keys.

Private keys should have restrictive permissions:

chmod 600 private-key.pem

and appropriate ownership:

chown <service-user>:<service-group> private-key.pem

Avoid giving ordinary users access to directories containing Wazuh private keys.

Also check backups. A secure production server can still be compromised if unprotected copies of its private keys exist elsewhere.

Monitor certificate expiration

Certificate expiration should be monitored just like CPU, memory, disk utilization, and service availability.

At minimum, regularly run:

openssl x509 \

-in certificate.pem \

-noout \

-enddate

For larger deployments, automate the process and alert administrators before expiration.

A good operational policy is to have several warning thresholds rather than one alert on the actual expiration date.

For example:

90 days — planning notification

60 days — renewal preparation

30 days — high-priority reminder

7 days — escalation

The exact thresholds should match your organization’s certificate-management policy.

Rotate certificates regularly

Certificate rotation should not be performed only after a certificate expires or is compromised.

Regular rotation limits the operational impact of:

Key compromise
Stale certificates
Outdated cryptographic parameters
Forgotten certificates
Personnel changes
PKI changes

Maintain a documented process for replacing certificates without disrupting Wazuh services.

Related Guide: How to Fix Wazuh Certificate Errors

Protect CA private keys

The CA private key is considerably more sensitive than an individual server certificate.

If an attacker obtains a CA private key, they may be able to issue certificates that appear trustworthy to systems configured to trust that CA.

Therefore:

Do not store the CA private key on every Wazuh server.
Restrict CA administration to authorized personnel.
Use secure CA infrastructure where possible.
Encrypt CA backups.
Maintain offline or otherwise protected backups.
Record certificate issuance and revocation procedures.
Rotate the CA only according to a controlled PKI plan.

In other words, Wazuh nodes should receive certificates signed by the CA; they generally should not need access to the CA’s private signing key.

Use modern TLS versions

Use currently supported TLS protocols and disable obsolete protocols according to your Wazuh, OpenSearch, Java, operating-system, and organizational compatibility requirements.

Test the endpoint:

openssl s_client \

-connect indexer.example.com:9200 \

-tls1_2

and, where supported:

openssl s_client \

-connect indexer.example.com:9200 \

-tls1_3

Do not blindly enable every protocol supported by the underlying operating system. Your TLS policy should prioritize currently supported protocols and cryptographic configurations.

NIST’s TLS recommendations provide a useful baseline for selecting secure protocol versions and cryptographic settings.

Maintain consistent certificates across Wazuh components

In a multi-component deployment, keep the certificate architecture consistent.

For example:

Root CA

+————+————+

| | |

Dashboard Indexer Manager

| |

| Indexer

nodes

Clients

Each certificate should have a clearly defined purpose and identity.

For an Indexer cluster, make sure node certificates and trust relationships are consistent with the cluster’s security configuration.

For Dashboard-to-Indexer communication, make sure the Dashboard trusts the CA that issued the Indexer certificate.

Make sure the Manager’s configured CA and client credentials correspond to the Indexer’s TLS configuration for Manager-to-Indexer communication.

For agent enrollment, ensure that the CA and Manager certificate used for identity verification are consistent with the agent configuration.

Document certificate ownership and renewal procedures

Certificate management becomes significantly harder when nobody knows:

Who owns the certificate
Which CA issued it
Where the private key is stored
Which Wazuh component uses it
When it expires
Which hostname it covers
How it should be renewed
Which services must be restarted
How the replacement should be tested

Also document the renewal procedure, including where certificates are deployed and which services must be restarted.

This turns Wazuh SSL certificate management from an emergency troubleshooting task into a repeatable operational process.

A well-maintained certificate inventory also makes incident response easier because administrators can quickly determine which credentials may need to be revoked or replaced following a suspected compromise.

Finally, remember that TLS is not merely an encryption mechanism.

Proper Wazuh SSL configuration provides confidentiality, integrity, and, when certificate validation is correctly configured, authentication of the systems participating in the connection.

That makes certificate lifecycle management, CA protection, hostname validation, and continuous monitoring fundamental parts of securing a Wazuh deployment.

Wazuh SSL vs. Wazuh TLS

The term Wazuh SSL is widely used when discussing Wazuh certificate configuration, HTTPS, encrypted agent communication, and secure Wazuh component communication.

Technically, however, modern deployments should use TLS (Transport Layer Security) rather than the older SSL protocols.

Wazuh documentation and configuration options may still use terminology such as ssl, ssl_manager_cert, or opensearch.ssl because these names are part of existing configuration interfaces and software conventions.

SSL vs. TLS terminology

SSL (Secure Sockets Layer) was the predecessor to TLS.

Also, SSL 2.0 and SSL 3.0 are obsolete and should not be used for modern deployments.

TLS replaced SSL and has evolved through several versions:

SSL 2.0

↓

SSL 3.0

↓

TLS 1.0

↓

TLS 1.1

↓

TLS 1.2

↓

TLS 1.3

When administrators search for Wazuh SSL, they are generally referring to the broader process of configuring certificates and TLS-secured communications within a Wazuh environment.

This terminology is common throughout the Wazuh ecosystem.

For example, configuration parameters can contain ssl even though the underlying protocol being negotiated is TLS.

Why Wazuh documentation may use both terms

You may encounter settings such as:

<ssl_manager_cert>…</ssl_manager_cert>

<ssl_manager_key>…</ssl_manager_key>

or:

opensearch.ssl.certificateAuthorities:

– “/path/to/root-ca.pem”

The ssl naming does not necessarily mean that the service is using an obsolete SSL protocol.

In many software projects, ssl remains part of configuration names because it is the established terminology for certificate-based secure communication.

Consequently, the distinction is:

“Wazuh SSL” is a common configuration and search term; TLS is the modern protocol technology that should be used.

Which TLS versions should be used

For modern Wazuh deployments, use TLS versions supported by your Wazuh and OpenSearch versions and compatible with your organization’s security policy.

TLS 1.2 is widely supported, while TLS 1.3 provides a newer protocol design where the underlying software stack supports it.

You can test a Wazuh endpoint with:

openssl s_client \

-connect indexer.example.com:9200 \

-tls1_2

And, where supported:

openssl s_client \

-connect indexer.example.com:9200 \

-tls1_3

Check the negotiated protocol:

Protocol : TLSv1.3

or:

Protocol : TLSv1.2

Do not select a TLS version simply because OpenSSL can test it. The appropriate protocol depends on the versions of Wazuh, OpenSearch, Java, OpenSSL, operating system, and other components involved.

NIST’s TLS guidance provides recommendations for selecting and configuring secure TLS versions and cryptographic algorithms.

Why legacy SSL protocols should be avoided

SSL 2.0 and SSL 3.0 are obsolete and should not be enabled in production.

Likewise, TLS 1.0 and TLS 1.1 have been deprecated for modern security use.

The goal of a Wazuh TLS configuration should not simply be:

“Enable encryption.”

It should be:

“Enable authenticated, encrypted communication using an appropriate modern TLS configuration.”

Using modern TLS also reduces exposure to weaknesses associated with obsolete protocol versions and cryptographic mechanisms.

Wazuh SSL vs. HTTPS

Wazuh SSL and HTTPS are related concepts, but they are not interchangeable.

HTTPS means:

HTTP + TLS

It describes HTTP traffic protected by TLS.

Wazuh, however, uses encrypted communications for more than browser-based HTTP traffic.

What SSL/TLS provides

TLS provides several important security properties:

Confidentiality — helps prevent unauthorized parties from reading transmitted data.
Integrity — helps detect modification of data in transit.
Authentication — certificates can establish the identity of the endpoint when certificate validation is correctly configured.

For example:

Wazuh Dashboard

| TLS

Wazuh Indexer

The TLS connection can encrypt the communication and validate the Indexer’s certificate.

With mutual TLS or client certificates, both sides can also authenticate each other.

What HTTPS means

HTTPS specifically means HTTP traffic transmitted over TLS.

For example:

Browser

| HTTPS

Wazuh Dashboard

When you visit:

https://wazuh.example.com

the browser is using HTTP over a TLS-protected connection.

HTTPS therefore describes the application protocol and transport security combination, not every encrypted communication channel within a Wazuh deployment.

How Wazuh Dashboard uses HTTPS

The Wazuh Dashboard can expose its web interface over HTTPS using a TLS certificate and private key.

A typical configuration includes settings such as:

server.ssl.enabled: true

server.ssl.certificate: “/path/to/dashboard.pem”

server.ssl.key: “/path/to/dashboard-key.pem”

The browser validates the Dashboard’s certificate and then establishes an encrypted HTTPS connection.

The Dashboard can simultaneously establish its own TLS connection to the Wazuh Indexer:

Browser

| HTTPS

Dashboard

| HTTPS/TLS

Indexer

These are two separate TLS connections.

A valid Dashboard certificate does not automatically mean that the Dashboard trusts the Indexer’s certificate.

Why HTTPS alone does not describe all Wazuh encrypted communications

A Wazuh environment can contain multiple TLS-secured communication paths:

Browser

| HTTPS

Dashboard

| TLS

Indexer

| TLS

Indexer nodes

Manager

| HTTPS/TLS

Indexer

Agent

| Encrypted agent communication

Manager

Only the first connection in this example is necessarily described as HTTPS from the user’s perspective.

The other connections may use TLS through different protocols and application layers.

This is why Wazuh SSL/TLS configuration is a more accurate description of the overall security architecture than simply saying “enable HTTPS.”

Frequently Asked Questions

Question: What is Wazuh SSL?

Wazuh SSL generally refers to configuring certificates and encrypted communications in a Wazuh deployment.

Technically, modern Wazuh environments use TLS rather than obsolete SSL protocols.

Wazuh SSL configuration can involve the Dashboard, Indexer, Manager, agents, and other components.

Question: Does Wazuh use SSL or TLS?

Modern Wazuh deployments use TLS for secure communications. The term “SSL” remains common in configuration names, documentation, and search queries.

When configuring a new deployment, use modern TLS versions supported by your Wazuh and underlying software stack rather than legacy SSL protocols.

Question: Does Wazuh require SSL certificates?

Certificate requirements depend on the specific communication path and Wazuh deployment architecture.

Wazuh’s standard secured deployments use certificates for TLS communication between components such as the Dashboard and Indexer and for other certificate-based security mechanisms.

The Wazuh installation process can generate certificates for the components in a standard deployment.

Question: How do I configure SSL in Wazuh?

The process depends on the component.

At a high level:

Create or obtain a trusted CA.
Generate certificates for Wazuh components.
Install certificates and private keys.
Configure the relevant Wazuh component.
Configure CA trust.
Restart the affected service.
Test the TLS connection with OpenSSL.
Review Wazuh and OpenSearch logs.

The Dashboard, Indexer, Manager, and agents have different configuration requirements.

Question: Where are Wazuh SSL certificates stored?

Certificate locations depend on the Wazuh component and deployment method.

Common locations include:

/etc/wazuh-dashboard/certs/

/etc/wazuh-indexer/certs/

/var/ossec/etc/

/etc/filebeat/certs/

Do not assume that every Wazuh installation uses exactly the same paths.

The authoritative location is the path specified in the component’s active configuration.

Question: How do I generate Wazuh SSL certificates?

For a standard Wazuh deployment, certificates can be generated using the certificate-generation process provided by Wazuh.

You can also use an organization’s internal PKI or another trusted CA.

Regardless of the certificate-generation method, ensure that certificates contain the correct Subject Alternative Names and are signed by a CA trusted by the systems that need to validate them.

Question: How do I enable HTTPS in Wazuh Dashboard?

Enable HTTPS in the Dashboard configuration and specify the server certificate and private key.

A typical configuration includes:

server.ssl.enabled: true

server.ssl.certificate: “/path/to/dashboard.pem”

server.ssl.key: “/path/to/dashboard-key.pem”

After changing the configuration:

sudo systemctl restart wazuh-dashboard

Then test:

curl -I https://wazuh.example.com

You can inspect the TLS connection with:

openssl s_client \

-connect wazuh.example.com:443 \

-servername wazuh.example.com

Question: How do I verify a Wazuh SSL certificate?

Use OpenSSL:

openssl x509 \

-in certificate.pem \

-noout \

-subject \

-issuer \

-dates \

-ext subjectAltName

This allows you to check:

Certificate subject
Issuing CA
Expiration dates
SANs

You can also test the certificate against a CA:

openssl verify \

-CAfile root-ca.pem \

certificate.pem

A successful verification should return:

certificate.pem: OK

Question: How do I renew a Wazuh SSL certificate?

First determine which certificate is expiring:

openssl x509 \

-in certificate.pem \

-noout \

-enddate

Generate or obtain a replacement certificate with the appropriate SANs, back up the existing certificate and key, install the replacement, update the configuration if necessary, restart the affected service, and verify the live endpoint.

Certificate renewal should ideally be completed before expiration.

Question: How do I fix a Wazuh SSL certificate error?

Start by identifying the exact error.

Then check:

Certificate path
Certificate expiration
SANs
CA trust
Certificate chain
Private-key permissions
Certificate/key matching
TLS protocol compatibility
Wazuh configuration
Service logs

Use:

openssl s_client \

-connect hostname:port \

-servername hostname

to determine whether the TLS connection itself is working.

Related Guide: How to Fix Wazuh Certificate Errors

Question: Why is my Wazuh SSL certificate not trusted?

The certificate is usually not trusted because the client does not have the CA that issued it, the certificate chain is incomplete, or the wrong CA has been configured.

Test:

openssl verify \

-CAfile root-ca.pem \

certificate.pem

If verification fails, inspect the certificate issuer and CA before replacing the certificate.

Question: How do I fix a Wazuh SSL handshake error?

First determine whether the failure occurs during:

Certificate exchange
Certificate validation
TLS version negotiation
Cipher negotiation
Client authentication
Hostname validation

Start with:

openssl s_client \

-connect hostname:port \

-servername hostname

Then inspect the Wazuh or OpenSearch logs for the corresponding timestamp.

A handshake failure does not necessarily mean the certificate is expired.

TLS protocol compatibility, certificate requirements, CA configuration, and private keys can also cause handshake failures.

Question: Can I use self-signed certificates with Wazuh?

Yes, a Wazuh environment can use a private/self-managed CA, which is often more appropriate terminology than calling each server certificate “self-signed.”

A stronger architecture is:

Private Root CA

+—- Dashboard certificate

+—- Indexer certificate

+—- Manager certificate

+—- Agent certificates

Each component certificate is signed by the trusted private CA.

A truly self-signed server certificate can be trusted if explicitly configured, but managing a private CA generally provides a more scalable trust model for multiple Wazuh components.

Question: How often should Wazuh SSL certificates be renewed?

There is no single renewal interval that applies to every Wazuh installation.

The appropriate interval depends on:

Certificate type
CA policy
Organizational security requirements
Certificate lifetime
Number of Wazuh components
Automation capabilities
Risk tolerance

More important than selecting an arbitrary interval is ensuring that certificates are monitored, renewed before expiration, and rotated through a documented process.

For production environments, maintain an inventory of certificates and alert administrators well before their expiration dates.

Conclusion

Configuring Wazuh SSL is ultimately about establishing trusted, encrypted communication between the different components of a Wazuh deployment.

A secure configuration requires more than simply enabling HTTPS.

You need to manage the entire certificate lifecycle, including certificate generation, CA trust, SAN configuration, private-key protection, certificate deployment, validation, renewal, and monitoring.

Recap of Wazuh SSL configuration

The basic workflow is:

Create or select CA

↓

Generate component certificates

↓

Install certificates and private keys

↓

Configure Wazuh components

↓

Configure CA trust

↓

Restart services

↓

Test TLS connections

↓

Monitor certificates

The Dashboard requires a valid HTTPS certificate for browser access, while the Indexer and Manager have additional TLS relationships that must be configured independently.

Agent communication and enrollment can also involve certificate-based identity verification depending on the security configuration.

Importance of proper certificate management

Certificates should be treated as security infrastructure rather than ordinary configuration files.

A strong Wazuh SSL implementation should have:

A clearly defined CA
Correct SANs
Protected private keys
Appropriate file permissions
Trusted certificate chains
Modern TLS protocols
Documented renewal procedures
Certificate-expiration monitoring
Tested backup and recovery procedures

Poor certificate management can result in outages, failed agent enrollment, broken Dashboard-to-Indexer communication, or loss of access to the Wazuh environment.

SSL/TLS verification and monitoring

OpenSSL should be one of your primary troubleshooting tools.

For example:

openssl s_client \

-connect hostname:port \

-servername hostname

and:

openssl x509 \

-in certificate.pem \

-noout \

-subject \

-issuer \

-dates \

-ext subjectAltName

These commands allow you to independently verify certificate identity, expiration, SANs, and TLS connectivity.

Do not rely exclusively on whether a Wazuh service starts successfully. A service can be running while another component is unable to establish a trusted TLS connection to it.

Recommended next steps for securing a Wazuh deployment

After completing your Wazuh SSL configuration, continue by reviewing the broader security architecture:

Verify every TLS communication path, not just Dashboard HTTPS.
Inventory all certificates and expiration dates.
Protect CA and component private keys.
Use correct SANs for every Wazuh hostname.
Avoid disabling TLS certificate verification.
Monitor certificate expiration automatically.
Document your certificate renewal procedure.
Review Wazuh RBAC and access controls.
Secure Wazuh SSO and identity-provider integrations.
Test your Wazuh deployment after certificate rotation.

For environments using SSO, certificate management should also be coordinated with the authentication infrastructure.

Changes to IdP certificates, SAML signing certificates, OIDC configurations, or reverse-proxy TLS certificates can introduce authentication failures even when the underlying Wazuh services remain operational.

Ultimately, the goal of Wazuh SSL is not simply to make the Dashboard display a padlock icon.

The objective is to create a trusted, encrypted, verifiable communication architecture across the Wazuh stack and maintain that architecture throughout the entire certificate lifecycle.