Hello,
We are trying to establish a mqtt connection between a nrf9160 Feather and digitalocean server following your instruction on this website

We have setup a server with mosquitto running on a digital ocean server, and flashed nrf9160 feather with mqtt_simple sample.

However, the MQTT connection does not seem to work properly, we observed error -45 (Operation not supported on socket) from LTE Link Monitor, mosquitto service on server log saids
OpenSSL Error[0]: error 1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate

We made sure our certificates are generated with easy-rsa following your instructions, also attempted to swap the CA_CERTIFICATE defined in certificates.h header file in mqtt_simple sample with our ca.crt generated by easy-rsa on our server, however the error -45 persists.

Then we disabled TLS with CONFIG_MQTT_LIB_TLS=n in proj.conf file, error -45 is gone, but error -57(Socket is not connected) appeared, LTE link monitor outputs
mqtt_simple: MQTT client disconnected: -57
mqtt_simple: mqtt_input: -57
mqtt_simple: Disconnecting MQTT client...
qtt_simple: Could not disconnect MQTT client: -57

And mosquitto service outputs
OpenSSL: OpenSSL Error[0]: error:1408F10B:SSL routines:ssl3_get_record:wrong version number
Client <unknown> disconnected: Protocol error

So I have a few questions:

  1. Should we replace the CA_CERTIFICATE in certificates.h with our ca certificate generated with easy-rsa on server?
  2. Should we place the nrf9160 certificate and key in certificates.h also?
  3. How do we resolve the -57 (Socket is not connected) issue?

Thank you,
Ron Zeman

  • jaredwolff replied to this.

  • ronzeman what are you using as the CONFIG_SEC_TAG within your code? Are you writing that to the correct security tag with the device when it’s programmed with at_client? Looks like you have certs in the NRF Cloud security tag and also 2039.

    ronzeman I noticed when I execute ./easyrsa sign-req client nrf9160 batch the commonName appeared to be ASN.1 12:‘nrf9160’ instead of my domain name, I wonder could this be the issue?

    Only should matter for the CA and server.

        Hi Ron

        ronzeman Should we replace the CA_CERTIFICATE in certificates.h with our ca certificate generated with easy-rsa on server?

        You’ll need to configure your server to use the CA certificate generated during the process. You also have to generate a server certificate which also needs to be added to the Mosquitto config. One easy way to make sure that the certificates are working is by using mosquitto_pub CLI.

        If you missed it here are some test commands to make sure the server is running ok:

        mosquitto_sub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/publish/topic" &
mosquitto_pub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/subscribe/topic" -m "hello there"

        You can actually use the cert that you’ll be programming to your device with mosquitto_pub/sub. Remember, when generating your certificates the domain name needs to match exactly to where your device is connecting. If there’s any mismatch, it will fail to connect.

        Should we place the nrf9160 certificate and key in certificates.h also?

        Once you’ve tested the server and it’s working we can move to the device itself. You’ll need to provision your certificates to the device using LTE Link Monitor

        https://www.jaredwolff.com/how-to-connect-nrf9160-feather-to-mosquitto/#add-certs-to-device

        This includes the CA Cert (public), private key generated by easy-rsa and public key. This should be new and different from the server cert you created before. In general, if you set your certs using LTE Link Monitor you should ignore using certificates.h. (Not recommended to use this file at all actually)

        Hope that helps

            jaredwolff
            Hi Jared,

            Thank you for your prompt reply.

            I checked the certificate using the commands you gave,

            mosquitto_sub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h domain.name.com -p 8885 -t "/my/publish/topic"

            The command above returned

            Client mosqsub|766-king sending CONNECT
Client mosqsub|766-king received CONNACK
Client mosqsub|766-king sending SUBSCRIBE (Mid: 1, Topic: /my/publish/topic, QoS: 1)
Client mosqsub|766-king received SUBACK
Subscribed (mid: 1): 1
Client mosqsub|766-king sending PINGREQ
Client mosqsub|766-king received PINGRESP

            Then I did mosquitto_pub in another terminal

            mosquitto_pub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h domain.name.com -p 8885 -t "/my/subscribe/topic" -m "hello there"

            This returned

            Client mosqpub|1567-king sending CONNECT
