Graylog TLS setup for web, API and inputs

Why Graylog TLS needs a plan before the first log arrives

Encrypting Graylog is not one switch. TLS for the web interface, the API, the inputs and the Data Node links are separate connections, each with its own certificate, trust chain and client configuration, and each one can be left in plain text while the others look secure. A team that turns on HTTPS for the browser and assumes the rest is covered will still send logs over unencrypted channels. Before the first log arrives, the team should list every connection that carries log content, credentials or session data, and decide how each one is authenticated and encrypted. The hardest part is that Graylog Open ingests logs over inputs such as syslog, GELF and Beats, so both ends of each connection need agreed TLS settings. The sending side, whether that is a host agent, a network device or an application library, must support the protocol version, cipher choices and certificate validation that the Graylog input expects. Many of these senders ship with weaker defaults, or with verification turned off, so the team should test each source against the input before the source goes into production. Confirm the exact input options and supported sender features in the Graylog documentation for your version and in each sender's own documentation rather than assuming they match. Keys and certificates also need an owner. Someone must decide who issues the certificates, how their private keys are stored, which file permissions the Graylog service account needs to read them, and how renewal will happen without an outage on the inputs. Those decisions shape the build plan, so they should be settled in writing before the first sender is pointed at Graylog. Ask your Graylog and certificate authority contacts to confirm how renewal and reloading work for each component.

Which Graylog connections need TLS and what each one decides

This table compares each Graylog connection that can carry TLS, showing who starts it, what the certificate must match and who has to configure it. Read each row before you issue certificates, because the hostname or sender setting that matters differs for every connection. Where a sender is an agent or appliance outside Graylog, confirm its TLS support before you plan the listener.

Connection	Who initiates it	What the certificate must match	Configuration owner and what to confirm
Web interface	Analysts and administrators in a browser	The name users type into the address bar, and any load balancer name in front of it	Graylog server nodes and the load balancer. Confirm the HTTPS settings and certificate chain guidance for your installed version in the official docs.
REST API	Scripts, integrations and the Graylog web interface calling the API	The API hostname that clients use, which may differ from the web interface name if you split them	Graylog server nodes plus every API client. Confirm which API URL the server advertises to clients and how clients should trust the certificate.
Beats input	Beats shippers such as Filebeat running on hosts	The hostname or address the shipper connects to, as set in the shipper's TLS configuration	Graylog input and the Beats shipper. Beats TLS depends on the shipper's own configuration. Confirm the input's TLS options and the matching shipper settings for your version.
Syslog input	Network devices, servers and syslog forwarders	The hostname or address the sender trusts, plus any client certificate the listener requires	Graylog input and the sender. Many devices and forwarders have limited or no TLS support. Confirm the sender's TLS capability before you plan this listener.
GELF input	Applications and logging libraries sending GELF	The hostname the application uses, and the CA the library trusts	Graylog input and application or library configuration. Confirm the input's TLS setting and the library's support for certificate verification in your environment.
Data Node or OpenSearch storage	Graylog server nodes connecting to the search backend	The Data Node or OpenSearch node names and the CA that signed them	Graylog server nodes and the storage cluster. Confirm the Data Node certificate workflow in the official documentation for your version, including whether it is managed or manual.

How to enable TLS across Graylog in the right order

This sequence encrypts each Graylog connection in an order that keeps the system reachable at every step, so that each change is verified before the next one depends on it. The result is a Graylog deployment where the web interface, API, inputs and storage backend all negotiate TLS, with evidence that senders and clients connect cleanly.

