Generate certs in production

[wegunterjr]

I am looking to do hundreds/thousands of devices, but not sure how to do this?

I have seen a post that shows it is possible:
"It is also possible for the ESP32 to generate its own client private key and certificate and then as part of provisioning it sends a signing request to a server located in your factory, which signs with your CA's key. We don't have an example for this at the moment though, and it's quite a complicated undertaking and easy to mess up."

I have the AWS cert and i have the company cert, but right now I have to manually do openssl commands then load the generated cert into the ESP32 for compiling. That isn't going to be helpful in production.

Suggestions?

[chegewara]

https://docs.aws.amazon.com/iot/latest/ ... oning.html
https://aws.amazon.com/blogs/iot/settin ... -iot-core/

[wegunterjr]

Excellent - i even searched for some information in AWS, but must have been looking in the wrong place.

OK. now, i see there is AWS setup to do - is there anything special we need to do in the ESP32 to allow this?
I plan to put in two certs (in a certs folder) - but they won't be the generated certs like using openssl (as I am doing manually now)

[wegunterjr]

ah..i was confused not JITP, JITR. different thing:


https://github.com/aws-samples/aws-iot- ... op.md#JITR

I need help with JITR

[ESP_Angus]

There are a few ways you could do this. The best option will depend on how your factory manufacturing and test process is going to work. Unfortunately we don't have ready to roll out examples of any of this, at the moment you'll have to assemble some parts on your own. We are in the planning stages of producing end-to-end examples and tools for manufacturing flows, but no ETA for this.

It sounds like you are currently embedding device keypairs into the firmware (this is the simplest way, and it's the default configuration for the AWS example projects). You probably don't want to do this for production, instead you can move the certificate and key files to "blobs" in the NVS storage partition or files on an embedded filesystem partition like SPIFFS or read-only FATFS. This way each device can have the same firmware binary but a different device key and certificate pair. The IDF AWS examples have some config items which can be configured to pick up the certificates from a filesystem.

So you have a bundle of key/certificate pairs signed by your Amazon trusted CA. How to get the certificates into the devices? There are a few options for this part:

• Include them in the initial factory flash. The best supported way to do this is to use the Manufacturing Utility to create individual per-device NVS partitions (ie each partition can have a different certificate.) Alternatively you could generate SPIFFS or read-only FATFS partitions with the correct contents. The downside to this approach is that at the factory each device needs to get a different flash payload - this rules out using some bulk SPI flash flashers, for example.
• Include them in the end-of-line test. Your product probably has some kind of end-of-line test done at the factory, where you make sure all the functionality is working correctly. Does this include a Wi-Fi test where the device connects to a local AP that you supply to the factory? If so, you can have a test firmware binary which runs any other device self-tests, connects to the AP, downloads the per-device payload from the AP, stores it in flash. Then resets into the "product" factory firmware (either OTA updated downloaded from the AP as well, or pre-flashed to another partition) and finally the factory firmware erases the test partition. The main downside is that you need a piece of software on each in-factory AP to manage this (many factories do not have good internet access, so you want any test AP to be self-contained in most cases).
• Provision in the initial setup process. If your device has an app or something else which is used to do initial setup (let the user enter their initial Wi-Fi app details,for example) then you could have the app quietly send the key and certificate to the device at this point. This is not a good security option, because you have to trust both the app and the device (which has no way to prove its identity to the app without a key/certificate pair), but you could (for example) authorise the user in the app and then have the server send the data to the app, as associated with that user. Don't recommend this way, but it is possible to do it.

Sorry there any "out of the box" solutions for this at the moment.

[guillep2k]

Regarding the third option, you could have a dedicated web server with https that takes a one time device request for signature of its own certificate; you could validate the server's certificate easily from the device side, while providing some fixed setup-use-only client-certificate to the server as a proof of identity (all devices can have the same certificate for that operation). The web server would be quite low traffic. It's not great, but it's a little bit better.