• State Suggested Answer
  • +2 person also asked this people also asked this
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 65 subscribers
  • Views 5614 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 241653
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF9160 TLS_HOSTNAME support

DeltaXP

Is TLS_HOSTNAME socket option supported inside the modem firmware or bsdlib?

When I make the function call:

err = setsockopt(client_fd, SOL_TLS, TLS_HOSTNAME, host, sizeof(host));

returns with err==42.

 

I need to set this socket option for my application. I am using AWS API Gateway with a custom domain name and the certificate that gets served by default is the "*.execute-api.us-east-1.amazonaws.com" and not my domain certificate. Then, I believe the TLS peer verification fails due to hostname mismatch.

I am using fairly latest, SW Versions:

fw-nrfconnect-nrf:v1.1.0
fw-nrfconnect-zephyr:v2.0.99-ncs1
nrfxlib:v1.1.0
mfw_nrf9160_1.1.0
Parents
  • 0

    Hot damn, you're right.  Calls to setsockopt are returning +42 for TLS_HOSTNAME.  I was briefly convinced it must be calling the wrong setsockopt through the offload mechanisms, but I added trace logging down in nrf91_socket_offload_setsockopt and it is getting the +42 back from nrf_setsockopt directly.

    [00:00:14.170,898] <wrn> nrf91_sockets: nrf_setsockopt(3, 282, 4, 0x20032ba0, 4)
[00:00:14.181,488] <wrn> nrf91_sockets: nrf_setsockopt retval=0
[00:00:14.190,551] <inf> net_mqtt_sock_tls: setsockopt PEER_VERIFY 0
[00:00:14.199,768] <wrn> nrf91_sockets: nrf_setsockopt(3, 282, 2, 0x20032fc0, 4)
[00:00:14.210,327] <wrn> nrf91_sockets: nrf_setsockopt retval=0
[00:00:14.219,390] <inf> net_mqtt_sock_tls: setsockopt SEC_TAG_LIST 0
[00:00:14.228,698] <wrn> nrf91_sockets: nrf_setsockopt(3, 282, 5, 0x20032d0a, 27)
[00:00:14.239,349] <wrn> nrf91_sockets: nrf_setsockopt retval=42
[00:00:14.248,504] <inf> net_mqtt_sock_tls: setsockopt HOSTNAME 42

    That's completely against the documentation for nrf_setsockopt.

    Hey, can we get someone at Nordic with visibility into the BSDLIB to comment, please?

    In my testing, I was using MFW 1.1.0 and BSDLIB 0.5.1.

Reply
  • 0

    Hot damn, you're right.  Calls to setsockopt are returning +42 for TLS_HOSTNAME.  I was briefly convinced it must be calling the wrong setsockopt through the offload mechanisms, but I added trace logging down in nrf91_socket_offload_setsockopt and it is getting the +42 back from nrf_setsockopt directly.

    [00:00:14.170,898] <wrn> nrf91_sockets: nrf_setsockopt(3, 282, 4, 0x20032ba0, 4)
[00:00:14.181,488] <wrn> nrf91_sockets: nrf_setsockopt retval=0
[00:00:14.190,551] <inf> net_mqtt_sock_tls: setsockopt PEER_VERIFY 0
[00:00:14.199,768] <wrn> nrf91_sockets: nrf_setsockopt(3, 282, 2, 0x20032fc0, 4)
[00:00:14.210,327] <wrn> nrf91_sockets: nrf_setsockopt retval=0
[00:00:14.219,390] <inf> net_mqtt_sock_tls: setsockopt SEC_TAG_LIST 0
[00:00:14.228,698] <wrn> nrf91_sockets: nrf_setsockopt(3, 282, 5, 0x20032d0a, 27)
[00:00:14.239,349] <wrn> nrf91_sockets: nrf_setsockopt retval=42
[00:00:14.248,504] <inf> net_mqtt_sock_tls: setsockopt HOSTNAME 42

    That's completely against the documentation for nrf_setsockopt.

    Hey, can we get someone at Nordic with visibility into the BSDLIB to comment, please?

    In my testing, I was using MFW 1.1.0 and BSDLIB 0.5.1.

Children
Related