Inventory every connection and sender
List each path into and out of Graylog: browser and API clients, Beats shippers, syslog and GELF senders, and the connection from Graylog server nodes to the Data Node or OpenSearch cluster. Record the host name, port, protocol and owner of each one, and note which senders cannot be updated quickly. Done means every connection has a row in a shared inventory that the team has reviewed, so nothing is switched on blind.
Issue certificates with the correct names
Obtain server certificates from your internal CA or public CA, with subject alternative names that match the exact host names clients use to reach each Graylog node, load balancer and input. Confirm the chain includes intermediates the senders trust. Check each certificate with an inspection tool to confirm the names, validity dates and key type match the inventory before anything is deployed.
Place certificate and key files with restricted ownership
On each Graylog node, copy the certificate chain and private key to the paths named in the official installation documentation, owned by the service account that runs Graylog and readable by no other local user. Keep the private key out of shared configuration repositories. Verify with a file listing that the key is not world-readable and that the service account can open it, then confirm the service starts without errors.
Enable HTTPS on the web interface and API
Turn on HTTPS for the web interface and API using the settings described in the Graylog installation documentation, and update the external URL so it matches the certificate name. Restart the node, then load the web interface in a browser and call an API endpoint with a command-line client, validating the certificate against your CA. Done means both return successful responses without certificate warnings or forced trust overrides.
Enable TLS on each input and update senders
Enable TLS on one input at a time for Beats, syslog and GELF, following the input settings in the Graylog documentation. Then update the matching sender configuration to trust the CA and use TLS, starting with one non-critical source. Confirm the input shows as running, that messages from the sender are arriving in the expected stream, and that the old plaintext port is closed or disabled before moving to the next input.
Configure TLS to the Data Node or OpenSearch
Configure the Graylog server connection to the Data Node or OpenSearch cluster with TLS and certificate verification, as described in the installation documentation for your version. Confirm the cluster version and compatibility against the compatibility matrix before you change anything. Verify by checking that Graylog reports the search backend as healthy, that indices still rotate, and that a search returns recent messages.
Test with a staging sender and review logs
Repeat the full sequence in a staging environment with the same certificate chain and at least one sender of each type. Send test messages from each sender, then review the Graylog server logs and the sender logs for handshake errors, certificate name mismatches and expired certificate warnings. Promote to production only when a test run produces no handshake errors and the team has written down the certificate expiry date for renewal.

How certificate handling changes for single-node and multi-node clusters

A single Graylog node in a lab or small team is the simplest case. TLS terminates at the Graylog server itself, so the web interface, the REST API and the HTTP-based inputs depend on one certificate and one private key that the server reads when it starts. Clients connect directly to the name in the certificate, which means the subject alternative names must match the addresses that browsers, API clients and collectors actually use. Rotation is one file replacement and a restart, but it still needs a planned window because searches, inputs and API sessions drop while the service restarts.

Termination point: Graylog serves HTTPS itself. Enable it and point the server at the certificate and key with keys such as http_enable_tls, http_tls_cert_file and http_tls_key_file in server.conf. Confirm the exact key names against the configuration reference for your Graylog version.
Certificate scope: One certificate must cover the host name in http_external_uri. List every other name that clients use, because a missing name produces failures that look like collector problems rather than certificate problems.
Rotation: Replace the certificate and key files, check their permissions, then restart the node. There is no second node to take the traffic, so schedule the change.
Verification: Connect to the web port with an OpenSSL client, confirm the served chain, and record the expiry date.

Before each rotation, check the expiry date, the list of names and that only the Graylog service account can read the private key.

The Graylog multi-node guide describes a medium to large layout with three Graylog and MongoDB nodes, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes. In this shape TLS can terminate at the load balancer, at each Graylog node, or at both. Terminating only at the balancer means fewer certificates to manage, but traffic between the balancer and the nodes is then unencrypted unless you re-encrypt it. Each Graylog node in the cluster also needs its own role configuration, and follower nodes set is_leader to false, so TLS settings must match across every node.

