Can EC200U - CN 4G module can support TLS for mqtt 8883 port connection. or do i need to upgrade the module firmware ?
Because in my module i am unable to connect with 8883 TLS connection. but i can connect with mqtt 1883 port.
can you please guide ho can i resolved this.
Dear @Piyush_Chaudhari ,
Thank you for reaching out.
I have addressed your queries via mail.
Kindly check your mail inbox.
Best Regards,
Aghelan
I am testing MQTT over TLS (SSL) on the EC200U-CN module as per your guidance and the MQTT TLS example you shared. I am sharing the complete results and logs for your review.
Module: EC200U-CN
SIM: Airtel (India)
Broker: HiveMQ Cloud
Authentication: Username / Password
TLS: Server authentication only (CA certificate)
AT+QIACT?
+QIACT: 1,1,1,"100.89.53.6"
PDP context is active and internet access is working.
AT+QPING=1,"8.8.8.8"
+QPING: success (multiple replies received)
AT+QPING=1,"a3c53da1e061486a8b2e00ed4bb0d6e8.s1.eu.hivemq.cloud"
OK
DNS resolution works correctly.
AT+QFLST
+QFLST: "UFS:boot",15004
+QFLST: "UFS:firm",243616
+QFLST: "UFS:cacert.pem",619
CA certificate is uploaded successfully in UFS.
AT+QMTCFG="SSL",0,1,2
OK
AT+QSSLCFG="cacert",2,"UFS:cacert.pem"
OK
AT+QSSLCFG="seclevel",2,1
OK
AT+QSSLCFG="sslversion",2,4
OK
AT+QSSLCFG="ciphersuite",2,0xFFFF
OK
AT+QSSLCFG="ignorelocaltime",2,1
OK
AT+QSSLCFG="sni",2,1
OK
Port 8883 (MQTT over TLS):
AT+QMTOPEN=0,"a3c53da1e061486a8b2e00ed4bb0d6e8.s1.eu.hivemq.cloud",8883
+QMTOPEN: 0,5
Port 443:
AT+QMTOPEN=0,"a3c53da1e061486a8b2e00ed4bb0d6e8.s1.eu.hivemq.cloud",443
+QMTOPEN: 0,1
result = 5).result = 1, possibly due to protocol mismatch (RAW MQTT vs WebSocket).Could you please confirm:
Please let me know if you need any additional logs or traces.
Dear @Piyush_Chaudhari ,
Thank you for sharing the detailed logs.
From your test result:
AT+QMTOPEN=0,“a3c53da1e061486a8b2e00ed4bb0d6e8.s1.eu.hivemq.cloud”,8883
+QMTOPEN: 0,5
The result code “5” indicates a Network connection error. This means the module could not establish the underlying network/TCP connection to the server on that port. Since the failure happens at QMTOPEN (before MQTT CONNECT and before the TLS handshake completes), the current evidence points to a network/port reachability restriction (SIM/APN/operator firewall policy) rather than a certificate or TLS parameter issue.
Regarding port 443:
AT+QMTOPEN=…,443
+QMTOPEN: 0,1
Result code “1” indicates a wrong parameter. In addition, the EC200U MQTT AT interface is designed for native MQTT over a TCP socket. Port 443 is commonly used by brokers for MQTT over WebSocket/HTTPS, which is a different protocol than native MQTT and is not handled by the AT+QMT* command set.
Recommended next steps:
Please try the same test using a different SIM/operator or an APN profile that allows outbound TCP 8883 (many IoT APNs restrict non-standard ports).
If you must use the current SIM/APN, please request the operator to allow outbound TCP port 8883 to the HiveMQ Cloud endpoint.
If the broker can provide an endpoint that supports native MQTT over TLS on an operator-allowed port, we can help validate the required configuration.
If you can share whether other devices on the same Airtel SIM/APN can reach the same host on port 8883, that will further confirm the port restriction on the network side.
Best Regards,
Aghelan
Dear Support Team,
Thank you for your detailed response and clarification regarding the meaning of +QMTOPEN result code 5.
As suggested, I performed additional tests to verify whether outbound TCP port 8883 is blocked at the SIM/APN/operator level. Please find the key observations below.
Raw TCP connectivity test on port 8883
I tested direct TCP connectivity to the same HiveMQ Cloud endpoint using AT+QIOPEN (bypassing MQTT and SSL):
AT+QIOPEN=1,0,“TCP”,“a3c53da1e061486a8b2e00ed4bb0d6e8.s1.eu.hivemq.cloud”,8883,0,1
Response:
+QIOPEN: 0,0
+QIURC: “closed”,0
This confirms that:
The connection is closed immediately by the server, which is expected since HiveMQ Cloud requires TLS on port 8883 and this test was plain TCP.
MQTT SSL connection attempt
Using the same endpoint and port with MQTT over SSL:
AT+QMTOPEN=0,“a3c53da1e061486a8b2e00ed4bb0d6e8.s1.eu.hivemq.cloud”,8883
Response:
+QMTOPEN: 0,5
Given that raw TCP connectivity to port 8883 is successful, this indicates that the failure occurs after TCP connection establishment, most likely during the TLS handshake stage rather than due to port reachability or APN restrictions.
SSL configuration status
Despite this, the SSL MQTT connection consistently fails at the QMTOPEN stage.
Clarification regarding client certificate and key
In the EC200U SSL example documentation, client certificate and client key configuration are also shown. Could you please clarify the following:
This clarification would help ensure correct interpretation of the reference examples.
Request for guidance
Could you please advise on the following points:
I hope the above test results help narrow down the issue. Please let me know if you need a complete power-on to QMTOPEN command log; I will be happy to share it.
Thank you for your support.
Shouldn’t the intermediate certificate be included as well?
For our current setup, we are using standard TLS server authentication where the device validates the broker certificate using the trusted Root CA. As per common IoT and TLS best practices, the intermediate certificate is provided by the broker during the TLS handshake, and therefore it is not required to be separately stored on the device.
The EC200U module supports certificate chain validation using the Root CA, and this approach works correctly as long as the broker is configured to send the complete certificate chain (which is standard for public cloud and managed MQTT brokers).
If you recommend including the intermediate certificate due to a specific network or broker-side requirement, please let us know and we will incorporate it accordingly.
Looking forward to your guidance
Dear @Piyush_Chaudhari ,
Thank you for running the additional isolation test.
TCP/8883 reachability
Your AT+QIOPEN result +QIOPEN: 0,0 confirms the module is able to establish a TCP connection to the server on port 8883 from the Airtel network path. The subsequent close indication is expected when opening a plain TCP socket to an endpoint that requires TLS on that port, and this test does not validate the TLS handshake path.
Meaning of +QMTOPEN: 0,5
For AT+QMTOPEN, result code 5 is defined as Network connection error. Since direct TCP connection to the same host and port is possible, this suggests the MQTT SSL open procedure is not completing successfully. This can be caused by TLS negotiation parameters, certificate chain verification behavior, cipher compatibility, or server-side rejection during TLS session establishment.
Client certificate and private key
Client certificate and private key are not required for server-authentication-only TLS. With seclevel=1, configuring only the CA certificate is correct. Client certificate and client key are only required when the broker enforces mutual TLS.
Intermediate certificate
In standard public PKI deployments, the broker provides intermediate certificates during the TLS handshake. However, if the chain presented by the server is incomplete or differs from what the module can validate, verification can fail. As a troubleshooting step, please try a CA bundle PEM that contains the intermediate certificate(s) followed by the root CA in a single file, upload it to UFS, and configure it as the cacert.
Next recommended steps:
Please provide the full power-on to SSL configuration to QMTOPEN log, and the firmware version (AT+QGMR).
Please share the broker TLS requirements, including minimum TLS version and the required cipher suites.
Based on the above, we will recommend a validated SSL configuration for HiveMQ or EMQX on your firmware, or advise an upgrade if an interoperability limitation is identified.
Best Regards,
Aghelan
Dear Aghelan,
Module Firmware Version:
EC200UCNAAR03A03M08
Thank you for your continued support and detailed guidance.
As advised, we performed additional isolation and configuration tests on our side and would like to share the scenarios we have already tested, along with sample logs.
Network and TCP Reachability
• PDP context activation is successful and the module obtains an IP address.
• AT+QIOPEN to TCP/8883 returns +QIOPEN: 0,0, confirming TCP reachability.
• This indicates that the SIM/APN path is allowing outbound TCP 8883.
SIM Cross-Check
• The same SIM card, when used in a mobile phone and connected via hotspot, can access services on port 8883 without issue.
• When the same SIM is placed in the EC200U module, MQTT over TLS on 8883 fails.
• This suggests the SIM/network itself is not blocking 8883.
TLS Configuration Tests
We tested server-authentication-only TLS with seclevel=1 using only a CA certificate:
• CA certificate uploaded to UFS successfully
• TLS version set to 1.2
• SNI enabled
• ignorelocaltime enabled
Cipher Suite Tests
We tested multiple cipher configurations:
• ciphersuite = 0xFFFF (default/all)
• ciphersuite = 0x0035
• ciphersuite = 0x002F
The behavior remains the same with +QMTOPEN: 0,5.
Multiple Broker Tests
We tested against:
• EMQX Cloud broker
• Public test broker (test.mosquitto.org)
Behavior is consistent with +QMTOPEN: 0,5.
AT
OK
ATI
Quectel
EC200U
Revision: EC200UCNAAR03A03M08
OK
AT+CPIN?
+CPIN: READY
OK
AT+CEREG?
+CEREG: 0,1
OK
AT+QIACT?
+QIACT: 1,1,1,“100.89.27.0”
OK
AT+QFUPL=“UFS:cacert.pem”,1294,100
CONNECT
+QFUPL: 1294,3d51
OK
AT+QSSLCFG=“cacert”,2,“UFS:cacert.pem”
OK
AT+QSSLCFG=“seclevel”,2,1
OK
AT+QSSLCFG=“sslversion”,2,4
OK
AT+QSSLCFG=“ignorelocaltime”,2,1
OK
AT+QSSLCFG=“sni”,2,1
OK
AT+QSSLCFG=“ciphersuite”,2,0xFFFF
OK
AT+QMTCFG=“recv/mode”,0,0,1
OK
AT+QMTCFG=“SSL”,0,1,2
OK
AT+QMTOPEN=0,“g180d1c7.ala.asia-southeast1.emqxsl.com”,8883
OK
+QMTOPEN: 0,5
As per your recommendation, our next step will be to test a CA bundle including intermediate + root certificates in a single PEM file and share those results.
Please let us know if there are any additional diagnostic commands or debug modes we can enable on the EC200U to further analyze the TLS handshake behavior.
Thank you again for your support.
Best regards,
Piyush
Dear @Piyush_Chaudhari ,
Thank you for the detailed update and the log.
Your AT+QIOPEN result confirms TCP connectivity to port 8883 is reachable from the module, so this is not an operator or APN port-blocking issue. Since AT+QMTOPEN in SSL mode still returns 0,5 across different brokers, the remaining root causes are in the TLS session establishment path, typically certificate chain validation, server certificate type compatibility, or TLS cipher negotiation.
For your use case, client certificate and private key are not mandatory. With seclevel configured for server authentication only, using only a CA certificate is the correct approach. Client cert and key are only required if the broker enforces mutual TLS.
Next actions to make this conclusive:
CA bundle test
Proceed with a CA bundle PEM that includes the intermediate chain and the root CA in a single file. Upload it to UFS and configure it as the cacert for the same SSL context, then retry QMTOPEN.
Confirm broker certificate type and TLS policy
Please confirm whether the broker endpoint presents an RSA or ECDSA server certificate, and the minimum TLS version and allowed TLS 1.2 cipher suites. If the broker is ECDSA-only or restricts to cipher suites not supported by the module, the TLS negotiation can fail even when the CA is correct. A quick way to check is from a PC using openssl s_client to the same host and port and noting the negotiated cipher and certificate signature algorithm.
Share the minimum evidence right before QMTOPEN
Please share:
Please share the CA bundle test result and the broker TLS details (RSA/ECDSA, minimum TLS, cipher list). Based on those results, we will advise the next action.
Best Regards,
Aghelan
Dear Aghelan,
Thank you for your continued support.
We have now completed all the requested isolation tests and would like to share a consolidated update with evidence. Based on these results, the issue appears to be in the TLS session establishment on the module side.
We verified raw TCP connectivity to port 8883 using AT+QIOPEN. The module successfully establishes a TCP session, confirming that the operator/APN is not blocking port 8883.
Example result:
AT+QIOPEN=1,0,“”,8883,0,1
+QIOPEN: 0,0
+QIURC: “closed”,0
This confirms TCP reachability is OK.
We created a CA bundle containing the intermediate and root CA in a single PEM file (Let’s Encrypt R12 + ISRG Root X1 for HiveMQ Cloud), uploaded it to UFS, and configured it as cacert.
Verification:
AT+QFLST=“UFS:*”
+QFLST: “UFS:cacert.pem”,3740
So the CA bundle is correctly stored and recognized by the module.
We configured server-authentication-only TLS (no client cert/key):
AT+QSSLCFG=“cacert”,2,“UFS:cacert.pem”
AT+QSSLCFG=“seclevel”,2,1
AT+QSSLCFG=“sslversion”,2,4
AT+QSSLCFG=“ignorelocaltime”,2,1
AT+QSSLCFG=“sni”,2,1
AT+QSSLCFG=“ciphersuite”,2,0xFFFF
AT+QMTCFG=“SSL”,0,1,2
All commands returned OK.
Using openssl s_client from a PC to the same endpoint:
• Server certificate type: RSA (2048-bit)
• Protocol negotiated: TLS 1.2
• Cipher: ECDHE-RSA-AES128-GCM-SHA256
• Verification: OK (full chain validated)
So the broker is not ECDSA-only and supports TLS 1.2.
Despite the above:
AT+QMTOPEN=0,“a3c53da1e061486a8b2e00ed4bb0d6e8.s1.eu.hivemq.cloud”,8883
+QMTOPEN: 0,5
We observe the same +QMTOPEN: 0,5 result across multiple public brokers.
ATI reports:
EC200U
Revision: EC200UCNAAR03A03M08
(We can also provide AT+QGMR output if required.)
At this stage:
• TCP connectivity is confirmed
• Correct CA bundle is used
• Server-auth-only TLS is correctly configured
• Broker uses RSA and TLS 1.2
• Multiple cipher configurations were tried
• Same failure occurs across different brokers
Therefore, the remaining likely cause is TLS interoperability or limitation in the current EC200UCNAAR03A03M08 firmware TLS stack.
If possible, could you please try our broker configuration and endpoint on your reference EC200U-CN module and let us know whether it works on your side? This would help confirm whether the behavior is firmware-related or environment-specific.
Could you please advise:
We are happy to run further tests if you suggest specific parameters.
Thank you for your guidance and support.
Best regards,
Piyush
Dear @Piyush_Chaudhari ,
Thank you for the consolidated update and the evidence.
From your results, TCP/8883 reachability is confirmed, the CA bundle is correctly applied, the broker negotiates TLS 1.2 with an RSA certificate on PC, and the module still returns QMTOPEN 0,5 consistently across brokers. This strongly suggests the failure is occurring during TLS session establishment on the module side (negotiation, verification, or compatibility), not due to SIM/APN port blocking.
To make the root cause conclusive, please do the following and share the outputs:
Confirm whether the module can complete a TLS handshake outside MQTT
Use the SSL AT command flow from the EC200U SSL application note to open a TLS connection to the same hostname and port using SSL context 2.
If the SSL connection also fails, it confirms a general TLS interoperability issue on this firmware build.
If the SSL connection succeeds but QMTOPEN still fails, it points to an MQTT SSL specific issue on this firmware build.
Use module-supported cipher configuration
Please avoid using non-TLS cipher values. Set TLS version to 1.2 and configure the cipher suite strictly based on the cipher suite options listed for this module in the SSL application note, then retry QMTOPEN. If possible, start by selecting ECDHE-RSA with AES-GCM suites since that is what your broker negotiates with PC.
Provide exact build information
Please provide AT+QGMR output and confirm the exact firmware package/build you are using, so we can match it internally.
After receiving the SSL handshake test result and the exact build info, we can advise the most suitable supported TLS configuration for this module or confirm the required firmware action.
Best Regards,
Aghelan
Dear Aghelan,
Thank you for your clear guidance and next-step recommendations.
We have reviewed your suggestions and would like to share our current scenario and details from our side.
Current Scenario and Findings
+QMTOPEN: 0,5.This confirms the module is capable of MQTT over TLS in general.
Firmware Information
ATI reports:
EC200U
Revision: EC200UCNAAR03A03M08
We will additionally share AT+QGMR output in our next log capture if required.
Next Tests (as per your guidance)
We will proceed with:
We will share these results once completed.
Clarifications Requested
Could you please confirm which TLS versions are officially supported on this firmware for EC200U-CN?
Are there any known limitations with:
Is there a recommended firmware version that improves TLS interoperability with public MQTT cloud providers?
If possible, could you share a known working TLS configuration example (TLS version + cipher) validated by Quectel with a public MQTT broker?
Your guidance will help us narrow down whether this is a configuration issue or a firmware limitation.
Thank you again for your support.
Best regards,
Piyush
Dear @Piyush_Chaudhari ,
Thank you for the update.
Your Mosquitto control-case is important, and it confirms EC200UCNAAR03A03M08 can complete MQTT over TLS when the server TLS profile matches what the module supports. The consistent failure only with public cloud brokers indicates an interoperability mismatch during TLS session establishment (certificate chain presentation, cipher/handshake policy, or related TLS parameters), not a PDP/DNS/TCP/port issue.
For EC200U-CN MQTT SSL, the supported TLS versions are those provided by the module SSL stack and used with QSSLCFG. In practice for this firmware line, TLS 1.2 is the expected and recommended version for MQTT over SSL. TLS 1.3 is not supported by the EC200U MQTT SSL AT interface on this build, so please continue with TLS 1.2 only.
About ECDHE-RSA, AES-GCM, and public CAs, these are not inherently unsupported, but compatibility depends on the exact broker-side configuration and the negotiated handshake parameters. Your self-hosted broker success already shows the module can work with TLS when the certificate and cipher profile are compatible.
Recommended next step to resolve
Please proceed with the two tests you listed, as they are the most conclusive:
Please also provide full firmware version (AT+QGMR) in your next log so we can match the exact build internally.
If the standalone SSL handshake also fails to the public broker with a complete CA bundle and a module-supported TLS 1.2 cipher, then this points to a TLS interoperability limitation in EC200UCNAAR03A03M08 for that broker profile, and the correct resolution is to move to a newer EC200U-CN firmware build that improves TLS interoperability. Once we have your SSL handshake test result plus AT+QGMR, we will advise the appropriate firmware action and the most suitable TLS configuration for your target broker.
Best Regards,
Aghelan
Dear Aghelan,
Thank you for your continued support.
We would like to share a clear update on our EC200U TLS testing and the behavior we observed regarding CA certificates, SSL context mapping, and file visibility in the module.
Initially, we found that an old CA certificate in the module did not match the broker certificate chain, which caused connection failures. After uploading the correct CA certificate and repeating tests, we observed the following behavior.
When the CA certificate and MQTT SSL use the SAME context ID, the connection fails with +QMTOPEN: 0,5.
Example (2–2):
AT+QSSLCFG=“cacert”,2,“UFS:cacert.pem”
AT+QMTCFG=“SSL”,0,1,2
AT+QMTOPEN=0,“broker”,8883
Result: Connection fails.
Example (1–1):
AT+QSSLCFG=“cacert”,1,“UFS:cacert.pem”
AT+QMTCFG=“SSL”,0,1,1
AT+QMTOPEN=0,“broker”,8883
Result: Connection fails.
When the CA context ID and MQTT SSL context ID are DIFFERENT, the connection succeeds.
Example:
AT+QSSLCFG=“cacert”,2,“UFS:cacert.pem”
AT+QMTCFG=“SSL”,0,1,1
AT+QMTOPEN=0,“broker”,8883
Result: +QMTOPEN: 0,0 (Connected)
AT+QSSLCFG=“cacert”,1,“UFS:cacert.pem”
AT+QMTCFG=“SSL”,0,1,0
AT+QMTOPEN=0,“broker”,8883
Result: Connected.
• If CA context ID = MQTT SSL context ID → connection fails
• If CA context ID ≠ MQTT SSL context ID → connection works
• With incorrect CA certificate → always fails
• With correct CA certificate → works only when context IDs differ
This behavior seems unusual to us and we want to confirm whether this is expected.
We also observed a file system issue on the module. Previously, the following files were visible in UFS:
• UFS:boot
• UFS:firm
At one point, these files were not visible in the listing and appeared to be deleted or missing when using:
AT+QFLST=“UFS:*”
Later, only the CA certificate file (cacert.pem) was visible. We are not sure if this is normal behavior, a display issue, or related to any reset or internal cleanup.
Could you please clarify:
We want to ensure we follow the correct and stable configuration for production deployment.
Thank you for your support and guidance.
Best regards,
Piyush
Dear @Piyush_Chaudhari ,
Thanks for the detailed update.
No, EC200U does not require the CA context and MQTT SSL context to be different. MQTT uses the SSL context specified by AT+QMTCFG=SSL, and the CA/TLS parameters must be configured on that same SSL context via AT+QSSLCFG. If a mismatched context combination appears to work, it typically means the MQTT-bound SSL context already contained valid CA/TLS settings from an earlier run, while the context updated in the latest test was not the one actually being used by MQTT.
To make this conclusive, please do one clean run from a reboot and ensure there is no previous MQTT session still active (disconnect/close MQTT client 0 using the QMT disconnect/close commands supported on your build, for example QMTDISC and QMTCLOSE, before re-testing).
Then configure only one SSL context and bind MQTT to the same context:
AT+QSSLCFG=cacert,2,UFS:cacert.pem
AT+QSSLCFG=seclevel,2,1
AT+QSSLCFG=sslversion,2,4
AT+QSSLCFG=sni,2,1
AT+QSSLCFG=ignorelocaltime,2,1
AT+QMTCFG=SSL,0,1,2
AT+QMTOPEN=0,broker,8883
If your firmware supports readback, please provide the SSL context readback and the QMTCFG SSL binding readback. If readback is not supported, please paste the full command sequence and outputs from reboot to QMTOPEN, including any earlier QSSLCFG/QMTCFG settings.
Regarding UFS:boot and UFS:firm: these are system-managed items, and their visibility can vary by firmware and by the AT+QFLST listing pattern. Normal certificate upload does not delete them, and you do not need to restore them for MQTT TLS operation. Only explicit file delete/format operations would affect user files.
Best regards,
Aghelan