Setting up Graylog Data Node and its certificate authority: what it does and when you need it
If you are standing up Graylog for production, you must choose a search backend before you install anything, and Graylog recommends Data Node for that role. Data Node is the managed OpenSearch backend that Graylog ships and operates for log storage, so you do not have to assemble and tune a separate OpenSearch cluster yourself. Its certificates are part of the design, not an afterthought: plan the certificate authority, the hostnames and the renewal process before the first install, because the Data Nodes and Graylog servers must trust each other from the start. Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, so confirm with your legal and procurement teams that this license works for your organization before you commit to the stack. Also note that use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so any self-managed OpenSearch backend on that line is a migration item, not a long-term option.
The Graylog documentation for the current 7.2 line is the reference to follow, but the version you install must match the compatibility matrix exactly. That matrix pairs each Graylog release with supported MongoDB and OpenSearch or Data Node versions, so check it for the precise release you plan to deploy and record the pairing in your change request. Before you run the preflight step, confirm which Data Node version the matrix lists for your target Graylog version, which operating system packages you will use, and whether your team will manage the certificate authority or use Graylog's built-in option. Those answers determine the rest of the build sequence.
Choosing between the Graylog CA and your own certificates
This table compares the Graylog-generated certificate authority with a certificate authority your organization already operates, with self-managed OpenSearch as a fallback. Read each row as a question you must answer before the Data Node certificates are issued, and use the takeaway to decide who owns renewal and trust distribution.
| Decision point | Graylog-generated CA | Your organization's CA | Self-managed OpenSearch fallback |
|---|---|---|---|
| When it fits | Isolated or new environments with no internal PKI, and teams that accept Graylog managing trust for Data Node and Graylog servers | Organizations with an existing internal PKI, policy requiring issued certificates from a managed CA, or existing monitoring of certificate expiry | Cases where Data Node is not used and an existing OpenSearch cluster must be kept, which Graylog documents as deprecated for 1.x versions |
| Who renews and rotates | Graylog-side tooling and the Graylog team's procedure, so confirm the documented renewal steps for your release | Your PKI team, using its own issuance and renewal workflow, with Graylog staff updating certificate files on hosts | Your platform team, including TLS for node and client traffic configured through the OpenSearch Security plugin |
| How trust reaches hosts | Trust material is distributed from the generated authority to Graylog servers and Data Nodes during setup | Your root or intermediate chain is installed on every Graylog server and Data Node, and must be updated when the chain changes | Trust is configured per node and per client in OpenSearch Security settings, so each node needs matching material |
| Revocation and inventory | Inventory is limited to what Graylog generates, so record each certificate and its host in your own register | Revocation and expiry monitoring can use existing tooling, provided Data Node hosts are added to the inventory | Inventory and revocation depend on your own processes, and must cover every node and client |
| Operational trade-off | Lower setup effort, but the internal trust root sits outside your PKI governance and audit tooling | More setup work and coordination, but certificates follow your organization's policy and audit evidence | Most flexible for existing clusters, but it adds a second search stack to secure, patch and back up |
| Questions to confirm | Where the generated authority's key material is stored and who can access it | Whether your PKI can issue server certificates with the Subject Alternative Names each Data Node requires | Which OpenSearch version your Graylog release supports, using the compatibility matrix |
Installing Data Node with its certificate authority, step by step
This sequence takes a team from a compatible version set to a verified Data Node cluster that Graylog servers trust over TLS. Each step ends with a check so that a failure is caught on the host where it happens, not after Graylog is pointed at the cluster.
Confirm versions and operating system support
Before touching any host, check the Graylog compatibility matrix for the Graylog release you plan to run, the MongoDB version it requires, and the Data Node release and operating system the installation documentation lists for that Graylog version. Graylog recommends Data Node as the search backend, and OpenSearch 1.x use is deprecated from Graylog 7.0, so do not plan a new build around it. Record the chosen versions in your change ticket. The step is done when every host in the plan runs an operating system on the supported list and the version set is written down and approved by the owner of the Graylog platform.
Run the preflight step on each Data Node host
On each planned Data Node host, run the preflight command from the Graylog installation documentation before installing the Data Node package. The check confirms system settings such as memory maps, file limits and disk layout that the search engine depends on. Run it on every host, not only the first one, because hosts often differ in kernel settings or free disk. The step is done when the preflight reports no failing checks on every host, and any warning you accept is recorded with the reason it is safe in your environment.
Create or import the certificate authority and node certificates
Decide whether Data Node will use the certificate authority that Graylog generates or a CA your organization already operates. If you use your own CA, issue one certificate per Data Node with subject alternative names that match the hostnames Graylog servers will use, and keep the private keys readable only by the service account. If you use the Graylog-generated CA, export its root certificate so you can distribute it to Graylog servers in the next steps. The step is done when each node has a certificate and key pair, and you can run an openssl x509 check on each certificate showing the expected names and an expiry date you have written down.
Configure Data Node with certificate paths and hostnames
On each Data Node, set the certificate, key and CA file paths and the hostname or address the node advertises in its Data Node configuration file, following the parameter names in the Graylog documentation for your version. Give each node a unique name and make sure the advertised address resolves from the other Data Nodes and from every Graylog server. Keep the configuration files under version control with secrets referenced rather than pasted in. The step is done when the configuration validates and each node reports the file paths it loaded in its startup log without a certificate error.
Install Data Nodes on separate hosts
Install the Data Node package on each host with the configuration from the previous step, and start the service one node at a time. Keep Data Nodes on their own hosts, separate from Graylog servers and MongoDB, so that search storage and the Graylog application do not compete for memory and disk. For a medium or large deployment, the multi-node guide describes a three-node Data Node cluster. The step is done when each service is running, every node appears in the cluster on the first host, and no node reports a join or certificate error in its log.
Connect Graylog servers with the matching trust chain
Copy the CA root certificate, and the Data Node settings that Graylog needs, to each Graylog server and point its configuration at the Data Node addresses over TLS. Confirm that each Graylog server trusts the same CA that signed the Data Node certificates, and that the hostnames in the Graylog configuration match the subject alternative names. Restart the Graylog servers one at a time so that inputs keep running on the remaining nodes. The step is done when each Graylog server starts, and its log shows a successful connection to the Data Node cluster with no TLS verification errors.
Verify cluster health and Graylog visibility
Check the Data Node cluster health from the API or the Data Node tooling, and confirm the status is green with all expected nodes present and no unassigned shards. Then open the Graylog web interface and confirm that the system overview lists the Data Node cluster as the search backend, that an index set can be created on it, and that a test message sent through an input is searchable. Record the health output and the test message ID. The step is done when cluster health is reported as healthy, Graylog lists the cluster, and the test message is found by a search.
Plan certificate renewal before go-live
Before the cluster takes production traffic, write down the expiry date of every node certificate and the CA, set a calendar reminder well ahead of each date, and test a renewal on a non-production copy. Renewal means reissuing the node certificates, replacing the files on each Data Node, restarting the nodes one at a time, and updating the trust chain on each Graylog server if the CA changed. Ask your Graylog partner or Graylog support to confirm the renewal steps for your exact version. The step is done when the renewal runbook has been rehearsed once and the expiry dates are in your monitoring.
Certificate decisions by environment
Most production Graylog deployments on a connected network can use certificates issued by an internal public key infrastructure (PKI) that your security team already operates. The Graylog Data Node setup lets you use the Graylog-generated certificate authority or your own certificates, and an internal CA usually gives you the audit trail, naming control and revocation handling that your existing policies expect. The decision is less about the technology and more about who owns issuance and renewal.
- Certificate source: Issue node and transport certificates from your internal CA, with subject names and subject alternative names that match the Data Node hostnames your Graylog servers use to connect.
- Renewal owner: Name a team, usually the PKI or platform team, and add renewal dates to the same change calendar that tracks Graylog and MongoDB maintenance.
- Trust distribution: Confirm that every Graylog server node trusts the issuing CA chain before the first cluster join, not after a failed connection.
- Verification: Check each certificate's validity dates, chain and names from every Graylog node, and confirm that Data Node reports a healthy cluster after restart.
- Revocation and rotation: Ask your PKI team how revoked or replaced certificates are handled and whether a rotation can happen without a full cluster outage.
Before go-live, confirm the exact certificate and key format that your Graylog and Data Node versions expect in the official installation documentation for your release.",
On an air-gapped or restricted network, Graylog and Data Node cannot rely on public certificate authorities or on automatic validation services. The certificate material has to be generated, signed and moved inside the boundary through an approved process. This usually makes the generated certificate authority or an offline internal CA the practical choice, but the handling rules matter more than the tool.
- Certificate source: Use a CA that lives inside the network, either an offline root that signs intermediates or the certificate authority generated during setup, with the private key stored under your key custody rules.
- Renewal owner: Assign renewal to a named role with physical or logical access to the signing process, and document how that role is notified before expiry.
- Transfer controls: Record how certificate files and keys cross the boundary, who approved the transfer and where copies are destroyed.
- Verification: Confirm trust on each node offline, using the CA material you carried in, and check that no component attempts to fetch certificate status or updates from outside the network.
- Recovery: Keep a tested procedure for reissuing certificates if a key is lost or a node is rebuilt, because you cannot count on an external service to help.
Ask your security architect to confirm how your restricted zone handles offline key ceremonies before the design is fixed, since the procedure affects the Data Node build sequence.",
Small test and lab installs are useful for learning the Graylog and Data Node setup, validating inputs or rehearsing an upgrade. They should not carry production data or connect to production networks. Certificates in a lab can come from the generated certificate authority with a short, documented lifetime, but the lab must stay isolated so that its trust material is never reused.
- Certificate source: Use the generated certificate authority or a throwaway internal CA, and never copy production CA keys or production certificates into the lab.
- Renewal owner: Assign renewal to the engineer who built the lab, and record the expiry date in the lab runbook so the environment is rebuilt rather than silently broken.
- Network boundary: Keep the lab on its own segment with no routes to production MongoDB, Data Node or log sources.
- Verification: Run the same preflight and cluster health checks you will use in production, so the procedure is rehearsed even though the trust chain is simpler.
- Promotion rule: Treat any lab configuration you plan to reuse as a new build, with new certificates issued in the production trust path.
Before reusing lab scripts in production, confirm with your team that every certificate, key and hostname was replaced, because copied lab material is a common source of avoidable trust problems.
Securing certificates, keys and Data Node traffic
The certificate authority, the Data Node certificates and the network paths between Graylog servers and Data Nodes form one trust chain. A weak link in any of them lets an attacker or a careless change reach the log store, so these controls should be designed together before the first Data Node starts.
Protecting CA private keys
Whoever holds the private key of the certificate authority can issue certificates that every Data Node and Graylog server will trust. Keep the CA key off the Data Node hosts, store it in an access-controlled secrets store or offline media, and limit signing to a named small group. Ask your team where the Graylog CA key lives today and who can reach it. If you bring your own CA, apply the same rules to that CA.
Controlling who may issue certificates
Certificate issuance should be a deliberate action with an owner, not a shell command run during an outage. Define which roles may sign node and client certificates, require a second person for signing where your process allows it, and keep the list of issued certificates with serial numbers and subject names. Check that a Data Node certificate cannot be issued for a host name that does not belong to your cluster.
Restricting Data Node ports to Graylog servers
Data Nodes accept traffic on the OpenSearch HTTP and transport ports. Allow those ports only from the Graylog server addresses and from other Data Nodes, and block them from user networks and general application subnets. Test the rule from a host that is not a Graylog server and confirm the connection is refused. Your firewall, security groups or network policies should express this rule, and the rule should be reviewed whenever nodes are added or replaced.
Handling the certificate chain on each node
Each node needs its own certificate, the matching private key and the intermediate and root certificates needed to validate the chain. A missing intermediate is a common cause of failed joins that looks like a network fault. Confirm each node presents the full chain with a tool such as openssl s_client, and keep file permissions on private keys restricted to the service account. Record which file paths each node uses so renewals update the right files.
Auditing certificate changes
Log every certificate issue, renewal, revocation and replacement with the requester, the approver, the affected node and the time of change. Keep the records in a location Graylog Data Node does not write to, so an attacker who compromises the cluster cannot erase the trail. Review the record during certificate renewals and after any node rebuild. OpenSearch Security also provides audit logging for its own events, which you can enable alongside your change records.
Protecting the backends
OpenSearch Security provides TLS for node and client traffic, role-based access control and audit logs, and that TLS design is the control that protects the Data Node cluster. Graylog Security adds detection features on top of the platform, but it does not replace certificate management, port restrictions or key protection. Confirm which security plugin settings your Graylog edition uses, and test that unencrypted connections to the Data Node cluster are rejected before you go live.
Renewing Data Node certificates without taking the cluster down
Certificate renewal on a Data Node cluster is an operational process, and the safe way to run it is one node at a time with the cluster kept healthy between steps. Start with an inventory: list every Data Node certificate, the Graylog server certificates and any certificate used for the web interface or inputs, along with the issuing CA, the subject names and alternative names, and the exact expiry date of each. Record which files on each host hold the certificate, its private key and the CA chain, and who owns each entry. Most renewal incidents come from a certificate nobody remembered, not from the renewal itself, so this inventory should be reviewed on a fixed schedule and tied to alerting that warns well before expiry.
Rotate one Data Node at a time. Before touching a node, confirm the cluster reports a healthy status and that shard allocation is complete, then replace that node's certificate and key, restart it, and wait until it rejoins and the cluster returns to the same healthy state before moving to the next node. Keep the replicas of the indices spread so that losing one node at a time does not reduce availability. Graylog servers hold the trust store they use to reach the Data Nodes, so the new CA chain must be in place on every Graylog server before any node certificate signed by a new CA is presented. Confirm the exact renewal commands, the certificate lifetimes and any restart or trust order in the Graylog documentation for your version, because these details change between releases.
Rehearse the whole procedure in a non-production cluster that uses the same Graylog version, Data Node version, certificate chain layout and file paths as production. The rehearsal should produce a written runbook with the expected health checks, the rollback steps if a node fails to rejoin, and the time each step took on your hardware. Decide in advance who approves each node change and what triggers a stop. Where your organization uses its own certificate authority, agree on the issuance lead time with the team that runs it, since a renewal that waits on a ticket queue is the most common cause of a missed expiry date.
Limits to confirm before you commit to this design
The Data Node design depends on a few limits that change between Graylog releases and editions. Confirm each one against the vendor documentation for the exact version you plan to run, before you size hardware or sign a scope.
OpenSearch version range
Graylog publishes a compatibility matrix that lists which OpenSearch versions each Graylog release supports. Use of OpenSearch 1.x is deprecated since Graylog 7.0 and is slated for removal in Graylog 8.0, so a backend that is already on 1.x needs a migration plan, not just a configuration change. Confirm the supported range for your Graylog minor version and write the target version into the design record. Check the matrix again before each upgrade, because the range moves with each release.
OpenSearch 2.0 for Security
Graylog Security needs OpenSearch 2.0 or later, which is a stricter floor than the general support range. If your organization plans to use Security features, confirm that the backend version you select meets this requirement before you choose a Data Node or self-managed OpenSearch path. Also confirm which Graylog edition license covers the features you need, since the requirement applies only once that edition is in use.
Storage sizing and journal
The architecture guidance sizes log storage as daily ingest multiplied by retention days, multiplied by 120 percent, and suggests giving the message journal 3 to 5 times daily ingest on SSDs. Ask your team to measure real daily ingest per source before using these multipliers, because estimates from guesses drive both disk and journal errors. Confirm the figures in the architecture page for your version, and size the Data Node disks and the Graylog journal volumes separately.
License-gated features
Some Data Node capabilities and the features you plan to rely on depend on Graylog Enterprise or Graylog Security. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license, so the terms for your use should be reviewed by your legal team. Confirm in writing which features the certificate and cluster design depends on, and which edition license you will hold, before the architecture is approved.
Internal PKI certificate fields
If you bring your own certificate authority rather than the Graylog CA, confirm that your internal PKI can issue certificates with the subject names, alternative names and extended key usages each Data Node and Graylog server needs. Also confirm that your CA chain can be distributed to every node and that your team can renew certificates before expiry. Ask the platform owner to test issuance against a non-production Data Node cluster first.
Questions teams ask before setting up Data Node certificates
How much does a Data Node install and certificate design cost?
No price is published for this work, and DeployOpen does not publish a price list. The cost follows from a written scope, and the main components are the planning of hosts and network layout, the preflight checks, the certificate design, the installation on each Data Node, and the handover of runbooks. Part of the cost is one-time (the build and first certificate issue), and part recurs (certificate renewal, Data Node patching and version upgrades). Costs rise with the number of Data Nodes, the complexity of your PKI integration, and how many environments need the same pattern, such as test and production. Ask for the quote to list each component separately, along with what is one-time and what recurs, and which tasks stay with your team.
Can our own team set up Data Node and its certificates alone?
Yes, many teams do, provided they have Linux administration skills, access to a certificate authority, and time for testing. The Graylog installation docs and the Data Node guidance cover the steps, but the work touches TLS trust, host sizing and the network, where mistakes are hard to spot until a cluster fails to form. Teams that go alone usually benefit from a second reviewer for the certificate chain and the separation of Data Nodes from Graylog servers. Ask a partner, if you use one, to name which steps they will do with you and which they will hand over.
How long does Data Node setup take?
Duration depends on scope and environment, including the number of Data Nodes, whether hosts are already provisioned, how quickly PKI requests are approved, and whether a test environment comes first. Teams with ready hosts and a clear certificate policy move faster than teams still waiting on network rules or change approvals. Ask for a timeline in the written scope that lists the dependencies you control, such as host access, certificate approvals and the maintenance window.
What does the work need from our team?
Expect to provide several things before work starts:
- Hosts for the Data Nodes, kept separate from the Graylog servers, with the resources the Graylog system architecture guidance describes for your ingest and retention plan
- Access to your PKI or a decision to use the Graylog CA, with someone who can approve certificate requests
- Network rules allowing traffic between Graylog servers, Data Nodes and MongoDB, plus the ports your inputs use
- A maintenance window for the first restart and any cluster changes
Confirm these with your security and network teams early, because approval queues often set the pace.
Should we use the Graylog CA or our own PKI for Data Node?
Use your own PKI when your organization already requires internal certificate issuance, revocation and audit records for services, since it keeps Data Node inside the same trust model as your other systems. The Graylog CA can suit a small, isolated deployment where your team has no PKI process to plug into, but you still need a plan for who holds the CA keys and how renewals happen. Whichever you choose, record the decision, the chain you trust, and the renewal owner. A security reviewer should check that the choice matches your certificate policy.
What happens when a Data Node certificate expires?
When a certificate expires, the TLS connections that depend on it fail, so Graylog servers may lose contact with Data Nodes and searches or ingest can stop until the certificate is replaced and the services reload it. Prevent this by tracking expiry dates, setting alerts well before they fall due, and documenting the renewal steps and the restart order. Test a renewal in a non-production environment before the first real expiry. Ask your partner or internal team to confirm the exact renewal procedure for the Graylog version you run, using the Graylog documentation.
Does Data Node setup affect our compliance evidence?
It can. Certificate issuance records, the list of trusted authorities and the renewal log become evidence that transport encryption is in place and maintained. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask your assessor which records they expect, and plan to keep them from the first day of the build.
How DeployOpen scopes and delivers Data Node setup
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For Graylog Data Node, we start from your storage, certificate and network requirements, then deliver a Data Node cluster that runs apart from your Graylog servers and that your team can operate after handover.
How we scope
- Written scope names the Data Node count, hosts, storage paths and the Graylog version you run.
- Scope records whether the Graylog CA or your own enterprise certificates will secure node and client traffic.
- Scope lists which certificate renewal and rotation tasks DeployOpen performs and which stay with your team.
How we build
- We run the preflight checks for OS, memory, disk and network reachability before any Data Node is installed.
- We install Data Node on its own cluster and issue certificates from the chosen CA, with the trust chain tested on each host.
- We verify that Graylog servers connect to the Data Node cluster and that nodes rejoin cleanly after a restart.
How we hand over
- Deliverables include the configuration record, certificate inventory with expiry dates and a renewal runbook.
- Documentation explains how to add a Data Node, replace a certificate and separate roles between Data Nodes and Graylog servers.
- We walk your engineers through a test renewal so the procedure is proven in your environment before handover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, certificate renewal assistance and upgrades are available as a retainer.
- Confirm with DeployOpen during scoping which support hours, response paths and renewal windows your retainer includes.
