I've been trying to connect my device to AWS IoT for a week, but I'm getting the same error "no matter what" I do (ERROR: mqtt_connect -45), which seemingly is an authorization issue of some kind?
Here are the exact steps I'm doing to connect my device:
This process gives the following output:
LTE Link Connecting ...
LTE Link Connected!
IPv4 Address 0x68e7dd12
ERROR: mqtt_connect -45
Please help me resolve this as I can't identify which step(s) I'm missing.
Thank you in advance.
CLOUD_CLIENT_PRIVATE_KEY is the private key, CLOUD_CLIENT_PUBLIC_CERTIFICATE is the public key
The private key should be CLOUD_CLIENT_PRIVATE_KEY, that's correct. As for the NRF_CLOUD_CLIENT_PUBLIC_CERTIFICATE, both of the remaining certificates (not CA) should be included here. It's important that you separate them with a "-----BEGIN CERTIFICATE-----\n" and "-----END CERTIFICATE-----\n". Also, I'm not sure what this does
I uncheck Use provisioned certificates
but you need to provision certificates, which can be done by adding the config option CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES=y.
The mqtt_connect: -45 by checking the error codes means operation not supported on the socket. This is usually caused by a misconfiguration of the certificates which are provisioned.
Unchecking Use provisioned certificates will provide certificates to the security tag selected in the Kconfig. I don't think you need to add the CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES=y option as this would be for the nRF Cloud library.
From what I can see from your post your problem is probably what you state here CLOUD_CLIENT_PUBLIC_CERTIFICATE is the public key
This is not your public key, but your public certificate from AWS, the file generated from AWS, is usually formatted in the following form <certificate-set-id>-certificate.pem.crt this file as mentioned before has the -----BEGIN CERTIFICATE----- at the beginning of the file. The private key file should have a -----BEGIN RSA PRIVATE KEY----- at the beginning, and the file format is usually <certificate-set-id>-private.pem.key.It's also important, as mentioned before that you follow the formatting of the certificates.h file by having \n endings at the end of each new line in the certificates.h header file.
I do recommend after provisioning your certificates, and you get a successful MQTT connection, that you check the Use provisioned certificates option again. This reduces the tear on the modem flash by not writing the certificates again to the modem. Also, by having the option unchecked, your certificates will be stored in the firmware image and when flashed in the flash of the device. By re-enabling the option, you avoid both these problems
Thank you for the in-depth answer, the problem was indeed that I was using the public key instead of the certificate. Now I am, however, receiving two more error codes "MQTT connect failed -61" and "ERROR: mqtt_connect -12" when I try to connect. Do you have any idea what the cause of this might be? I remember seeing a more descriptive list of the error codes somewhere, but I'm not able to find it again.
Also, I'm not sure if this is a version-thing, but the "CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES" option is nowhere to be found in my sample (aws_fota v1.0.0), I only find "CONFIG_USE_PROVISIONED_CERTIFICATES".
Thank you for the answer, as suggested by sigvartmh I used the provided certificate instead of the public key and the error disappeared. Now, however, I'm getting two new error codes "MQTT connect failed -61" and "ERROR: mqtt_connect -12". Do you have any suggestions on what these error codes mean?
Both you and sigvartmh have been referencing the CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES option, but this is not to be found in the sample. I am, however, seeing the CONFIG_USE_PROVISIONED_CERTIFICATES option, is this the same as the CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES in previous versions of the sample, maybe?
What I tried to say is that you don't need the CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES
The error you get is described as ECONNREFUSED 61 /* Connection refused */ meaning the MQTT endpoint you tried to connect to refused your connection request. I would guess that what you set as the AWS IoT MQTT broker hostname is wrong.
Not sure why you get -12 ENOMEM but I assume it's because a resource is already in use and you can't have 2 MQTT instances with TLS at the same as there is not enough memory on the device to handle it(This is just an assumption)
I've found it easiest to find the host name by going to the test panel of the AWS IoT console. Then click on the name of the console usually something like (Connected as iotconsole-1570880786449-0) and choose view endpoint