Werk #19543: Fixed relay certificate renewal that silently failed since 2.5.0p9
| Component | Relay | ||
| Title | Fixed relay certificate renewal that silently failed since 2.5.0p9 | ||
| Date | Sep 8, 2026 | ||
| Level | Prominent Change | ||
| Class | Bug Fix | ||
| Compatibility | Compatible - no manual interaction needed | ||
| Checkmk versions & editions |
|
Relays could not renew their client certificates, and eventually stopped communicating with the site altogether.
What went wrong
Every relay authenticates to its site with a client certificate that it renews shortly before expiry. Since Checkmk 2.5.0p9 the site rejected these renewal requests, so renewal failed quietly, day after day, until the certificate expired. From that moment the relay could not reach the site at all - every request failed during the TLS handshake, which the relay logged as
HTTP request to get tasks from site failed: Server disconnected without
sending a response.
Nothing in that message points at certificates, which is what made this one hard to recognise.
Who is affected
Sites running 2.5.0p9 through 2.5.0p12, regardless of the relay version - it is the site that rejected the renewal request. A relay stayed healthy until its certificate came up for renewal.
What you need to do
Update your site to 2.5.0p13 or newer. For every relay whose certificate has not expired yet, that is all: the relay renews on its next attempt.
A relay whose certificate has already expired cannot recover on its own - it can no longer reach the site at all, not even to renew, nor to learn that a fixed version is available. It does not need to be re-registered either. We provide a recovery procedure that opens a short window in which the site accepts the expired certificate, just long enough for the relay to update itself and renew; the relay keeps its ID, its hosts and their history. For more details see the related KB article
Technical background
The relay sent the certificate signing request without a Content-Type header.
Up to 2.5.0p8 the site parsed the body as JSON anyway. The FastAPI update in
2.5.0p9 made that strict, so the site treated the body as an opaque string and
answered 422 Unprocessable Entity. The relay now announces the request body
as application/json.