IOT Devices disconnect from IOT HUB post min TLS config change

Hello @Denis ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

Based on the given information, the behavior appears closely correlated with the IoT Hub configuration change "minTlsVersion": "1.2"

The timing of the fleet-wide disconnects immediately after enabling TLS 1.2 strongly suggests that the configuration change exposed an underlying compatibility limitation that was not previously enforced.

Validating the following will be helpful-

1. Cipher Suite Compatibility A device can support TLS 1.2 while still failing to connect if the TLS handshake cannot negotiate a cipher suite accepted by IoT Hub. Recommended validation:
   • Capture TLS handshake logs from an affected SIM868E device.
   • Review the ClientHello message.
   • Confirm the TLS version offered by the modem.
   • Identify the cipher suites presented during negotiation.
   • Check for TLS alerts such as handshake failure or protocol-version errors.
   Particular attention should be given to whether the modem can negotiate modern ECDHE-based cipher suites supported by IoT Hub.
2. MQTT Security Configuration Please validate the MQTT connection configuration to ensure:
   • Endpoint is configured as <hub>.azure-devices.net.
   • MQTT communication is TLS-secured.
   • TLS 1.2 is explicitly configured.
   • Authentication configuration (SAS token or X.509) is correct.
   • Secure socket profile matches the TLS requirements.
3. Certificate Validation Although considered secondary to cipher-suite validation, certificate trust should also be reviewed. suggested checks:
   • Verify required root certificate authorities are installed.
   • Validate certificate chain verification succeeds.
   • Confirm there are no expired or outdated certificates involved in the TLS handshake.
4. SNI (Server Name Indication) Validation Please confirm whether the modem correctly sends <hub>.azure-devices.net during TLS negotiation. This is a compatibility consideration that should be validated during the handshake review, particularly when working with embedded TLS stacks.
5. IoT Hub Diagnostics Review IoT Hub diagnostics around the configuration change timestamp:
   • Connection failures.
   • Disconnect events.
   • Authentication errors.
   • TLS-related failures.
   • Connection metrics by TLS version and cipher suite.
6. Device Time Validation As a lower-probability check:
   • Verify accurate UTC time.
   • Enable NTP synchronization if available.
   Time drift can affect certificate validation and SAS token authentication but is less likely to explain a simultaneous fleet-wide disconnect immediately after the TLS configuration change

Regarding the request to revert the TLS setting ,A temporary rollback can be considered as a diagnostic step to determine whether the observed behavior is directly linked to the recent configuration change. However, rollback should be treated as a troubleshooting measure rather than a confirmed long-term solution.

The following references might be helpful , please check them out

• Monitor and Troubleshoot Azure IoT Hub Device Connectivity | Microsoft Learn
• Azure IoT Hub TLS support | Microsoft Learn
• Use MQTT to communicate with Azure IoT Hub - Azure IoT Hub | Microsoft Learn
• Monitor device status - Azure IoT Hub | Microsoft Learn

Please let us know if the response was helpful

Thank you

This issue may be related: https://learn.microsoft.com/en-us/answers/questions/2242718/azure-https-connections-from-simcom-cellular-modem

Hi Karnam

We will begin pulling the required data listed in the comment above.

This will take some time to collated as we rely on an external vendor for Device firmware support.

Can we look at a more immediate fix in the interim to allow the devices to reconnect such as the requested roll back of the TLS enforcement?

Kind regards

Denis.

Hello @Denis ,

Please allow us some time to suggest a workaround

Thank you