Hi, I have the https sample up and running. When I try to point it to my own domain, however it tries to connect to LTE then errors out. Could it be a certificate issue?

To construct a pem file, I go to my domain in chrome, click the icon in the location bar, then click the “connection is secure”, then “certificate is valid”, then details tab, then export. I have tried both BASE 64 encoded ascii single and BASE 64 encoded ascii certificate chain. I then prefix each line with double quotes and append \n" to each line. Seems to largely mirror your pem file. I’ve done a pristine build. It doesn’t work, however.

How do I get this working?

Thank you!
Jason

Hi Jason

There are a few things here.

I would pop your site’s root certificate into the cloud folder, update the name of the file here:

/* CA Certificate */
static const char cert[] = {
#include "isrg-root-x1.pem"
};

Make sure that the format of your file follows the same one as the one included with the sample (isrg-root-x1.pem). The quotes and ‘\n’ characters are critical.

If you’re using Let’s Encrypt, the one that’s included should work for your site.

Can you share a log so I can see where the problem is? Are you getting a “Failed to connect.” or “Unable to publish” error?

Thank you for your reply. My server is on Vercel, which does use letsencrypt certs, but I’m not able to get things working.

I added this LOG_INF lines to pinpoint where the error is:
/* Connect */
LOG_INF(“Connecting to LTE”);
err = lte_lc_connect();
if (err < 0)
{
LOG_ERR(“Failed to connect. Err: %i”, err);
return err;
}
LOG_INF(“Connected to LTE”);

Here’s the log:
Connecting..
Connected to /dev/cu.usbserial-10!
*** Booting Zephyr OS build v3.3.99-ncs1-2 ***
[00:00:00.252,685] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9160
[00:00:00.537,506] <inf> cloud: Certificate match
[00:00:00.541,351] <inf> main: Connecting to LTE
[00:10:00.585,845] <inf> lte_lc: Network connection attempt timed out
[00:10:00.622,406] <inf> lte_lc: Using fallback network mode

I have also tried reverting the git repo back to your https example code and that does work fine. for what that’s worth.

I should say also that its more common for the modem to just hang on the let_lc_connect(); line, with log something like the following:

*** Booting Zephyr OS build v3.3.99-ncs1-2 ***
[00:00:00.252,655] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9160
[00:00:00.538,452] <inf> cloud: Certificate match
[00:00:00.542,297] <inf> main: Connecting to LTE

Do you:

  • Have a SIM inserted?
  • Have an antenna connected to the correct port?
  • Activated the SIM?
  • LTE-M service in your area?

My guess it’s one of those things!

Just to ensure, we’re on the same sample:

“nrf/samples/net/https_client”

And you changed the destination with altering

#define HTTPS_HOSTNAME “example.com”

How large are you server’s certificates (in bytes)?

Hi, I’m sure the SIM card is inserted, antenna is correctly installed, sim is activated and LTE-M service is in my area because the sample works out of the box. If I simply run the sample as is, the nrf9160 feather makes a number of POST requests to www.circuitdojo.com/some/path which succeed.

If I make the following changes, however, the app silently fails and resets trying to active the LTE network on line err = lte_lc_connect();

In Kconfig:

   config CLOUD_HOSTNAME
        string "Base URL"
-       default "www.circuitdojo.com"
+       default "okthatworks.com"

Also in Kconfig

 config CLOUD_PUBLISH_PATH
     string "Publish Path"
-    default "/some/path"
+    default "/api/test"

Those are the only changes. The root cert for okthatworks.com is identical to the www.circuitdojo.com root cert, because both domains use certs that are chained up to lets encrypt. Also, the following command shows that the issue isn’t the server:

curl https://okthatworks.com/api/test -X POST -H "Content-Type: application/json" -d '{"do_something":true}'
returns:
data: { do_something: true }%

That api/test route just echos whatever json data is POSTed into it.

@AchimKraus : I am actually using the nfed/samples/https/ sample! Sorry if that wasn’t clear.

I would modify the values in the Kconfig using an overlay (.conf) or add your values to the project’s prj.conf.

Nevertheless, seems like you have a connection issue:

[00:00:00.541,351] <inf> main: Connecting to LTE
[00:10:00.585,845] <inf> lte_lc: Network connection attempt timed out
[00:10:00.622,406] <inf> lte_lc: Using fallback network mode

This is indicative of not being able to connect to the cell towers. Though there is one caveat:

I have encountered a bug in the past where if you connect/disconnect frequently during testing the modem will time out trying to connect. It’s very difficult to reproduce for Nordic to look at.

What version of the SDK and toolchain are you using?

