9151 https download

[pauloslf]

HI, i have been using the nrf9151 to download my OTA's it has been working fine, but since this week it stopped working for all device we have deployed, i suspect it is related to the change in certificates but i already tried to go back to a certificate of the same type, also tryed multiple options on nginx and reverted back to what we had, but currenly http works fine while https always fails, even if i use other https urls stored in a diferent server.

I can validate the behavior also using tge nrf desktop and AT commands:

> AT+CFUN=1

OK
> AT+CEREG?

+CEREG: 0,5,"BCB6","0010D9FF",7

OK
> AT#DOWNLOADFW="https://updates.server.com","/firmwares/download/795/firmware.bin?currentversion=2026-01-27T14:41:05Z&deviceId=F4EEFA811B94"
OK

OK
> AT#GETDOWNLOADDATA=1024
+DL: 3, -34

OK

Any idea what could have caused this issue?

[Syed Maysum Abbas Zaidi]

Hi,

This most likely looks like a TLS/certificate issue on the modem side. A common cause is that the server’s certificate chain has changed (for example due to a CA rotation or expiry), and the nRF9151 no longer trusts your HTTPS server, so the TLS handshake fails. Similar issues have been seen when HTTPS suddenly stopped working until the CA in the device was updated. So please try the following

1. Inspect the certificate chain presented by https://updates.server.com (using a browser certificate viewer or openssl s_client) and identify the root CA used.
2. On the device, list the currently stored certificates using: AT%CMNG=1
3. If the root CA used by the server is not present in the modem then delete the old CA and write the correct root CA that matches your server’s current chain.

Best Regards,
Syed Maysum

[pauloslf]

Hi Syed,Thank you for the quick response. We've already investigated the certificate chain and it appears to be correct. Here's what we've found:1. Server certificate chain (via openssl s_client):

0 s:CN =https://updates.server.com

  i:C = US, O = Let's Encrypt, CN = R13

1 s:C = US, O = Let's Encrypt, CN = R13

  i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

2. Modem credentials (AT%CMNG=1): %CMNG: 42,0,"BD6681410FB05ECD2B414AFA3B02E285132CD289F9CAD......"

Security tag 42 (type 0 = CA cert) contains the ISRG Root X1 certificate, which is the root CA for the R13 intermediate. The chain should validate correctly.

3. Additional diagnostics that suggest this is NOT a certificate issue:

• HTTP downloads work perfectly -- when we bypass TLS and use http:// with AT#DOWNLOADFW, the firmware downloads successfully.

• The TLS handshake appears to succeed -- our backend (behind nginx) receives 8+ HTTP requests from the modem during a single download attempt, meaning the TLS connection is established and the HTTP GET request reaches the server.

• Error codes change with server TLS configuration:

• TLS 1.3 (CHACHA20-POLY1305): +DL: 3, -34 (ERANGE)

• TLS 1.2 (AES128-GCM, default record size): +DL: 3, -12 (ENOMEM)

• TLS 1.2 (AES128-GCM, ssl_buffer_size 4k): +DL: 3, -104 (ECONNRESET)

• Modem firmware: mfw_nrf91x1_2.0.2, Application firmware: 1.4

• This was working 2 weeks ago with the same modem firmware. The server runs nginx 1.28 and we suspect an OpenSSL update may have changed TLS record sizes.

Our current theory is that the server's TLS record/fragment size is too large for the modem's receive buffer (similar to EMSGSIZE issues reported by other nRF91 users). 

We trying upgrading the modem to 2.0.4 (last available version) but the issue remains

Best regards,

Paulo

[Syed Maysum Abbas Zaidi]

Hi,

Based on the additional details and the error codes (-12 ENOMEM, -34 ERANGE, -104 ECONNRESET), this does not look like a certificate validation issue, since the TLS handshake completes and your backend receives HTTPS requests. 

The nRF91 modem has a documented TLS receive size limitation of around 2 kB as shown here. If the TLS packet (which includes HTTP headers and payload inside a single TLS record) exceeds this limit, the download can fail after the handshake. So can you try capturing the TLS traffic (for example with Wireshark) and checking the TLS record lengths being sent by the server.

Best Regards,
Syed Maysum

[pauloslf]

HI,

the issue was caused by a server change, basically the range http header was not being handled, the nrf was requesting 1024 bytes and receiving a lot more, and that caused the described problems, we managed to fix the issue server side and the code we had started to work without issues.

Thanks for your support

[Syed Maysum Abbas Zaidi]

Hi,

Thanks for sharing the root cause of the issue and we’re glad to hear the OTA download is now working again.

Best Regards,
Syed Maysum