Client mosqpub|1567-king received CONNACK
Client mosqpub|1567-king sending PUBLISH (d0, q1, r0, m1, '/my/subscribe/topic', ... (11 bytes))
Client mosqpub|1567-king received PUBACK (Mid: 1)
Client mosqpub|1567-king sending DISCONNECT

            Does that indicate the MQTT connection is established correctly?
            The LTE Link Monitor however still outputs

            [00:18:48.585,418] [1;31m<err> mqtt_simple: mqtt_connect -45
[00:18:48.585,449] [0m<inf> mqtt_simple: Reconnecting in 60 seconds...

            Does this means the certificate is still wrong?
            Thank you for your help.

                ronzeman Does that indicate the MQTT connection is established correctly?

                Looks ok. mosquitto_sub subscribes to the topic you provide so when you run mosquitto_pub you will see the message on the mosquitto_sub side. Make sure though that you’re using the same topic (using the -t param) if you want to check this. Otherwise there aren’t any errors which is a good sign!

                ronzeman Does this means the certificate is still wrong?

                Likely that it’s not correct. Did you load the certificates you’re using with mosquitto_sub to the device using LTE Link Monitor? You need to make sure that the tag is the correct value in order for it to use the correct certificate. You can run AT%CMNG=1 and that will return a list of all the set certificates. Make sure you have entries for the tag that is being used by that sample.

                      jaredwolff
                      I tried to generate the certificates again following this instruction, however the problem (error -45) persists.
                      Here are the output when I generated the certificates and keys

                      root@hullbot-ubuntu18-droplet:~/easy-rsa/easyrsa3# ./easyrsa gen-req nrf9160 nopass batch
Using SSL: openssl OpenSSL 1.1.1  11 Sep 2018
Generating a RSA private key
......................................................................................+++++
.................+++++
writing new private key to '/root/easy-rsa/easyrsa3/pki/easy-rsa-13262.Ml8L8c/tmp.uWqUQb'
-----
                      root@hullbot-ubuntu18-droplet:~/easy-rsa/easyrsa3# ./easyrsa sign-req client nrf9160 batch
Using SSL: openssl OpenSSL 1.1.1  11 Sep 2018
Using configuration from /root/easy-rsa/easyrsa3/pki/easy-rsa-13367.69LwwZ/tmp.StICts
Enter pass phrase for /root/easy-rsa/easyrsa3/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'nrf9160'
Certificate is to be certified until Jan 11 01:36:47 2024 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

                      I noticed when I execute ./easyrsa sign-req client nrf9160 batch the commonName appeared to be ASN.1 12:'nrf9160' instead of my domain name, I wonder could this be the issue?

                      I did AT%CMNG=1 on LTE Link Monitor, it returned

                      AT%CMNG=1
%CMNG: 0,6,"0606060606060606060606060606060606060606060606060606060606060606"
%CMNG: 2039,0,"0000000000000000000000000000000000000000000000000000000000000000"
%CMNG: 2039,1,"0101010101010101010101010101010101010101010101010101010101010101"
%CMNG: 2039,2,"0202020202020202020202020202020202020202020202020202020202020202"
%CMNG: 16842753,0,"0000000000000000000000000000000000000000000000000000000000000000"
%CMNG: 16842753,1,"0101010101010101010101010101010101010101010101010101010101010101"
%CMNG: 16842753,2,"0202020202020202020202020202020202020202020202020202020202020202"
OK

                      Is this normal?
                      Thank you.

                          ronzeman what are you using as the CONFIG_SEC_TAG within your code? Are you writing that to the correct security tag with the device when it’s programmed with at_client? Looks like you have certs in the NRF Cloud security tag and also 2039.

                          ronzeman I noticed when I execute ./easyrsa sign-req client nrf9160 batch the commonName appeared to be ASN.1 12:‘nrf9160’ instead of my domain name, I wonder could this be the issue?

                          Only should matter for the CA and server.

                                jaredwolff
                                Thanks Jared, the probelm is indeed related to CONFIG_SEC_TAG
                                There is a line in mqtt_simple/src/main.c

                                static sec_tag_t sec_tag_list[] = { CONFIG_MQTT_TLS_SEC_TAG };

                                It overwrote the line added to top in your instruction

                                static sec_tag_t sec_tag_list[] = { CONFIG_SEC_TAG };

                                Now everything seems to be working as expected.
                                Thanks a lot for your help Jared!

                                    Terms and Conditions | Privacy Policy