Catch up on the latest product updates, best practices, and expert insights from the Checkmk Conference #12 – Watch the livestream recordings now

Werk #20075: Agent controller: Renew agent certificates rejected by Checkmk 3.0

Component Checks & agents
Title Agent controller: Renew agent certificates rejected by Checkmk 3.0
Date Aug 12, 2026
Level Trivial Change
Class Bug Fix
Compatibility Compatible - no manual interaction needed
Checkmk versions & editions
3.0.0b1
Not yet released
Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT
2.5.0p12
Not yet released
Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT

This Werk fixes a bug that will be active only after the future Checkmk 3.0 release. However, to prevent it, a fix is already needed during the Checkmk 2.5 lifecycle.

When updating a Checkmk site to Checkmk 3.0, monitoring on TLS-registered hosts may break, with the Check_MK service going CRIT with the message [agent] Error establishing TLS connection, delivering no data any more.

A host is affected when the certificate it holds is issued by a Checkmk site older than Checkmk 2.4.0p20.

The agent controller now detects such a certificate and requests a replacement from the agent receiver of the registered site. The certificate check is part of the renewal cycle that the controller daemon runs once per day, and that cycle also runs within a minute of every daemon start. An agent update restarts the daemon, so a host replaces its certificate shortly after it has received an agent package that contains this fix.

What you need to do

Update your agents before you update your site to Checkmk 3.0.0. Hosts that receive their agent through the automatic agent update need no manual action.

On a host that is not updated automatically, install a current agent package, or renew the certificate by hand:

cmk-agent-ctl renew-certificate <servername>/<site>

Connections that were set up with cmk-agent-ctl proxy-register and cmk-agent-ctl import are the one case the controller cannot repair on its own, because it has no site to talk to for such a connection. Repeat the proxy registration and the import for these hosts from a site that runs Checkmk 2.5.0 or newer.

Technical background

Python 3.13 enables the OpenSSL flag X509_V_FLAG_X509_STRICT for the default SSL context. Under that flag OpenSSL requires the authority key identifier on every certificate that is not self-issued, and reports certificate verify failed: Missing Authority Key Identifier otherwise. When a Checkmk 2.5.0 site contacts the agent on a monitored host, it switches the flag off before it establishes the TLS connection. Checkmk 3.0.0 keeps the flag enabled.

The agent receiver adds the extension to every certificate it signs since Checkmk 2.5.0 and 2.4.0p20, so a renewed certificate passes the strict validation. The receiver itself does not validate strictly. The agent controller can therefore still reach the renewal endpoint while it holds the old certificate.

Note: The missing X509 extension never resulted in a security risk. The mentioned OpenSSL flag is off by default in common OpenSSL installations. The Python project decided to switch it on deliberately starting with Python 3.13. We follow this decision in two steps, by applying the required X509 extension(s) in Checkmk 2.5.0, and requiring them in Checkmk 3.0.

To the list of all Werks