We’re experiencing certificate renewal failures on our edge devices running MQTT clients with Cumulocity 1020. The devices connect fine initially, but after the automatic certificate renewal attempt (configured for 90-day rotation), the TLS handshake fails and devices lose connectivity completely.
The MQTT client logs show:
TLS handshake failed: certificate verify failed
MQTT connection error: SSL_ERROR_SYSCALL
Connection refused by broker
We’re using the standard MQTT SDK for device certificate auto-renewal, but it seems the new certificates aren’t being properly validated. Our edge device firmware is v2.8.3, and we’ve configured TLS 1.2 as required. Has anyone encountered similar issues with certificate rotation in MQTT integrations? The data loss during these outages is becoming critical for our billing operations.
This sounds like the certificate renewal hook isn’t properly configured in your MQTT client settings. The SDK supports auto-renewal, but you need to explicitly configure the post-renewal callback to trigger a client restart. Without this, the client continues using the old certificate from its SSL context even though a new one exists on disk.
I’ve seen this before. Usually it’s a timing issue where the new certificate is generated but the MQTT client doesn’t reload it properly. Check if your edge devices are caching the old certificate in memory. You might need to force a client reconnection after renewal completes. What’s your certificate renewal workflow - is it triggered by the device or centrally managed?
The renewal is centrally managed through the Cumulocity platform. We push new certificates to devices, and they’re supposed to automatically restart the MQTT client. The issue is the handshake fails immediately when using the new cert. Could this be a firmware compatibility problem with how TLS 1.2 validates the certificate chain?