Termination choice: Terminate at the balancer and re-encrypt to each node if your policy requires encryption between the balancer and Graylog. Terminate at each node only if clients reach nodes directly.
Per-node identity: A re-encrypting balancer checks the name of each backend, so each node needs a certificate for its own name. A shared certificate with several names can be deployed to all nodes, but then the private key is copied to every node, so confirm that your key management policy allows it.
Rotation sequence: Rotate one node at a time, confirm it is healthy and back in the balancer pool, then continue. Keeping the cluster available depends on the balancer removing a node that fails its health check, so verify that behavior before the first change.
Configuration consistency: Keep the TLS settings identical on the leader and on every follower. Drift between nodes causes intermittent failures that are hard to trace back to certificates.
Data Node certificates: Rotation of Data Node certificates is a separate task with its own restart order, so plan it as its own change.

After each node, repeat the chain check, the expiry check, a login through the balancer and a test input connection.

Protecting certificate files and private keys on Graylog hosts

A TLS setup is only as strong as the files behind it. The cards below cover the places where private keys and certificates usually leak or quietly stop working on a Graylog host, from file permissions and backups to expiry and trust chains. Each one names the control and a check you can run on the host.

Private key file ownership

The private key used by the Graylog web interface, API and inputs should be readable only by the account that runs the Graylog service and by root. Look for a key file that is group-readable or world-readable, especially after a package upgrade or a configuration management run has reset modes. Confirm owner, group and mode with ls -l on every key path referenced in your configuration, and repeat the check after each upgrade.

Keys leaking into support bundles

Certificate directories are easy to pull into a support bundle or a configuration backup, and a bundle is often shared with a vendor or stored in a ticketing system. Decide which paths are excluded before collecting a bundle, and treat any bundle that contains a .key file as a secret. Check the contents of a test bundle and of your backup set for private key material before sharing them.

Keys kept in version control

Teams that manage Graylog configuration as code often commit the certificate chain and, by accident, the private key alongside it. A key in a Git history stays exposed even after it is deleted from the current branch. Keep only public certificates and chains in the repository, inject private keys from a secrets store at deploy time, and scan commits for PEM headers before they are pushed.

Expiry that stops inputs silently

When a certificate on a Beats, Syslog or GELF TLS input expires, senders fail their handshake and the input may show no obvious error in Graylog, so logs stop arriving without an alert. Record the expiry date of every certificate in use, set a reminder well before it, and confirm that a monitor watches for messages dropping to zero from each source. Include the Graylog web interface certificate in the same inventory.

Internal CA trust chains

Many Graylog deployments use certificates issued by an internal certificate authority. If the chain is incomplete, or the root is not installed on the sending hosts, network devices and agents will refuse the connection. Confirm that the server presents the full chain, that the root is trusted by every sender class, and that intermediates are renewed before they expire. Test each input from a client that is configured the way production senders are.

Default protocol and cipher settings

Leaving TLS protocol versions and cipher suites at whatever the operating system or the Graylog build provides can fail a security review, particularly on older senders that negotiate weak options. Write down the protocol versions and cipher list you accept for each listener, and compare them with the policy your security team has adopted. Verify the result from outside the host with a TLS scanner so the evidence reflects what a client actually negotiates. Confirm the supported settings in the Graylog security documentation before you change them.

What breaks when TLS is added to a running Graylog cluster

Enabling TLS on a live Graylog cluster is a change to every client that talks to it, so the main risk is that senders and consumers stop working before anyone has reconfigured them. The most common failure is an input switched to TLS while the devices, agents or applications pointing at it still send plain traffic. Those senders typically fail silently from the operator's point of view, so logs stop arriving with no alert. The same applies to load balancers: a health check that still probes the old protocol or port will mark healthy nodes as down once the listener changes, and the balancer may then route all traffic to a single node or none. Confirm, for each input, which senders use it, which protocol and port each one uses today, and who owns the change on the sender side.

Users and automation are the second group at risk. Browser bookmarks, reverse proxy rules, monitoring probes and API scripts that call the web interface or REST API over plain HTTP will break or redirect unexpectedly once HTTPS is enforced. Certificate expiry is the third risk and the least visible: a certificate that expires on a date nobody tracks can take down the web interface, the API and any TLS input at once. Record every certificate's issuer, subject alternative names and expiry date, and set alerts well before expiry. Your certificate authority's renewal process, including any manual steps, should be written down before the change window.

