EC200U-CN: AT+QHTTPGET returns 732 (SSL handshake failed) to a public ECDSA/RSA host even with TLS 1.2 + RSA ciphersuite forced

IoT Modules LTE Standard Module
1

Dear Quectel Technical Support,

We are using the EC200U-CN (firmware revision AAR03) for an HTTPS firmware-download (OTA) feature and are blocked by a TLS handshake failure we cannot resolve from the AT documentation we have. We would appreciate your guidance.

Summary: AT+QHTTPGET always returns +QHTTPGET: 732 (SSL handshake failed) against our HTTPS host, despite the full SSL configuration sequence being accepted by the module.

Host: https://ota.connect-links.com (served via Cloudflare). By default it presents an ECDSA leaf certificate (chain: leaf → Google Trust Services WE1 → GTS Root R4). When a client offers only RSA ciphersuites, the same host instead presents an RSA chain (leaf → WR1 → GTS Root R1) and accepts classic RSA suites such as ECDHE-RSA-AES128-GCM-SHA256. (Confirmed with openssl s_client.)

What works: Over plain HTTP the same host serves the file perfectly — +QHTTPGET: 0,200,<len> — so the bearer/PDP, the host, and the file are all fine. The failure is purely the TLS handshake.

Exact AT sequence we run on the OTA SSL context (id 2), with the module’s reply:

AT+QHTTPCFG="contextid",1            -> OK
AT+QHTTPCFG="sslctxid",2             -> OK
AT+QSSLCFG="sslversion",2,3          -> OK      (TLS 1.2)
AT+QSSLCFG="ciphersuite",2,0xC02F    -> OK      (intend ECDHE-RSA-AES128-GCM-SHA256)
AT+QSSLCFG="seclevel",2,1            -> OK      (verify server certificate)
AT+QSSLCFG="cacert",2,"UFS:otacacert.pem"  -> OK   (RSA chain WR1 + GTS Root R1 uploaded; QFLST shows 3974 bytes)
AT+QHTTPURL=<len>,80                 -> CONNECT -> <url> -> OK
AT+QHTTPGET=80                       -> OK
                                     -> +QHTTPGET: 732

Every configuration command returns OK, and the CA file uploads and is accepted — yet the GET handshake fails with 732.

Our questions:

  1. Ciphersuite value encoding: For AT+QSSLCFG="ciphersuite",<ctx>,<value>, what is the exact accepted value set on EC200U-CN AAR03? Is <value> the IANA cipher code (e.g. 0xC02F = ECDHE-RSA-AES128-GCM-SHA256), or a Quectel-specific code? Could you provide the full ciphersuite value table? We suspect 0xC02F may not select the suite we intend (the module returns OK but the handshake still fails), so the ClientHello may still be offering ECDSA suites, causing the server to send an ECDSA certificate the module cannot verify/handshake.

  2. ECDSA certificate support: Does the EC200U-CN AAR03 TLS stack support ECDSA server certificates (e.g. ECDHE-ECDSA suites, P-256/P-384)? If not, what is the correct ciphersuite value to restrict the ClientHello to RSA-only so the server presents its RSA certificate?

  3. Recommended configuration: For a public-CA host that prefers ECDSA/TLS 1.3 but also offers an RSA/TLS 1.2 path (typical Cloudflare config), what QSSLCFG settings do you recommend on EC200U-CN AAR03 to complete the handshake?

  4. Is there an AT command to query the negotiated ciphersuite / TLS error detail beyond the 732 code, to help us diagnose?

We can provide a full AT trace log and the server certificate chains on request. Thank you very much for your help.

Best regards,
Sanjay M. Dalvi
ConnectLinks

2

Hi,

Regarding the TLS handshake failure (+QHTTPGET: 732 ), please refer to the following suggestions.

  1. Cipher Suite Value

The value used with AT+QSSLCFG="ciphersuite",<ctx>,<value> is the IANA cipher suite code in hexadecimal format. For example:

AT+QSSLCFG="ciphersuite",2,0xC02F

corresponds to:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The EC200U series supports the following cipher suites (including RSA and ECDSA variants). You may also use:

AT+QSSLCFG="ciphersuite",2,0xFFFF

to allow the module to negotiate any supported cipher suite automatically.

  1. ECDSA Certificate Support

The EC200U series supports ECDSA server certificates and the corresponding ECDSA cipher suites. Therefore, if the server presents an ECDSA certificate, the module is capable of completing the TLS handshake provided the correct Root CA is loaded and the SSL configuration is correct.

  1. Recommended SSL Configuration

For servers hosted behind Cloudflare or using public CAs, please also check the following settings:

  • Enable SNI (Server Name Indication), as Cloudflare commonly requires it:
AT+QSSLCFG="sni",2,1
  • Ensure the module’s RTC is correct. If the local time is invalid, certificate validation may fail. For initial testing, you can temporarily ignore the certificate validity period:
AT+QSSLCFG="ignorelocaltime",2,1

A recommended configuration is:

AT+QHTTPCFG="contextid",1
AT+QHTTPCFG="sslctxid",2
AT+QSSLCFG="sslversion",2,3
AT+QSSLCFG="sni",2,1
AT+QSSLCFG="ignorelocaltime",2,1
AT+QSSLCFG="seclevel",2,1
AT+QSSLCFG="cacert",2,"UFS:otacacert.pem"
AT+QSSLCFG="ciphersuite",2,0xFFFF

Alternatively, you may force a specific cipher suite such as 0xC02F if required.

  1. Further Diagnostics

If the handshake still fails, please execute:

AT+QIGETERROR

immediately after receiving:

+QHTTPGET: 732

This command will provide the detailed SSL error code, which will help identify the root cause.

Please share the output of AT+QIGETERROR if the issue persists so we can continue the investigation.