AWS IoT using own Certificate. or procedure for bulk production

[Trialblazer47]

Hi,

I am currently trying to use my own CA certificate and device certificate https://github.com/espressif/esp-idf/issues/1350
but I am not able to. I am using publish_subscribe and it works with the AWS IoT generated Certs. I followed all steps show on AWS documentation and my certificates and CA is registered on AWS IoT I can see on console and also attached thing and policy but It fails as show in above github issues .. can any one help me give me exact steps

also how should I go with production process for this?

I really need to understand we are using ESP32 as hub for ble devices we have.

[ESP_Angus]

I've closed the issue on Github as I think this is better answered as a discussion question. For future reference, please don't ask the same question simultaenously in multiple places at once - it can be confusing for us.

E (4192) subpub: Error(-4) connecting to aofdwnij85jbh.iot.ap-southeast-1.amazonaws.com:8883
E (6402) aws_iot: failed! mbedtls_ssl_handshake returned -0x2700
E (6402) aws_iot: Unable to verify the server's certificate.

The TLS connection to AWS has to be verified in two ways:

• The client (ESP32) has to securely identify (aka verify) the server. This verification indicates that it's not talking to some third party server, Man-In-The-Middle attack, etc. The "aws-root-ca.pem" is the certificate used for this - this cert represents the "root of trust" for all AWS IoT servers' certificates.
• The server (AWS) has to securely identify (aka verify) the client. This verification is so AWS IoT knows that this is you and not some random person pretending to be you. For this, AWS IoT uses a per-device "TLS client certificate" with a matching private key. These are the certificates you can either have AWS generate and then you download from them, or you can try the alternativel approach you are using now: generate your own keys, sign them with your own CA, and have that CA trusted by AWS IoT.

The failure you have is from the first step - the ESP32 client can't verify (securely identify) the server. The reason looks to be that you've substituted the aws-root-cert.pem for your own CA's root cert. This won't work, the server you are talking to is still AWS not your own server (The AWS server couldn't identify itself with your CA's custom root cert unless it also had your CA's private key, and you wouldn't want that!)

Try swapping the root cert back to aws-root-ca.pem, but still supply your own client certificate & client private key for the client part of the connection. The ESP32 will be able to identify AWS and connect. Whether or not the connection is then accepted by Amazon (the second item on the list above) will depend on whether you've successfuly registered your CA Cert so it's trusted by AWS IoT, and also used your CA's key to sign your ESP32's client certificate. (These are the steps described by Amazon at the link you're using.)

Hope that makes sense.

[ESP_Angus]

also how should I go with production process for this?

This depends on a lot of individual factors - production size, degree of automation, specific factory/site/market-level security concerns, etc. Most likely you'll want to pre-generate private keys and certificates for each individual device, and have them flashed by the factory as part of firmware installation (probably with a script).

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.

Pre-generating all the keys & certificates on a host PC and then flashing them individually is much simpler and should scale, unless your production run is huge.

(The other in-between option is something like: flash the same firmware to all devices, but have them run a one-off factory firmware which connects to a trusted server - probably in the factory - and downloads their individual key & certificate to save on an internal filesystem or data partition, and then OTA updates itself to the "real" firmware.)

[Trialblazer47]

Try swapping the root cert back to aws-root-ca.pem, but still supply your own client certificate & client private key for the client part of the connection.

as they device cert will not be made with aws-root-ca.pem so are you sure it should work? as they are saying that deviceCert should be made with same rootCa.pem .

I used old aws-root-ca.pem with deviceCert.crt and deviceCert.key and it did not work, I get:

Code: Select all

I (1462) wifi: connected with UNICORN, channel 1
I (2182) event: ip: 192.168.XXX.XXX, mask: 255.255.255.0, gw: 192.168.1.1
I (2182) subpub: Connecting to AWS...
E (3242) aws_iot: failed! mbedtls_ssl_handshake returned -0x2700
E (3242) aws_iot:     Unable to verify the server's certificate. 
E (3252) subpub: Error(-4) connecting to aofdwnij85jbh.iot.ap-southeast-1.amazonaws.com:8883
E (5182) aws_iot: failed! mbedtls_ssl_handshake returned -0x2700

[ESP_Angus]

as they device cert will not be made with aws-root-ca.pem so are you sure it should work? as they are saying that deviceCert should be made with same rootCa.pem .

I am quite sure. There are two different CAs involved here: your custom CA is used to verify the device certificate. AWS's CA (VeriSign) is used to verify AWS itself. TLS and public key infrastructure is quite complex, and it can take some time to get your head around it. I tried to explain it as best I could in the first reply, I'm happy to explain any particular individual point if that helps.

It's possible to verify the aws-root-ca.pem is correct for the client to verify the server by using the openssl command line:

Code: Select all

 openssl s_client -CAfile main/certs/aws-root-ca.pem -connect aofdwnij85jbh.iot.ap-southeast-1.amazonaws.com:8883

This will connect to your AWS IoT endpoint, using the aws-root-ca.pem as our CA file to verify that it's the correct connection. You'll see a lot of output including a line like "Verify return code: 0 (ok)". This indicates that openssl is happy with the server's identity as specified. However then the server will immediately close the connection (because openssl hasn't provided any TLS client certificate, ie the device certificate you generated for the device, so the server isn't able to identify/verify the client.)

I used old aws-root-ca.pem with deviceCert.crt and deviceCert.key and it did not work, I get:

Code: Select all

I (1462) wifi: connected with UNICORN, channel 1
I (2182) event: ip: 192.168.XXX.XXX, mask: 255.255.255.0, gw: 192.168.1.1
I (2182) subpub: Connecting to AWS...
E (3242) aws_iot: failed! mbedtls_ssl_handshake returned -0x2700
E (3242) aws_iot:     Unable to verify the server's certificate. 
E (3252) subpub: Error(-4) connecting to aofdwnij85jbh.iot.ap-southeast-1.amazonaws.com:8883
E (5182) aws_iot: failed! mbedtls_ssl_handshake returned -0x2700

I can't explain this. Does the same file work with "openssl s_client" as given above?

[Trialblazer47]

Ya I was attaching CA certificate that I was creating while it required AWS provided CA cert on ESP32.
Worked after putting AWS provided certificate as discused here
https://github.com/aws/aws-iot-device-s ... issues/114

There were also confusions with file names and extensions which are clear now.

Sorry for any troubles yes it is a bit confusing involving 3 certificates Any ways now I get it better. CA certificate is required but AWS and AWS certificate is required by device, CA certificate is also used to generate device Certificate and key. so device Cert, device key and Aws Cert is required by device to make connection.
Thanks.

[ESP_Angus]

CA certificate is required but AWS and AWS certificate is required by device, CA certificate is also used to generate device Certificate and key. so device Cert, device key and Aws Cert is required by device to make connection.

You've got it now. Glad everything is working.

[barato0306]

I just want to say thank you for the detailed explanation.