GM02SP UE8.2.3.1 fails certificate validation with ISRG Root X2 chains (cURL error 35)

LTE-M / NB-IoT (Monarch)
1

Hello,

We are seeing a TLS certificate-validation problem on a Sequans GM02SP running:

SEQUANS Communications
GM02SP
UE8.2.3.1

The modem can connect successfully to a server using an RSA certificate chain trusted through ISRG Root X1, but fails when the server uses a chain trusted through ISRG Root X2.

Working X1 test

AT+SQNSPCFG=1,2,"",1,19,18,1,"","",0,0,0
OK

AT+SQNHTTPCFG=1,"valid.x1.test-certs.letsencrypt.org",443,0,"","",1,120,1,1,60,0
OK

AT+SQNHTTPCONNECT=1
OK

+SQNHTTPCONNECT: 1,0

CA slot 19 contains our CA bundle, including ISRG Root X1 and ISRG Root X2.

Failing X2 test

Using the same security profile:

AT+SQNHTTPCFG=1,"valid.x2.test-certs.letsencrypt.org",443,0,"","",1,120,1,1,60,0
OK

AT+SQNHTTPCONNECT=1
OK

+SQNHTTPCONNECT: 1,35
+SQNHTTPSH: 1,35

Test with standalone ISRG Root X2

To rule out CA-bundle parsing issues, we provisioned a standalone ISRG Root X2 certificate in slot 17:

AT+SQNSNVR="certificate",17

+SQNSNVR: "certificate",17,
"/C=US/O=Internet Security Research Group/CN=ISRG Root X2",
"41d29dd172eaeea780c12c6ce92f8752",
"/C=US/O=Internet Security Research Group/CN=ISRG Root X2",
"20/09/04 00:00:00",
"40/09/17 16:00:00",
"sha384ECDSA",
...
"sha1",
"bd49d42c1fbb733120cd260418ac892a6954d54c"

We then selected only that CA:

AT+SQNSPCFG=1,2,"",1,17,18,1,"","",0,0,0
OK

AT+SQNHTTPCONNECT=1
OK

+SQNHTTPCONNECT: 1,35
+SQNHTTPSH: 1,35

The modem clock is correct:

AT+CCLK?

+CCLK: "26/09/01,15:51:11+08"
OK

Disabling certificate validation

When certificate validation is disabled, the same X2 server connects successfully:

AT+SQNSPCFG=1,2,"",0,17,18,1,"","",0,0,0
OK

AT+SQNHTTPCONNECT=1
OK

+SQNHTTPCONNECT: 1,0

This indicates that network connectivity, DNS, TLS negotiation, and the ECDSA handshake work. The failure appears to occur specifically during X.509 certificate/path validation.

Our production server uses an ECDSA chain ultimately anchored in ISRG Root X2, and it shows the same behavior. External OpenSSL clients validate and connect to that server successfully.

Could Sequans please confirm:

  1. Is ISRG Root X2 or an ECDSA P-384 trust anchor unsupported by UE8.2.3.1?
  2. Is this a known certificate-path-validation issue?
  3. Is there a newer GM02SP firmware containing a fix?
  4. Is there a secure workaround other than changing the server to an RSA/ISRG Root X1 chain?

Disabling certificate validation is not an acceptable production workaround.

Thank you.

2

Hi Klemens,

  1. Is ISRG Root X2 or an ECDSA P-384 trust anchor unsupported by UE8.2.3.1?
    [SQNS]I am checking the capability of GM02SP SSL engine and it might still need some time. I will back to you later.
  2. Is this a known certificate-path-validation issue?
    [SQNS]No. I have review the SQN internal bug history and there is not similar issue like this one.
  3. Is there a newer GM02SP firmware containing a fix?
    [SQNS]LR8.2.3.1 is the latest one for GM02SP.
  4. Is there a secure workaround other than changing the server to an RSA/ISRG Root X1 chain?
    [SQNS]I might not in position to answer that yet as it is not clear for the root cause.

If I may, I would like to understand if you manage to make X2 work with previous GM02SP SW release? I am asking it to clarify if this is regression issue.

1 Like
3

I looks like the issue started to occur since FW LR8.2.2.1-63493, before that i managed to publish messages to my backend. Also in the FW version LR8.2.2.1-63493 it looked like it sometimes worked and sometimes failed depending on any unknown reasons. That is why i did a FW upgrade in hopes that this issue will be solved, but now it fails all the time.

4

Hi Klemens,

May I know if you recall the SW release for full working case? I would like to review the change history then it is good to have precise anchor.

5

Hi,
I checked and found a prototype which was not updated but from the same patch, it has FW version LR8.2.0.0-58753

Thank you for checking!