mTLS for monitoring: both sides show ID

A result receiver is a place where you want monitoring agents to deliver information. “Someone connected to the port” is a rather relaxed guest list.

Mutual TLS, or mTLS, adds a certificate check on both sides of the connection. In RMON, it can protect the path from agents to the result receiver. The useful part is straightforward: the agent checks whom it is talking to, and the receiver checks whether the caller has a client certificate it trusts.

Start by separating the connections

There are two easy-to-confuse journeys. First, an agent contacts the service you are monitoring. An HTTP check can use TLS and, where needed, client credentials for that target. Second, the agent sends its measurement to RMON’s result receiver.

Configuring mTLS for result delivery protects the second journey. It does not change how the monitored service authenticates the check. The agent management API is also separate: it remains HTTP and should be restricted to the monitoring network. Installation, reconfiguration and service actions use SSH.

Draw those connections before changing certificates. It is a much cheaper exercise than explaining why a perfectly valid certificate was installed on the wrong end of the wrong connection.

What both sides actually verify

With HTTPS, the agent verifies the receiver’s certificate, including trust and the name or IP address used to connect. With mTLS, the receiver also requires a client certificate issued by a CA it trusts. A receiver that merely accepts an optional client certificate does not enforce the same requirement.

This adds certificate-based admission to the connection. It does not automatically map a certificate’s subject to an RMON agent UUID, nor does it replace RMON’s application-level checks. Treat certificate issuance and access to private keys as part of the deployment’s access policy.

Prepare the receiver, then the agents

Start with the receiver’s certificate, private key and trusted client CA. Its certificate must cover the exact address agents will use. A certificate for results.example.com does not automatically validate a connection to an IP address.

For the agents, RMON supports two workflows: supply client certificates and matching private keys, or configure RMON to generate missing client pairs using an administrator-provided CA and signing key. That signing key stays with RMON; it is not copied to agents.

Certificate paths belong to the agent owner’s group. Use the directory shown under Admin area → Settings → Agent connections, with the required permissions. A file on your laptop is not a file the RMON service can read. Unfortunately, certificates have not yet learned telepathy.

Apply the setting and verify a real result

1. Prepare a receiver that requires the intended trusted client certificate.
2. Save the group’s CA and client-certificate settings.
3. Choose HTTPS + mTLS for one agent and run Reconfigure.
4. Wait for the task’s final status and inspect the card’s applied mode and verification time.
5. Create a disposable check on that agent and confirm fresh results before repeating the rollout elsewhere.

Saving a desired mode does not apply it to the running agent. The card’s applied state and a fresh measurement are useful evidence; the presence of a certificate file is only a promising beginning. In a controlled test, also verify that the receiver rejects a connection without a trusted client certificate.

Put certificate renewal on the calendar

mTLS creates an ongoing certificate-management responsibility. Keep track of expiry, trust changes and replacement credentials. RMON does not provide automatic renewal for these receiver and agent-delivery certificates. After replacing an agent certificate at the same path, explicitly reconfigure the agent and verify delivery again.

A failed certificate check should lead to a diagnosis: the wrong CA, an address mismatch, an expired certificate or an incomplete pair. Disabling verification turns a useful failure into a quieter uncertainty.

Follow the receiver guide and the agent mTLS walkthrough for deployment details. Mutual trust is useful. Mutual trust that you have actually tested is better.