That sounds really strange. I haven’t observed, that changing the destination causes the modem to even not register in the cellular network. The only idea would be to use a “–pristine” build, if you didn’t already do so.

This bug is completely unexplainable to me…. Could one of you please try to repro it? I think the process would be change those two lines in kconfig to point the example at my server and see if you get the same error. If you get the same behavior, then I think that would mean there is something wrong with the DNS or certs on my server. Maybe? Otherwise, I don’t know what else to do. Maybe it’s a hardware issue?

One other clue is that if I run ngrock and point the nrf9160 to my local server (through the ngrock service) I get a slightly different error (I’ve turned on modem debug output):

Connecting..
Connected to /dev/cu.usbserial-110!
*** Booting Zephyr OS build v3.3.99-ncs1-2 ***
[00:00:00.252,838] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9160
[00:00:00.544,677] <inf> cloud: Certificate match
[00:00:00.554,107] <inf> main: lte init
[00:00:00.554,565] <inf> main: power saving on
+CEREG: 2,"8B3A","0A128E0F",7
+CSCON: 1
+CEREG: 5,"8B3A","0A128E0F",7,,,"00001000","00100110"
%XTIME: "2B","4221324054712B","00"
[00:00:09.058,166] <inf> main: lte connected
[00:00:09.058,319] <inf> cloud: Publish path: 8b47-157-131-113-156.ngrok-free.app/api/test
[00:00:09.058,349] <inf> cloud: Payload: {"do_something": "true"}
[00:00:09.058,380] <inf> cloud: Looking up 8b47-157-131-113-156.ngrok-free.app

It then resets. So, this gets a bit further, but still has issues at the basic level of setting up the socket.

Thanks so much for your help!

What version of the SDK and toolchain are you using?

I miss the answer.

Could one of you please try to repro it?

That would require the answer, which nfed version you use.

Here’s some output from the top of the build pristine command:

Loading Zephyr default modules (Zephyr base).
-- Application: /Users/oh/Desktop/dojo/nfed/samples/https
-- CMake version: 3.22.0
-- Using NCS Toolchain 2.6.20240304.378197178396 for building. (/opt/nordic/ncs/toolchains/580e4ef81c/cmake)
-- Found Python3: /opt/nordic/ncs/toolchains/580e4ef81c/bin/python3 (found suitable exact version "3.9.6") found components: Interpreter 
-- Cache files will be written to: /Users/oh/Library/Caches/zephyr
-- Zephyr version: 3.3.99 (/Users/oh/Desktop/dojo/zephyr)
-- Found west (found suitable version "1.2.0", minimum required is "0.7.1")
-- Board: circuitdojo_feather_nrf9160_ns
-- Found host-tools: zephyr 0.16.4 (/Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4)
-- Found toolchain: zephyr 0.16.4 (/Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4)
-- Found Dtc: /opt/nordic/ncs/toolchains/580e4ef81c/bin/dtc (found suitable version "1.6.1", minimum required is "1.4.6") 
-- Found BOARD.dts: /Users/oh/Desktop/dojo/zephyr/boards/arm/circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160_ns.dts
-- Generated zephyr.dts: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/dts.cmake

warning: Experimental symbol HTTP_CLIENT is enabled.

That seems like the most authoritative way for me to answer your question. I hope I got that right.

Thank you so much for your help so far.

Jason

I’m realizing that perhaps I should have included more of the pristine output here.

-- west build: making build dir /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns pristine
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /Users/oh/Desktop/dojo/nfed/samples/https
-- CMake version: 3.22.0
-- Using NCS Toolchain 2.6.20240304.378197178396 for building. (/opt/nordic/ncs/toolchains/580e4ef81c/cmake)
-- Found Python3: /opt/nordic/ncs/toolchains/580e4ef81c/bin/python3 (found suitable exact version "3.9.6") found components: Interpreter 
-- Cache files will be written to: /Users/oh/Library/Caches/zephyr
-- Zephyr version: 3.3.99 (/Users/oh/Desktop/dojo/zephyr)
-- Found west (found suitable version "1.2.0", minimum required is "0.7.1")
-- Board: circuitdojo_feather_nrf9160_ns
-- Found host-tools: zephyr 0.16.4 (/Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4)
-- Found toolchain: zephyr 0.16.4 (/Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4)
-- Found Dtc: /opt/nordic/ncs/toolchains/580e4ef81c/bin/dtc (found suitable version "1.6.1", minimum required is "1.4.6") 
-- Found BOARD.dts: /Users/oh/Desktop/dojo/zephyr/boards/arm/circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160_ns.dts
-- Generated zephyr.dts: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/dts.cmake

