After Securing Graylog with TLS no access to logdata anymore

1. Describe your incident:

After enabling TLS as described at How-To Guide: Securing Graylog with TLS I’m able to log in and navigate through the UI. But I don’t have access to the log data. The message “Updating log data” appears.

2. Describe your environment:

  • OS Information:
    Ubuntu 22.04.5 LTS

  • Package Version:
    Graylog 6.1.3-1
    Graylog-datanode 6.1.3
    MongoDB 7.0.15

  • Service logs, configurations, and environment variables:

tail /var/log/graylog-server/server.log

2024-11-26T07:57:59.270Z INFO  InputStateListener Input [GELF UDP/GELF UDP | Windows Events | Domain Computers/673ef639412a2b2c68e0c2bd] is now RUNNING
2024-11-26T07:58:01.766Z WARN  ProxiedResource Failed to call API on node <9e429e13-6e85-4d39-a6cc-a6be9fd5a696>, cause: Failed to connect to ift-sl040/127.0.1.1:80 (duration: 16 ms)
2024-11-26T07:58:03.739Z WARN  ProxiedResource Failed to call API on node <9e429e13-6e85-4d39-a6cc-a6be9fd5a696>, cause: Failed to connect to ift-sl040/127.0.1.1:80 (duration: 4 ms)
2024-11-26T07:58:05.739Z WARN  ProxiedResource Failed to call API on node <9e429e13-6e85-4d39-a6cc-a6be9fd5a696>, cause: Failed to connect to ift-sl040/127.0.1.1:80 (duration: 4 ms)
2024-11-26T07:58:07.743Z WARN  ProxiedResource Failed to call API on node <9e429e13-6e85-4d39-a6cc-a6be9fd5a696>, cause: Failed to connect to ift-sl040/127.0.1.1:80 (duration: 3 ms)
2024-11-26T07:58:09.734Z WARN  ProxiedResource Failed to call API on node <9e429e13-6e85-4d39-a6cc-a6be9fd5a696>, cause: Failed to connect to ift-sl040/127.0.1.1:80 (duration: 1 ms)
2024-11-26T07:58:11.737Z WARN  ProxiedResource Failed to call API on node <9e429e13-6e85-4d39-a6cc-a6be9fd5a696>, cause: Failed to connect to ift-sl040/127.0.1.1:80 (duration: 2 ms)
2024-11-26T07:58:13.727Z WARN  ProxiedResource Failed to call API on node <9e429e13-6e85-4d39-a6cc-a6be9fd5a696>, cause: Failed to connect to ift-sl040/127.0.1.1:80 (duration: 1 ms)

server.conf

is_leader = true
node_id_file = /etc/graylog/server/node-id
password_secret =HS08cEQzvukdFQL-uNfdztxSe8AT-Ki1CGrfSS3DPdhw9E1ABDChfjyHt6eTRyyqwK0-Ox22XDFIeKUdf9iHcj1ZPuXbA4be6
root_password_sha2 =c13c9e222657bc5907fbd687dfb39fe6dfb757b86b44d67cdfc8ff7814238de9
bin_dir = /usr/share/graylog-server/bin
data_dir = /var/lib/graylog-server
plugin_dir = /usr/share/graylog-server/plugin
http_bind_address = 10.77.33.86:443
http_publish_uri = http://host123/
http_enable_tls = true
http_tls_cert_file = /opt/graylog/tls/public.pem
http_tls_key_file = /opt/graylog/tls/private.key
http_tls_key_password = myPassW0rd
stream_aware_field_types=false
disabled_retention_strategies = none,close
allow_leading_wildcard_searches = false
allow_highlighting = false
field_value_suggestion_mode = on
output_batch_size = 500
output_flush_interval = 1
output_fault_count_threshold = 5
output_fault_penalty_seconds = 30
processor_wait_strategy = blocking
ring_size = 65536
inputbuffer_ring_size = 65536
inputbuffer_wait_strategy = blocking
message_journal_enabled = true
message_journal_dir = /var/lib/graylog-server/journal
lb_recognition_period_seconds = 3
mongodb_uri = mongodb://localhost/graylog
mongodb_max_connections = 1000
transport_email_enabled = true
transport_email_hostname = company-de0i.mail.protection.outlook.com
transport_email_port = 25
transport_email_use_auth = false
transport_email_from_email = it@domain.de
transport_email_socket_connection_timeout = 10s
transport_email_socket_timeout = 10s
transport_email_use_tls = true
transport_email_use_ssl = false
transport_email_web_interface_url = https : //graylog.example.com
integrations_scripts_dir = /usr/share/graylog-server/scripts

3. What steps have you already taken to try and solve the problem?

Everything I found with google.

4. How can the community help?

Maybe someone has an idea what else I could try.

Kind regards

Sven

Is your publish_uri in server.conf http:// , thats most likely your problem, publish uri is what it uses to call the api, even when its calling it itself. Second most common reason is that it doesnt trust its own cert to call the api, but i think the error for that one is different.

As a test, I changed the value of “http_publish_uri” to https://ift-sl040/, but this does not change the behavior.

Another installation with Graylog 6.0.x works perfectly with the same configuration (server.conf). But I installed this installation with opensearch v2.18.0 by mistake. This worked until Graylog v6.0.7, but an upgrade to Graylog v6.1 crashed the system. But that is another topic.

I have imported the required Import Root and Intermediate certificates into the Java Key Store (JKS). So this should not be the problem. Otherwise, HTTPS access to the UI would probably not work either.

I suspect that something fundamental has changed from v6.0.x to v6.1.x.

With the following server.conf the access to the log files works now:

is_leader = true
node_id_file = /etc/graylog/server/node-id
password_secret =HS08cEQzvukdFQL-uNfdztxSe8AT-Ki1CGrfSS3DPdhw9E1ABDChfjyHt6eTRyyqwK0-Ox22XDFIeKUdf9iHcj1ZPuXbA4be6
root_password_sha2 =c13c9e222657bc5907fbd687dfb39fe6dfb757b86b44d67cdfc8ff7814238de9
bin_dir = /usr/share/graylog-server/bin
data_dir = /var/lib/graylog-server
plugin_dir = /usr/share/graylog-server/plugin
http_bind_address = 10.77.33.86:443
http_publish_uri = https://host123.intra.company.com:443/
http_enable_tls = true
http_tls_cert_file = /opt/graylog/tls/public.pem
http_tls_key_file = /opt/graylog/tls/private.key
http_tls_key_password = myPassW0rd
stream_aware_field_types=false
disabled_retention_strategies = none,close
allow_leading_wildcard_searches = false
allow_highlighting = false
field_value_suggestion_mode = on
output_batch_size = 500
output_flush_interval = 1
output_fault_count_threshold = 5
output_fault_penalty_seconds = 30
processor_wait_strategy = blocking
ring_size = 65536
inputbuffer_ring_size = 65536
inputbuffer_wait_strategy = blocking
message_journal_enabled = true

It is important that the web interface is then accessed via https://host123.intra.company.com:443/. Otherwise, when the API browser is viewed, it is called up via the IP and a new password request is made.

Ya I see it now, your publish uri needs to match exactly how it would comunicate to the API so it needed the https and the port. Think of it as if you needed to send the link to someone, it needs to be everything because it’s not infering port etc from anywhere else just what is in that config line.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.