EC200U CN - MQTTS Certificate Expiry Handling (Dynamic Certificate Update)

IoT Modules LTE Standard Module
,
1

Hello Quectel Team,

I am currently using the EC200U-CN module to communicate with server over MQTT.

Previous Setup:

Earlier, I was using MQTT and everything was working fine. Now I have migrated to MQTTS and have started using MQTTS-related AT commands for secure communication.

Current Implementation:

To enable MQTTS, I upload server’s certificate to the module using the following command:

AT+QFUPL="UFS:cacert.pem",1590

This works perfectly. After uploading the certificate, the module successfully communicates with the MQTTS server.

Issue:

The issue I am facing now is certificate expiry. I can retrieve server’s certificate.

However, the certificate retrieved has an expiry date (a months days to a year). Once it expires, the GSM module stops communication with the server.

Question:

  • Is there any way to dynamically manage or update the certificate on the EC200U module?
  • Can the GSM module automatically fetch the certificate during MQTTS connection and validate it without manual upload?
  • If not, what is the best recommended practice for updating the certificate before expiry, especially for remote/deployed devices?

My main goal is to make the system more robust and not depend on manual intervention to keep updating certificates every few days.

Any guidance or recommended approach from Quectel would be highly appreciated.

Thanks,
Kazuki

2

Dear @kazuki1 ,

Thank you for your question.

For the EC200U-CN series, the module does not provide a mechanism to automatically retrieve or automatically renew the server CA certificate during an MQTTS connection. For MQTT over SSL, the module requires the SSL context to be configured in advance, and when SSL mode is enabled for MQTT, the SSL context index must be specified by AT+QMTCFG=“ssl”,<client_idx>,<SSL_enable>,<SSL_ctx_idx>. The same MQTT application note also states that AT+QSSLCFG is used to configure the SSL version, cipher suite, security level, CA certificate, client certificate, client key, and RTC-time related behavior for the MQTT SSL handshake. This means the certificate used for server verification is expected to be prepared and stored on the module side first, rather than fetched dynamically from the broker during connection.

In other words, the certificate management model on this platform is file-based and host-controlled. The FILE application note shows that the module uses UFS as the user file storage area and that files are uploaded with AT+QFUPL. It also provides file management operations such as listing files and deleting files. Therefore, the normal design flow is that the host MCU or application processor uploads the certificate into UFS, and then the SSL context is configured to point to that certificate file.

A typical certificate provisioning sequence is as follows.

  1. Upload the new CA certificate into UFS with AT+QFUPL.
  2. Bind the uploaded certificate file to the SSL context with AT+QSSLCFG=“cacert”,<ssl_ctx_id>,“UFS:cacert.pem”.
  3. Enable MQTT SSL and assign that SSL context with AT+QMTCFG=“ssl”,<client_idx>,1,<ssl_ctx_id>.
  4. Reopen the MQTT network and reconnect the client.

This behavior is also consistent with the HTTPS examples, where the certificate is first uploaded to UFS and then explicitly configured into the SSL context with AT+QSSLCFG.

So for your question about certificate expiry, once the currently configured CA certificate is no longer valid for the server certificate chain, the MQTTS handshake can fail because the module will continue to use the expired or outdated CA file that was previously configured. The module will not automatically replace that file by itself. The certificate must be updated by the device application logic or by the host side remote management mechanism.

The recommended implementation for deployed products is to treat certificate rotation as part of the device maintenance flow. A robust approach is the following.

  1. Your backend should provide the renewed CA certificate before the current one expires.
  2. The host side of the device should download the new certificate from a trusted source, for example through HTTPS or FTPS.
  3. The new certificate should be uploaded into the module UFS with AT+QFUPL.
  4. After upload, the old certificate can be replaced or a new filename can be used.
  5. Update the SSL context with AT+QSSLCFG=“cacert”,<ssl_ctx_id>,“UFS:new_cacert.pem”.
  6. Close the existing MQTT session if it is active, then reopen and reconnect using the updated SSL context.
  7. After confirming successful reconnection, the old certificate file can be deleted with the file management command if required.

From a system design perspective, this is the correct remote-update method because it avoids manual onsite intervention and keeps certificate renewal under application control. The module provides the storage and SSL configuration capability, but the renewal trigger and update logic must be implemented by the customer application.

Regarding your question on whether the module can simply fetch the certificate from the server during connection and validate it automatically, the current documents do not describe such a feature for MQTT SSL on this series. The documented flow is always based on a locally configured SSL context and locally referenced certificate file. Therefore, the correct expectation is that automatic certificate acquisition is not part of the standard MQTTS AT command workflow on this platform.

One additional note is that the MQTT application note mentions AT+QSSLCFG can configure RTC-time related behavior for the SSL handshake. This is useful when device time handling affects certificate time validation, but it is not a substitute for renewing an expired CA certificate. If the CA certificate itself is outdated or no longer appropriate for the server chain, it still needs to be replaced with a valid one.

So the final conclusion is as follows.

  1. The module does not automatically fetch or automatically refresh the CA certificate for MQTTS.
  2. The certificate used for MQTT SSL must be uploaded to UFS and configured explicitly through AT+QSSLCFG.
  3. When the certificate expires or changes, it must be updated by the host application or remote device management logic.
  4. The best practice for field devices is to implement a remote certificate rotation mechanism using HTTPS or FTPS delivery, UFS file update, SSL context reconfiguration, and MQTT reconnection.

Thank you.

Best Regards,
Aghelan