Mbedtls_ssl_handshake failed in pkcs#1 verification

Dear All
We are using mbedtls ssl_client2 and ssl_server2 examples with cert chain of root,intermediate and device.
Please refer earlier conversation as per below link
My own sample rootCA is failing on handshaking with aws - #8 by roneld01.
We have created a new topic as per earlier request.
We have hard-coded root ca ,intermediate(Server) and device(client) certs and keys in certs.c file.
Please let us know if any additional information is required.

Thanks

Hi @manish_arm
Thank you for posting a new topic.
As questioned in the original topic, What is the “own key” You have set in the client side?
Could you please share logs?
Regards,
Ron

Hi Mr Ron

Thanks a lot for your support.

As per current understanding we have replaced certs and keys in certs.c file.

So we have replace TEST_CLI_KEY_RSA_PEM in certs.c file with RSA private key.

In the client example this points to mbedtls_test_cli_key in mbedtls_pk_parse_key(…) function.

Please correct the understanding if required.

The server and client side logs are at below location valid for one day.
https://drive.google.com/open?id=1Z66Y-vjEuEMm25Y38p1rzvl_ZNZV5m56

Please note these are old logs and the certs are expired now and we have to debug by creating new certs.

Thanks

Manish

(Attachment ARmEmbedLogs.7z is missing)

Hi Manish,
You don’t need to replace the certificates in keys in certs.c. This file holds test certificates used by Mbed TLS.
You should use your own certificates and keys, by parsing them, whether with mbedtls_x509_crt_parse() or with mbedtls_x509_crt_parse_file(). For keys, you should parse with mbedtls_pk_parse_key().
If you are using the sslclient2 example, you can send these as parameters to the example application.
As for the logs, they are not accessible; Please paste the logs as text.
Regards

Hi Mr Ron

Thanks for your feedback.

The logs are again uploaded to below link. Please do confirm they are available and u can download.

For us its downloading from below link

https://drive.google.com/open?id=15N8tQQe1JuxMEThMBILWU9YaY_XHHj2C.

The final cert chain for us will be

DEVICE SIDE: root ca,intermediate1,intermediate2,device cert

SERVER SIDE: root ca,intermediate1,server cert

Please share mbedtls library expectation for device and server cert verification so that we can work accordingly.

Thanks

Manish

Hi Manish,
The root CA should not be sent as part of the certificate chain in the handshake.
It should be set as a trusted certificate using mbedtls_ssl_conf_ca_chain() (or mbedtls_ssl_conf_ca_cb()). From the logs, I understand that you have set two way authentication method, that the server requires client certificate verification. Was this your intention?

The failure is when the server tries to verify the client certificate. It is probably because the public key used for verification is not the pair of the private key that signed the certificate.
Regards

Hi Mr Ron

Sorry for late updates as we are busy in other high priority task.

We have uploaded working logs at below location.(
ToMbedtlsforum.7z)

https://drive.google.com/open?id=1qUfXV4z8H6SbnHJZMn9LF8juE4ma_L42

Request to please confirm the same at your end once.

The last error was “MBEDTLS_X509_BADCERT_EXT_KEY_USAGE” for device cert verification.

We changed device cert without extension and found apps are working fine.

In future we will update only the extension key usage field in device cert and maintain the extension.

We are passing root ca cert as chain of cert(intermediate/root) in client and server side test app.

Please do suggest your views and close the call if required.

Thanks for your cooperation.

Thanks

Manish

Hi @manish_arm

MBEDTLS_X509_BADCERT_EXT_KEY_USAGE is returned when the call for [mbedtls_x509_crt_check_extended_key_usage()] (mbedtls/ssl_tls.c at development · Mbed-TLS/mbedtls · GitHub). THis function fails, if the extended key usage doesn’t have the ANY usage, or MBEDTLS_OID_SERVER_AUTH for server, and MBEDTLS_OID_CLIEWNT_AUTH for client. (Inn case this extension exists)
In your working logs, I don’t see any extended key usage extension. However, t seems that the server certificate being sent is actually the intermediate certificate.
Please verify you have setr the correct server certificate, and that it has the correct extended jey usage extension.
Regards

Hi Mr Ron

As shared earlier we are using cert chain as RootCA,intermediate(server certificate) and device cert.

The intermediate certificate serve as server cert and it is correct.

The device cert was having below details when error “ MBEDTLS_X509_BADCERT_EXT_KEY_USAGE” was reported.

X509v3 Extended Key Usage:

TLS Web Server Authentication

We will check once again by updating above field with appropriate flag and check.

Once again thanks for your cooperation.

Thanks

Manish

Hi @manish_arm
The server certificate should not be an intermediate certificate.
It should not have a CA: true basic constraint.
In addition, it should b=not be the parent of the device certificate ( as it seems this is hte case here)

The device certificate in your working logs doesn’t have this extension, but if your failed case has the “TLS Web Server Authentication” extended key usage, then this is the reason for failure. It should wither have the MBEDTLS_OID_CLIENT_AUTH extended key usage, or the MBEDTLS_OID_ANY_EXTENDED_KEY_USAGE

Regards