AT+QSSLOPEN / HTTP(S) SSL handshake fails universally (err=579), while AT+QMTOPEN mutual TLS succeeds

Technical Subjects Driver
,
5

Thank you for the detailed analysis. Here are the latest updates:

1. PC-side verification against the actual failing endpoint and CA.

Here is the test against the actual OTA host and CA we have configured on the modem (ota_ca.pem/ota_client.pem/ota_key.pem on UFS):

openssl s_client \
  -connect ota.staging.domalys.com:443 \
  -tls1_2 -servername ota.staging.domalys.com \
  -CAfile domalys_servers_L0_L1.pem -cert ota_domalys_L2.pem -key ota_domalys_L2.key \
  -state \
  -verify_return_error

Result: handshake completes, Verify return code: 0 (ok). Notably, the state trace shows the server never sends a CertificateRequest (No client certificate CA names sent, no “write certificate” step) — this endpoint does one-way (server-authenticated) TLS only and authenticates the client via an Authorization: Token ... HTTP header, not a TLS client certificate. So seclevel=2 was never actually required here.

2. We already ran the seclevel isolation you’d expect from that finding. On the modem, we tested both:

  • seclevel=2 (CA + client cert + client key uploaded and configured) — AT+QHTTPGETEX fails, +QHTTPGET: 701, AT+QIGETERROR reports 0, operate successfully, ~0.9s.
  • seclevel=1 (CA cert only, no client cert uploaded or configured — matching what the PC trace shows is actually required) — identical failure, same error, same timing.

Both fail identically regardless of whether a client cert is in play at all, which rules out the client certificate as the variable.

3. This matches a pattern already resolved on your side for this exact module. We found EG916Q-GL AT+QSSLOPEN Always Returns Error 579 — EG916Q-GL, firmware EG916QGLLGR01A05M04_A0.300.A0.300 (one revision behind our A0.301.A0.301), reporting AT+QSSLOPEN universally failing with 579 regardless of host or cert config, with PC-side OpenSSL confirmed working throughout — identical to what we’re seeing. Your team resolved that case by providing a patched firmware build. Given the match, could you confirm whether that same patch (or a newer one) applies to A0.301.A0.301, or whether a further update is available?

We’re happy to still run the same-context AT+QSSLOPEN vs AT+QMTOPEN comparison against the MQTT broker if it’s still useful alongside a firmware check — let us know.