[Azure RTOS Thread X version 6.1.9] _nx_secure_x509_pkcs1_rsa_private_key_parse returns NX_SECURE_PKCS1_INVALID_PRIVATE_KEY error

Question

I am using an STM32H735 board with Azure RTOS (ThreadX version 6.1.9). I am trying to connect the board to an Azure IoT Hub Device configured with x.509 self-signed authentication type.

I have created the X.509 self-signed certificate using openssl and listed the commands below:

** generate a 2048-bit RSA private key **

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048

** create a Certificate Signing Request (CSR) **

openssl req -new -key private_key.pem -out request.csr

** generate the X.509 Certificate valid for 100 years **

openssl x509 -req -in request.csr -signkey private_key.pem -out certificate.pem -days 36500

** verify the Certificate **

openssl x509 -in certificate.pem -text -noout

** make sure the private key is in pkcs-1 format **

openssl rsa -in private_key.pem -traditional -out private_key_pkcs1.pem

** convert private key and certificate to DER

openssl x509 -outform der -in certificate.pem -out certificate.der

openssl rsa -outform der -in private_key_pkcs1.pem -out private_key_pkcs1.der

** verify the DER certificate **

openssl x509 -in certificate.der -inform der -text -noout

openssl rsa -in private_key_pkcs1.der -inform der -text -noout

I then converted the file into a byte array so it can be loaded integrated into the firmware.

I observe that when _nxd_mqtt_client_secure_connect (nxd_mqtt_client.c) calls _nx_secure_x509_certificate_initialize (nx_secure_x509_certificate_initiatlize.c), a function within it (_nx_secure_x509_pkcs1_rsa_private_key_parse, nx_secure_x509_pkcs1_rsa_private_key_parse.c) returns NX_SECURE_PKCS1_INVALID_PRIVATE_KEY.

The specific location on the source code that returns this error is shown below:
if (tlv_type != NX_SECURE_ASN_TAG_INTEGER || tlv_type_class != NX_SECURE_ASN_TAG_CLASS_UNIVERSAL)

{

    return(NX_SECURE_PKCS1_INVALID_PRIVATE_KEY);

}

The reason for this is that the tlv_type is 16 while the code is expecting a value of 2 (NX_SECURE_ASN_TAG_INTEGER ).

Is there a step I am missing in my private key generation process that can make sure that thetlv_type will be 2 instead of 16?

Answer 1

I have resolved the problem.

This step is not required:
** make sure the private key is in pkcs-1 format **

openssl rsa -in private_key.pem -traditional -out private_key_pkcs1.pem

What is actually required is to add -traditional when converting the .pem to .der:
openssl rsa -outform der -in private_key_pkcs1.pem -traditional -out private_key_pkcs1.der

Answer 2

setenforce gcc -o log_reader your_code_file.c -lmlibrary

dd if=/path/to/inputfile of=/path/to/outputfile bs=512 count=1

#include <mlibrary.h>

readLogs() {

    MLibrarySDK sdk;

    sdk.initialize();

    sdk.readLogcat(); // Custom function to read logs

    sdk.cleanup();

}

dd if=C:\path\to\inputfile of=C:\path\to\outputfile bs=512 count=1

06-14 20:13:54.782 30255 30255 V Resources Manager: The following library key has been added: Resourceskey { mHash=e0576fcc mResDir=null msplit Dir s=[] moverlayDirs=[/product/overlay/Navi gati onBar Mode3Button/NavigationB ar Mode 3ButtonOverlay. apk, /product/overlay/IconShapeTeardrop/IconShape Tea rdropOverlay. apk, /product/overlay/Font Rooker yRegul ar/Font Rooker y Regul ar O verlay. apk,/data/resource-cache/com androi d. systemul neutralFDv8. frro,/data/resource-cache/com android. systemui accent-4j Gl.frro,/data/resource -cache/com androi d. systemui dynamic-AFns.frro] mLibDirs=[/data/app/~~CWB 1FsZ28UI Mt_Eo2f Boww==/com.google.androi d. webvi ew- ESMz OUbws] TGocy7W CI Pg= /base, apk,/data/app/~~aBs P8HRDPOEPYqZEUIf_ZA==/com google. android. trich romelibrary.71 51 061 33-nC94v5JJ1gvTzms-3mKdMQ==/base. apk, /system ext/fram ework/androi dx. window. extensions.jar] mbi spl ayl d = 0 mOverride Config=v35 m Compatinfo={400dpi al ways-compat) mLoaders=[]]

Answer 3

20799a27 : 0, xxxx : 6279, xxxx : 6279, xxxx : 6279, xxxxxxxx4180 : 0

Your search - 20799a27-xxxx-XXXX-XXXX-XXXXXXxx4180 - did not match any documents.

Suggestions:

Make sure all words are spelled correctly.

Try different keywords.

Try the extended search mode. DNS had no answers for United States of America.