warning: Experimental symbol HTTP_CLIENT is enabled.

Parsing /Users/oh/Desktop/dojo/nfed/samples/https/Kconfig
Loaded configuration '/Users/oh/Desktop/dojo/zephyr/boards/arm/circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160_ns_defconfig'
Merged configuration '/Users/oh/Desktop/dojo/nfed/samples/https/prj.conf'
Merged configuration '/Users/oh/Desktop/dojo/nfed/samples/https/boards/circuitdojo_feather_nrf9160_ns.conf'
Configuration saved to '/Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/.config'
Kconfig header saved to '/Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/zephyr/include/generated/autoconf.h'
-- Found GnuLd: /Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd (found version "2.38") 
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Found Python3: /opt/nordic/ncs/toolchains/580e4ef81c/bin/python3 (found version "3.9.6") found components: Interpreter 
Changed board to secure circuitdojo_feather_nrf9160 (NOT NS)

=== child image mcuboot -  begin ===
loading initial cache file /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base).
-- Application: /Users/oh/Desktop/dojo/bootloader/mcuboot/boot/zephyr
-- CMake version: 3.22.0
-- Using NCS Toolchain 2.6.20240304.378197178396 for building. (/opt/nordic/ncs/toolchains/580e4ef81c/cmake)
-- Found Python3: /opt/nordic/ncs/toolchains/580e4ef81c/bin/python3 (found suitable exact version "3.9.6") found components: Interpreter 
-- Cache files will be written to: /Users/oh/Library/Caches/zephyr
-- Zephyr version: 3.3.99 (/Users/oh/Desktop/dojo/zephyr)
-- Found west (found suitable version "1.2.0", minimum required is "0.7.1")
-- Board: circuitdojo_feather_nrf9160
-- Found host-tools: zephyr 0.16.4 (/Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4)
-- Found toolchain: zephyr 0.16.4 (/Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4)
-- Found Dtc: /opt/nordic/ncs/toolchains/580e4ef81c/bin/dtc (found suitable version "1.6.1", minimum required is "1.4.6") 
-- Found BOARD.dts: /Users/oh/Desktop/dojo/zephyr/boards/arm/circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160.dts
-- Found devicetree overlay: /Users/oh/Desktop/dojo/bootloader/mcuboot/boot/zephyr/app.overlay
-- Generated zephyr.dts: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot/zephyr/dts.cmake

