Hi Quectel team,
I’m stuck on X.509 device authentication to Azure IoT Hub with an EC200U-EU
(EC200UEUAAR03A13M08). TLS connects fine, but MQTT CONNECT is always refused:
AT+QSSLCFG="sslversion",4,3 OK
AT+QSSLCFG="seclevel",4,2 OK
AT+QSSLCFG="clientcert",4,"azure_cert.pem" OK (RSA-2048, uploaded via QFUPL)
AT+QSSLCFG="clientkey",4,"azure_key.pem" OK
AT+QSSLCFG="sni",4,1 OK (read-back confirms "sni",4,1)
AT+QSSLCFG="cacert",4,"azure_ca.pem" OK (DigiCert Global Root G2)
AT+QMTCFG="ssl",0,1,4 / "version",0,4 OK
AT+QMTOPEN=0,"<hub>.azure-devices.net",8883
+QMTOPEN: 0,0 <- TLS handshake completes
AT+QMTCONN=0,"<deviceId>","<hub>.azure-devices.net/<deviceId>"
+QMTCONN: 0,0,5 <- always "not authorized"
I saw thread 53312 with the same error — but in my case seclevel 2 and SNI were
already set, and it still fails.
What makes me think the module is not sending the client certificate at all:
-
The same cert/key/username from a PC (OpenSSL) connects fine → CONNACK 0.
It even works without SNI and without the EMS extension, so the server isn’t
strict about those. -
Azure’s CertificateRequest (checked with
openssl s_client -trace) has an
empty CA list and allows basically every signature algorithm, so there’s
nothing the module could fail to match. -
I registered both possible thumbprints on the IoT Hub device → still 5.
-
The same module does mutual TLS to AWS IoT successfully, and SAS auth
to the same Azure hub also works — so only “X.509 + Azure” fails. -
Also tried: TLS version ALL, forcing ciphersuite 0XC02F, fresh file names,
fully isolated run right after modem power-on. Always 0,0,5.
So it looks like the TLS stack skips the client Certificate specifically in
Azure’s handshake. Could you check with internal logs whether this is a known
issue? And if there’s a fixed firmware — we’d need it for both EC200U-EU and
EC200U-AU, ideally as a DFOTA delta from R03A13M08 since our modules are
deployed in the field.
Happy to share full AT logs or run any test build. Thanks!