Create OTA job

system · June 16, 2018, 7:25pm

ahmedwahdan wrote on June 16, 2018:

I succeeded to test the MQTT publish demo.
Now I’m trying to test the OTA demo but I’m lost in the signing key- certificate thing.
I followed an article and create local CA.crt and CA.key which are works as my Certificate Authority and created my device.crt and device.key signed with the CA.crt.
Now I’m trying to create a OTA job on IOT core console and I have issue importing my device certificate and key, the console doesn’t accept them for some reason, any suggestions?
I also have some questions:
1- Device hardware platform, can I still use the Windows Simulator option while I’m using my ESP32 hardware as is not yet supported?
2- Why I have to specify the code signing certificate and firmware path on my device?!
3- This certificate and key differ from the certificate and key for MQTT communication, right?

Thanks

Edited by: ahmedwahdan on Jun 16, 2018 12:26 PM

system · June 19, 2018, 7:48pm

Alexa-AWS wrote on June 19, 2018:

Hi,

As you’ve pointed out, the ESP32 OTA is not supported at this time. Answering question #1, you can do an OTA using the Windows Simulator project.

For your question #3, yes, there are 2 different sets of credentials needed for OTA
(1) Device private key/certificate (needed for the TLS communication with AWS IoT)
(2) Code signing credentials (needed to sign and verify the OTA update code)

For the first set of credentials, you should be able to use the same device credentials as you used for the MQTT demo before. You may also create new credentials using your own custom CA (but I would first try with your current credentials that you have already confirmed work with the MQTT publish demo before doing at OTA with your own Custom CA).

For the code signing credentials, you will also need to generate an additional set to sign and verify your OTA image. For Windows Simulator, our code signing services expect a RSA-2048 key and use SHA-256 as the hash.

First, create a document “cert_config.txt”


[ req ]
prompt = no
distinguished_name = my dn

[ my dn ]
commonName = test_signer@youremail.com

[ my_exts ]
keyUsage = digitalSignature
extendedKeyUsage = codeSigning

Next, using OpenSSL, you can call the following to generate your code signing private key and certificate.


openssl req -x509 -config cert_config.txt -extensions my_exts -nodes -days 365 -newkey rsa:2048 -keyout rsasigner.key -out rsasigner.crt

You can either import the key and certificate (rsasigner.key and rsasigner.crt) into ACM directly, or in the job console, under “Code signing certificate” you can select “Import a Certificate” and copy and paste the contents of rsasigner.key and rsasigner.crt into the “Certificate private key” and “Certificate” sections, respectively. You can leave the Certificate chain blank.

–> In the IoT Create OTA Job Console, select the device who’s credentials you’ve already confirmed work.
–> Leave the first radio button on “Sign a new firmware image for me”.
–> In Device hardware platform select “Windows Simulator” and for “Pathname of code signing certificate on device” tell the Windows Simulator project where to find the rsasigner.crt file relative to your solution file. (I like to copy my rsasigner.crt file into the same folder as my aws_demos.sln, and then just type rsasigner.crt in that box!).
----> Regarding question #2, when the device (or Windows Simulator) receives a new firmware image, it must verify that the image came from an authorized source. It uses the code signing certificate path to figure out which public key to use.
–> The pathname of the firmware image on your device is the name of the new Windows executable that will be downloaded. If you provide just a file name (like newImage.exe) then this file will be placed in the same folder as your solution.

Best,
Alexa

system · June 19, 2018, 9:56pm

ahmedwahdan wrote on June 19, 2018:

Thanks Alexa.
I have some more questions:
1- For the MQTT security documentation, it was mentioned that the root certificate should be included in the software to compare with Amazon certificate when I receive it at the beginning of the TLS handshaking, but in the demos the root certificate wasn’t used and only the private key and device certificate, What is really happening here?
2- I read about the TLS and found it’s used for authentication and securely generate symmetric key for communication, is this what’s happening with AWS MQTT?
3- In the OTA demo the software couldn’t complete because there is a NULL values in the firmware JSON file sent from AWS like the following:
https://s8.postimg.cc/a3qs0ezsl/bucket_JSON_file.png
the file path and version are NULL, how to fix this issue?

Thanks

system · June 20, 2018, 1:06am

Alexa-AWS wrote on June 20, 2018:

The root certificates come with the project that you download from the IoT Console or Github so that you do not have to copy them manually into the project. You can check them out in /lib/include/private/aws_default_root_certificates.h
Yes- AWS MQTT creates an AWS Secure Socket, which performs a TLS handshake where communication credentials are agreed upon.
The null filepath is what is causing the problem. It’s ok that the version is null. To fix this, create another OTA job making sure “Pathname of firmware image on device” lists the file name to be given to the new OTA image. (example aws_demos_new.exe)

Let me know if this works!

Edited by: Alexa-AWS on Jun 20, 2018 1:31 PM

system · June 24, 2018, 12:24pm

ahmedwahdan wrote on June 24, 2018:

Hi Alexa,
Thanks a lot for you response.
I succeeded to download the new firmware(using windows demo.)
The issue was the missing file path.
Thanks a lot.

system · June 25, 2018, 4:52pm

Alexa-AWS wrote on June 25, 2018:

Thanks for the update. Glad the OTA was successful!