warning: UART_CONSOLE (defined at drivers/console/Kconfig:43) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: CONSOLE (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_UART_CONSOLE and/or look up UART_CONSOLE in
the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration
Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

Parsing /Users/oh/Desktop/dojo/bootloader/mcuboot/boot/zephyr/Kconfig
Loaded configuration '/Users/oh/Desktop/dojo/zephyr/boards/arm/circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160_defconfig'
Merged configuration '/Users/oh/Desktop/dojo/bootloader/mcuboot/boot/zephyr/prj.conf'
Merged configuration '/Users/oh/Desktop/dojo/bootloader/mcuboot/boot/zephyr/boards/circuitdojo_feather_nrf9160.conf'
Merged configuration '/Users/oh/Desktop/dojo/nrf/modules/mcuboot/tfm.conf'
Merged configuration '/Users/oh/Desktop/dojo/nrf/modules/mcuboot/fih_low_enable.conf'
Merged configuration '/Users/oh/Desktop/dojo/nrf/subsys/partition_manager/partition_manager_enabled.conf'
Merged configuration '/Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '/Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot/zephyr/.config'
Kconfig header saved to '/Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot/zephyr/include/generated/autoconf.h'
-- Found GnuLd: /Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd (found version "2.38") 
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /Users/oh/.zephyrtools/toolchain/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
CMake Warning at /Users/oh/Desktop/dojo/zephyr/CMakeLists.txt:839 (message):
  No SOURCES given to Zephyr library: lib__libc__common

  Excluding target from build.


MCUBoot bootloader key file: /Users/oh/Desktop/dojo/bootloader/mcuboot/root-ec-p256.pem
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/oh/Desktop/dojo/nfed/samples/https/build/circuitdojo_feather_nrf9160_ns/mcuboot
=== child image mcuboot -  end ===

CMake Warning at /Users/oh/Desktop/dojo/nrf/modules/mcuboot/CMakeLists.txt:310 (message):
  

          ---------------------------------------------------------
          --- WARNING: Using default MCUBoot key, it should not ---
          --- be used for production.                           ---
          ---------------------------------------------------------
          



CMake Warning at /Users/oh/Desktop/dojo/zephyr/CMakeLists.txt:839 (message):
  No SOURCES given to Zephyr library: lib__libc__common

  Excluding target from build.

Using nrf9160-feather-examples-and-drivers - v2.6.x I get:

nfed/samples/https:

west build -b circuitdojo_feather_nrf9160_ns -p

[00:00:00.250,488] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9160
[00:00:00.547,973] <inf> cloud: Certificate match
[00:00:05.344,146] <inf> cloud: Publish path: www.circuitdojo.com/some/path
[00:00:05.344,299] <inf> cloud: Payload: {“do_something”:true}
[00:00:05.344,329] <inf> cloud: Looking up www.circuitdojo.com
[00:00:07.824,737] <inf> cloud: Connected!
[00:00:07.824,768] <inf> cloud: Socket setup complete
[00:00:08.175,689] <inf> cloud: HTTP Status 200
[00:00:08.175,811] <inf> cloud: HTTP Status 200
[00:00:08.175,933] <inf> cloud: HTTP Status 200
[00:00:08.176,055] <inf> cloud: HTTP Status 200
[00:00:08.289,276] <inf> cloud: HTTP Status 200
[00:00:08.289,367] <inf> cloud: HTTP Status 200
[00:00:08.289,489] <inf> cloud: HTTP Status 200
[00:00:08.289,611] <inf> cloud: HTTP Status 200
[00:00:08.289,825] <inf> cloud: HTTP Status 200
[00:00:08.289,947] <inf> cloud: HTTP Status 200
[00:00:08.290,039] <inf> cloud: HTTP Status 200
[00:00:08.290,161] <inf> cloud: HTTP Status 200
[00:00:08.290,313] <inf> cloud: HTTP Status 200
[00:00:08.319,396] <inf> cloud: HTTP Status 200
[00:00:08.319,519] <inf> cloud: HTTP Status 200
[00:00:08.319,671] <inf> cloud: HTTP Status 200
[00:00:08.360,382] <inf> cloud: Data sent to cloud

and with

west build -b circuitdojo_feather_nrf9160_ns -p -- -DCONFIG_CLOUD_HOSTNAME="\"okthatworks.com\"" -DCONFIG_CLOUD_PUBLISH_PATH="\"/api/test\""

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
[00:00:00.250,488] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9160
[00:00:00.547,760] <inf> cloud: Certificate match
[00:00:05.650,573] <inf> cloud: Publish path: okthatworks.com/api/test
[00:00:05.650,726] <inf> cloud: Payload: {“do_something”:true}
[00:00:05.650,756] <inf> cloud: Looking up okthatworks.com
[00:00:06.118,774] <err> cloud: Unable to connect. Err: -111 - Connection refused
[00:00:06.122,406] <err> os: ***** BUS FAULT *****
[00:00:06.122,406] <err> os: Precise data bus error
[00:00:06.122,436] <err> os: BFAR Address: 0×0
[00:00:06.122,436] <err> os: r0/a1: 0xfffffffc r1/a2: 0×20013c2c r2/a3: 0×2000d394
[00:00:06.122,467] <err> os: r3/a4: 0×00000020 r12/ip: 0×00000000 r14/lr: 0×0002e381
[00:00:06.122,467] <err> os: xpsr: 0×21000000
[00:00:06.122,497] <err> os: Faulting instruction address (r15/pc): 0×0002ad04
[00:00:06.122,528] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:06.122,558] <err> os: Current thread: 0×2000d240 (unknown)
[00:00:06.211,975] <err> fatal_error: Resetting system

A look at the certificates shows:

“www.circuitdojo.com” => ECDSA 256, “E5” => ECDSA 384, “ISRG Root X1” => RSA 4096

“okthatworks.com” => RSA 2048, “R10” => RSA 20248, “ISRG Root X1” => RSA 4096

My guess, the RSA chain is over the size limit of the nRF9160 for certificates.

Not sure, what you want to do in the end, but this smells like something, which will fail in both, energy consumption and reliability. In my experience, RSA is not “ok” for embedded ;-).

Edited:

    /* Cipher suite */
    // Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    nrf_sec_cipher_t cipher_list[] = {0xc02b};