Plan the change as a staged rollout with a rollback path. Choose a change window that gives the sender owners time to confirm, and agree in advance who can make the call to revert. Keep the previous configuration and certificate files so that reverting is a known, tested step rather than a rebuild. Before touching production, build a test sender in a staging environment that mirrors your inputs, load balancer and certificate chain, then send test messages over each TLS input and load the web interface and API from a client that trusts the certificate. The Graylog installation documentation describes the server configuration you will be changing, and the staging result should match it before production is touched.

What to confirm for your Graylog version, license and senders

TLS options in Graylog depend on the release you install, the license edition behind each input and the senders you connect. Confirm these items before you write configuration, because a gap found during rollout usually means a rebuild of the listener, the certificate chain or the backend.

TLS options in your release

Graylog's documentation covers version 7.2, but your installed release decides which TLS settings exist and how they are named. Confirm the HTTPS and certificate options in the release notes and configuration reference for the exact version you run. Note that OpenSearch 1.x use is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so a plan built on it has a dated exit point. Check the option names against your version before you copy any example.

Input and sender TLS support

Graylog's input types and the devices that send to them do not always agree on TLS. Syslog senders, Beats shippers and GELF clients each have their own transport options, and many network devices support only UDP or plain TCP. Confirm with each sender's vendor which protocol, port and certificate validation method it supports, and test one sender end to end before you commit the design.

Edition required for each input

Graylog Open supports several inputs, but some inputs and integrations depend on an Enterprise or Security license. If your TLS design relies on a specific input, confirm in the Graylog product and pricing pages that the input is included in the edition you plan to run. Make this check before procurement, since a license gap can force a different input choice after the listeners are already built.

OpenSearch or Data Node compatibility

The TLS design for Data Node or OpenSearch must match the Graylog release and its supported backend versions. Check the compatibility matrix for the Graylog version you run, since Graylog 7.0 to 7.2 list supported OpenSearch ranges and Graylog Security requires OpenSearch 2.0 or later. Confirm that the certificate handling you plan for the backend is supported by that exact version before you deploy.

Certificate authority and renewal ownership

Decide which certificate authority issues the server and listener certificates, who holds the private keys and who renews them before expiry. Internal CAs, public CAs and automated issuance each change how clients trust Graylog. Record a named owner, a renewal date process and a test for chain validation, because an expired certificate on an input can silently stop log ingestion from senders that do not retry.

Protocol versions set by your auditor

Confirm with your internal security team or external auditor which TLS protocol versions and cipher policies they expect for log transport. Some assessors ask for a minimum version and a documented exception process, while others accept a baseline set by your own policy. Ask for that requirement in writing before you configure listeners, so the evidence you collect matches what the assessor will review.

Questions teams ask before they encrypt Graylog

What does a Graylog TLS project cost?

The fee follows from the written scope, and DeployOpen does not publish a price list. The main drivers are the number of connections and senders that need TLS, the number of Graylog server nodes and Data Nodes, where certificates come from, how many change windows the work needs, and how much sender reconfiguration and testing is included. A one-time project fee covers design, configuration and verification. Certificate issuance and renewal costs recur and depend on your certificate authority. Ask for the quote to list each sender group, each node, the certificate source, and who performs the sender changes, so you can compare it with your own team's effort.

How long does it take to encrypt Graylog inputs?

Duration depends mostly on how many senders must change and how hard each one is to reconfigure. The number of Beats, Syslog and GELF sources is the largest factor, followed by legacy devices that cannot present or validate modern TLS, and by approval steps for certificates and change windows. A single node with a few supported senders moves quickly. A multi-node cluster with many device owners takes longer because each sender group needs its own test and cutover. Your written scope should set the timeline once you have agreed the sender inventory.

What must our team provide before TLS work starts?

