Notifications
Clear all
Topic starter
10/07/2026 9:23 pm
TL;DR: A walkthrough shows how Zabbix Agent 2 can monitor MQTT over TLS on AlmaLinux 8, according to Cybertrust Japan, but also exposes a failure mode where a misconfigured certificate path leaves TLS plugin loading broken and monitoring unavailable. The practical lesson is that secure telemetry depends on certificate handling, file paths, and trust configuration staying aligned, not just on turning on encryption.
NHIMG editorial — based on content published by Cybertrust Japan: Zabbix Agent 2 MQTT TLS monitoring setup and troubleshooting
Questions worth separating out
Q: What breaks when MQTT TLS settings are missing the right certificate files?
A: The agent or broker can fail before any telemetry flows if the TLS loader cannot read the CA, certificate, or key it expects.
Q: Why do certificates in monitoring systems need identity-style governance?
A: Because certificates control who can speak on the channel, what trust anchor is accepted, and which service is allowed to present itself as legitimate.
Q: How do security teams know whether encrypted telemetry is actually trusted?
A: They should confirm that the channel uses the expected trust chain, that the service reads the intended CA and key material, and that the monitoring logs show successful TLS loading rather than fallback behavior.
Practitioner guidance
- Validate TLS file paths before enabling monitoring Check that the CA, certificate, and key paths in the Zabbix Agent 2 MQTT plugin point to real files and match the broker configuration exactly.
- Treat certificate files as managed secrets Store broker and agent certificates in a controlled directory, assign explicit ownership, and set permissions so only the required service accounts can read them.
- Decide whether server-only TLS is enough Use server-only verification only when the broker trust boundary is tightly controlled and client authentication is not required.
What's in the full article
Cybertrust Japan's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact shell commands for building a local CA, server certificate, and agent certificate on AlmaLinux 8
- The full Mosquitto and Zabbix Agent 2 configuration files, including TLS listener and plugin settings
- The strace-based troubleshooting sequence that pinpoints why the agent reports a missing key pair
- The concrete workaround used to avoid the TLS plugin loading error in the reported setup
👉 Read Cybertrust Japan's walkthrough of MQTT TLS monitoring with Zabbix Agent 2 →
MQTT TLS monitoring in Zabbix: what breaks when certificate files are miswired?
Explore further
10/07/2026 9:45 pm
Certificate-path integrity is a governance issue, not just a configuration issue. The article’s failure mode is caused by a mismatch between what the Zabbix Agent 2 TLS loader expects and what the operator supplied. That means monitoring reliability depends on the same discipline used for credential lifecycle management, because certificate files are secrets with a defined scope, path, and trust purpose. For practitioners, the control objective is to prevent silent breakage in authenticated telemetry flows.
A question worth separating out:
Q: Should teams use server-only TLS or mutual TLS for MQTT monitoring?
A: Server-only TLS can be enough for tightly controlled test or internal setups, but it leaves the client unauthenticated. Mutual TLS is the better choice when the broker must know exactly which agent or publisher is allowed to connect. The decision should follow trust requirements, not convenience.
👉 Read our full editorial: MQTT TLS monitoring exposes certificate handling pitfalls in Zabbix