may also prevent to be able to connect …
…
It may require a modem trace. Maybe “okthatworks.com” offers ECDSA as well and only my browser got the RSA stuff.

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
[00:00:00.250,488] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9160
[00:00:00.547,698] <inf> cloud: Certificate match
[00:00:05.196,502] <inf> cloud: Publish path: okthatworks.com/api/test
[00:00:05.196,655] <inf> cloud: Payload: {“do_something”:true}
[00:00:05.196,685] <inf> cloud: Looking up okthatworks.com
[00:00:06.577,056] <inf> cloud: Connected!
[00:00:06.577,117] <inf> cloud: Socket setup complete
[00:00:08.178,375] <inf> cloud: HTTP Status 200
[00:00:08.186,950] <inf> cloud: HTTP Status 200
[00:00:08.187,011] <inf> cloud: Response data
66 65 74 63 68 0d 0a 58 2d 4d 61 74 63 68 65 64 |fetch..X -Matched
2d 50 61 74 68 3a 20 2f 61 70 69 2f 74 65 73 74 |-Path: / api/test
0d 0a 58 2d 56 65 72 63 65 6c 2d 43 61 63 68 65 |..X-Verc el-Cache
3a 20 4d 49 53 53 0d 0a 58 2d 56 65 72 63 65 6c |: MISS.. X-Vercel
2d 49 64 3a 20 6c 68 72 31 3a 3a 69 61 64 31 3a |-Id: lhr 1::iad1:
3a 32 36 67 6d 66 2d 31 37 33 35 33 37 32 38 36 |:26gmf-1 73537286
38 33 38 36 2d 38 34 36 62 30 65 64 31 39 63 39 |8386-846 b0ed19c9
35 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 |5..Conne ction: c
6c 6f 73 65 0d 0a 54 72 61 6e 73 66 65 72 2d 45 |lose..Tr ansfer-E
6e 63 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 |ncoding: chunked
0d 0a 0d 0a 31 63 0d 0a 64 61 74 61 3a 20 7b 20 |….1c.. data: {
64 6f 5f 73 6f 6d 65 74 68 69 6e 67 3a 20 74 72 |do_somet hing: tr
75 65 20 7d 0d 0a 30 0d 0a 0d 0a 30 0d 0a 56 61 |ue }..0. …0..Va
72 79 3a 20 52 53 43 2c 20 4e 65 78 74 2d 52 6f |ry: RSC, Next-Ro
75 74 65 72 2d 53 74 61 74 65 2d 54 72 65 65 2c |uter-Sta te-Tree,
20 4e 65 78 74 2d 52 6f 75 74 65 72 2d 50 72 65 | Next-Ro uter-Pre
[00:00:08.187,011] <inf> main: Cloud callback
[00:00:08.188,232] <inf> cloud: Data sent to cloud

After removing

err = setsockopt(fd, SOL_TLS, TLS_CIPHERSUITE_LIST, cipher_list, sizeof(cipher_list));

it works on my “feather” :.

On a nRF9160-DK with modem-trace I get from “okthatworks.com” :-)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

Certificates (2561 bytes)
    Certificate Length: 1266
    Certificate: 308204ee308203d6a003020102021204fdf5078dd54f131032441184ac19bb8e4f300d06… (id-at-commonName=okthatworks.com)
        signedCertificate
        algorithmIdentifier (sha256WithRSAEncryption)
        Padding: 0
        encrypted: 28c188af4c8567c71c6a7f49e9dd4f45b4209a3b0bc53578ba52d90716d389e2ab38c565…
    Certificate Length: 1289
    Certificate: 30820505308202eda00302010202104ba85293f79a2fa273064ba8048d75d0300d06092a… (id-at-commonName=R10,id-at-organizationName=Let's Encrypt,id-at-countryName=US)
        signedCertificate
        algorithmIdentifier (sha256WithRSAEncryption)
        Padding: 0
        encrypted: 92b1e74137eb799d81e6cde225e13a20e9904495a3815ccfc35dfdbda070d5b19628220b…

So, it’s really about 2K RSA certificates.

Wow, amazing work. Thank you so much for this. I’ll see if I can just purchase an RSA cert and install it on that domain.

Thank you so much!
Jason

    theIntuitionist

    ECDSA works for embedded devices and cellular communication much better than RSA.
    I personally even don’t use x509, I use RFC7250 (Raw Public Key). I also don’t use HTTP/TCP, I use CoAP/UDP and a proxy to forward that to a HTTP API.

    if I can just purchase

    Not sure, maybe let’s encrypt helps.

    Thank you so much!

    you’re welcome.

      I have mqtt up and running for message passing, but was working on https to post large files- somewhere around a few megabytes in size more or less (prob a bit less, frequently)- for storage on a server. What do you think the best communications mode is for this task?

      Sounds like a camera-trap. That’s not my domain.
      I mainly use it for low-power monitoring/metering. That’s more or less “200-600” bytes every hour.
      From other tickets (mainly in the Nordic Forum), you will need to be careful, because the nRF9160 is no Raspberry PI and some approaches may fail, just because RAM isn’t available in MBytes ;-).

      Terms and Conditions | Privacy Policy