Four things make the work predictable. First, a complete inventory of senders, including host, device, application, input type and current port. Second, access to the internal certificate authority or the process your organization uses to issue server certificates. Third, scheduled maintenance windows for the web interface, the API and each input. Fourth, named owners for Graylog, for each sender group and for certificate renewal, who can approve changes and confirm test results. Missing owners are the most common cause of delay, because senders cannot be switched to TLS without someone who controls them.

Can our internal team encrypt Graylog without a partner?

Yes, for a small setup. A single Graylog node with a short list of senders that already support TLS is a reasonable task for an experienced administrator who has access to the certificate authority and a test environment. The work gets harder when legacy devices cannot negotiate modern TLS, when several Graylog nodes must share certificates and trust settings, or when Data Node connections to OpenSearch need to be encrypted without disrupting ingest. In those cases, the cost of testing and rollback usually shifts the decision. Confirm the protocol and certificate support of each sender before you decide.

Does Graylog Open support TLS on every input?

Confirm this per input and per license before you plan the project. Graylog Open ingests logs over inputs such as syslog, GELF and Beats, and the TLS options for each one depend on the input type and the Graylog version you run. Some inputs and features are tied to Enterprise or Security licenses, and the Graylog licensing terms under SSPL-1.0 also apply to how you deploy. Check the current Graylog documentation for the version in use and the input list in your own environment, then record each TLS path as supported, unsupported or needing a different input.

How are Graylog certificates renewed after the project?

Renewal is an ongoing task that should be assigned before go-live. Each certificate for the web interface, the API, the inputs and the Data Node connection has an expiry date, and an expired certificate stops ingest or breaks user access. Define who receives expiry alerts, how replacement certificates are issued, where private keys are stored with restricted file permissions, and how each sender is updated or pinned to a new trust chain. Ask any partner to include renewal steps and a test procedure in the handover documentation, and confirm whether ongoing support is handled under a retainer or by your team.

Which parts of the TLS work carry the most risk?

The highest risk is a cutover that stops log ingest without a rollback. Senders that cannot be changed quickly, such as legacy network devices, should be scheduled last and run with a tested fallback where your policy allows it. Misconfigured certificate chains, wrong file permissions on private keys and forgotten ports are common faults that appear only after a sender reconnects. Plan a test on each input before you switch the sender, and keep the previous configuration available until the new path has run through a full reporting cycle.

How DeployOpen scopes and delivers Graylog TLS work

DeployOpen plans and implements Graylog TLS inside your own infrastructure, covering the web interface and API, the Beats, Syslog and GELF inputs, certificate file permissions and Data Node TLS to OpenSearch. Each engagement starts from a written scope that lists every connection type, certificate source and host that will change.

How we scope

Inventory every listener, input and client connection that must move to encrypted transport before any change is made
Confirm which certificate authority issues server certificates and whether clients trust it or need the chain added
Record the Graylog nodes, load balancer, Data Node cluster and input sources that the written scope covers
Agree in writing which clients will be tested, which will be migrated and which remain on plaintext for a stated period

How we build

Configure HTTPS for the web interface and API on each Graylog server node behind the load balancer
Enable TLS on Beats, Syslog and GELF inputs and check each sender against the new listener before cutover
Set certificate and key file ownership and permissions so only the Graylog service account can read private keys
Configure Data Node TLS to OpenSearch and verify that every node in the cluster presents and validates the expected certificate

How we hand over

Deliver a written record of endpoints, ports, certificate sources, trust chains and renewal owners for your team to review
Provide test evidence for each connection, including handshake results, rejected plaintext attempts and input ingestion checks
Document the renewal, rotation and rollback steps your operators will follow when a certificate expires or is replaced
Walk your engineers through the configuration files and confirm they can repeat the checks without DeployOpen

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer if your team wants help after handover
Ask for the handover package, test evidence format and renewal responsibilities to be named in any quote
Confirm with your Graylog edition and version which TLS options your environment supports before finalizing the scope

TLS for the Graylog web interface, API and inputs