espressif/esp-azure

mbedtls problem when trying to register with Azure Device Provisioning Service (IDFGH-2726) (CA-62)

Closed this issue · 2 comments

afcec commented

Environment
IDF Version: v4.1-dev-2246-gb942327a2
Build System: Cmake
Operating System: Windows
Power Supply: USB
Problem
After experiencing some problems with my application when I was trying to register with Azure Device Provisioning Service I decided to simplify the scenario and just executed example "prov_dev_client_II_sample". I am using self-signed certificates with OpenSSL and have created certificates for the CA, intermediates and devices. The CA and intermediate certificates have successfully been uploaded and verified in Azure and I have registered some devices using a Java client (which indicates DPS configuration and certificates being used are correct). However, when using ESP-IDF I am always receiving an error during handshake. Please see below the log with debug activated for mbedtls:

`
Provisioning API Version: 1.2.14
Iothub API Version: 1.2.14
I (28216) mbedtls: ssl_tls.c:8088 => handshake

I (28216) mbedtls: ssl_cli.c:3510 client state: 0

I (28216) mbedtls: ssl_tls.c:2755 => flush output

I (28226) mbedtls: ssl_tls.c:2767 <= flush output

I (28226) mbedtls: ssl_cli.c:3510 client state: 1

I (28236) mbedtls: ssl_tls.c:2755 => flush output

I (28236) mbedtls: ssl_tls.c:2767 <= flush output

I (28246) mbedtls: ssl_cli.c:774 => write client hello

I (28256) mbedtls: ssl_tls.c:3184 => write handshake message

I (28256) mbedtls: ssl_tls.c:3343 => write record

I (28266) mbedtls: ssl_tls.c:2755 => flush output

I (28266) mbedtls: ssl_tls.c:2774 message length: 326, out_left: 326

I (28276) mbedtls: ssl_tls.c:2779 ssl->f_send() returned 326 (-0xfffffeba)

I (28286) mbedtls: ssl_tls.c:2807 <= flush output

I (28286) mbedtls: ssl_tls.c:3476 <= write record

I (28296) mbedtls: ssl_tls.c:3320 <= write handshake message

I (28306) mbedtls: ssl_cli.c:1106 <= write client hello

I (28306) mbedtls: ssl_cli.c:3510 client state: 2

I (28316) mbedtls: ssl_tls.c:2755 => flush output

I (28316) mbedtls: ssl_tls.c:2767 <= flush output

I (28326) mbedtls: ssl_cli.c:1499 => parse server hello

I (28336) mbedtls: ssl_tls.c:4311 => read record

I (28336) mbedtls: ssl_tls.c:2536 => fetch input

I (28346) mbedtls: ssl_tls.c:2697 in_left: 0, nb_want: 5

I (28346) mbedtls: ssl_tls.c:2721 in_left: 0, nb_want: 5

I (28356) mbedtls: ssl_tls.c:8098 <= handshake

I (28366) mbedtls: ssl_tls.c:8088 => handshake

I (28366) mbedtls: ssl_cli.c:3510 client state: 2

I (28366) mbedtls: ssl_tls.c:2755 => flush output

I (28376) mbedtls: ssl_tls.c:2767 <= flush output

I (28386) mbedtls: ssl_cli.c:1499 => parse server hello

I (28386) mbedtls: ssl_tls.c:4311 => read record

I (28396) mbedtls: ssl_tls.c:2536 => fetch input

I (28396) mbedtls: ssl_tls.c:2697 in_left: 0, nb_want: 5

I (28406) mbedtls: ssl_tls.c:2721 in_left: 0, nb_want: 5

I (28406) mbedtls: ssl_tls.c:8098 <= handshake

I (28426) mbedtls: ssl_tls.c:8088 => handshake

I (28426) mbedtls: ssl_cli.c:3510 client state: 2

I (28426) mbedtls: ssl_tls.c:2755 => flush output

I (28436) mbedtls: ssl_tls.c:2767 <= flush output

I (28436) mbedtls: ssl_cli.c:1499 => parse server hello

I (28446) mbedtls: ssl_tls.c:4311 => read record

I (28446) mbedtls: ssl_tls.c:2536 => fetch input

I (28456) mbedtls: ssl_tls.c:2697 in_left: 0, nb_want: 5

I (28466) mbedtls: ssl_tls.c:2721 in_left: 0, nb_want: 5

I (28466) mbedtls: ssl_tls.c:2722 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)

I (28476) mbedtls: ssl_tls.c:2742 <= fetch input

I (28486) mbedtls: ssl_tls.c:2536 => fetch input

I (28486) mbedtls: ssl_tls.c:2697 in_left: 5, nb_want: 3996

I (28496) mbedtls: ssl_tls.c:2721 in_left: 5, nb_want: 3996

I (28496) mbedtls: ssl_tls.c:2722 ssl->f_recv(_timeout)() returned 3991 (-0xfffff069)

I (28506) mbedtls: ssl_tls.c:2742 <= fetch input

I (28546) mbedtls: ssl_tls.c:4385 <= read record

I (28546) mbedtls: ssl_cli.c:1789 server hello, total extension length: 9

I (28546) mbedtls: ssl_cli.c:1978 <= parse server hello

I (28556) mbedtls: ssl_cli.c:3510 client state: 3

I (28566) mbedtls: ssl_tls.c:2755 => flush output

I (28566) mbedtls: ssl_tls.c:2767 <= flush output

I (28576) mbedtls: ssl_tls.c:5655 => parse certificate

I (28576) mbedtls: ssl_tls.c:4311 => read record

I (28616) mbedtls: ssl_tls.c:4385 <= read record

W (28726) mbedtls: ssl_tls.c:5761 x509_verify_cert() returned -9984 (-0x2700)

I (28726) mbedtls: ssl_tls.c:5250 => send alert message

I (28726) mbedtls: ssl_tls.c:3343 => write record

I (28726) mbedtls: ssl_tls.c:2755 => flush output

I (28736) mbedtls: ssl_tls.c:2774 message length: 7, out_left: 7

I (28746) mbedtls: ssl_tls.c:2779 ssl->f_send() returned 7 (-0xfffffff9)

I (28746) mbedtls: ssl_tls.c:2807 <= flush output

I (28756) mbedtls: ssl_tls.c:3476 <= write record

I (28766) mbedtls: ssl_tls.c:5263 <= send alert message

I (28766) mbedtls: ssl_tls.c:5867 <= parse certificate

I (28776) mbedtls: ssl_tls.c:8098 <= handshake

E (28776) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x2700
I (28786) esp-tls-mbedtls: Failed to verify peer certificate!
I (28796) esp-tls-mbedtls: verification info: ! The certificate is not correctly signed by the trusted CA
`
After some initial tests I have replaced th existing certificates from esp-azure/azure-iot-sdk-c/certs/certs.c with my CA and intermediate certificates with no luck.

Is there anything else I should do? What am I missing?

Thanks

@afcec , sorry for the (very) late reply. Have you followed all steps in the example README. I just tried this out today and it worked for me. I even tried self-signed certificates (primary and secondary, with same Common Name, and that same name used as the device id in the example configuration)

Hi @afcec,

thank you for reporting this issue. We are trying to keep our backlog manageable and because of that we are closing this issue. There is suggested workaround by @shahpiyushv and issue is stale at this point. If you disagree with this decision, please let me know and we will reopen the issue.

Thank you,

Tomas