- Newest
- Most votes
- Most comments
I've noticed that if I don't add the signerCA to the chain when connection mbedTLS, the handshake is still successful but I get the same behaviour: AWS closes the connection and do not register any certificate. In this case this is expected because the signerCA cannot be identified.
That looks like mbedTLS/cryptoauthlib does something wrong when connecting (I use atca_mbedtls_cert_add(&device_cert_chain, &g_cert_def_1_signer)) to add the signerCA to the chain).
I've continued to explore the issue and can confirm that:
A) a similar certificate (same x509v3 extensions, same naming scheme) sent by mosquitto_pub triggers the JITP process while my device certificates does not. After inspecting the TLS handshake with Wireshark, both send the two certificates (signerCA and end-device cert). Both have a succesful handshake, both receive a close notify message but only the mosquitt_pub one triggers the provisioning proces. This should validate that the JITP configuration (signerCA+policy) is correct.
B) If I manually import the device certificate in the AWS console, attach a policy and a thing to it, the code is able to publish a message in a topic. This should validate that the TLS connection is correct and the ATECC chip works well.
I don't know why the device cert chain does not trigger JITP. I've checked the TLS handshake in Wireshark and cannot see what is different between the two sessions.
Edited by: fstephany on Jan 18, 2021 9:08 AM (formatting)
Edited by: fstephany on Jan 18, 2021 9:18 AM (formatting)
Found the issue !
The problem was the AuthorityKeyIdentifier (which is 20 bytes in the middle of the cert) in the signerCA that was wrong. It is populated at runtime by the atecc. I'll double check my provisioning scripts to ensure that the signer cert def and template regenerate the right CA out of the box.
Relevant content
- asked 3 years ago
- asked 9 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 7 months ago