- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2396714_en-US
2396714_en-US
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2396714_en-US
2396714_en-US
Can the provisioned certificate and private key on the i.MX93 be used directly to establish HTTPS/TLS connections? If yes, what is the recommended method for accessing and utilizing these credentials for client/server authentication and mTLS implementations?
once provisioning is complete and the secure object blobs are present in /etc/ele/, what is the recommended workflow for using those provisioned credentials in a real HTTPS/TLS connection?
Hi ,@Manuel_Salas
Thanks for your reply.
Following up on the mbedTLS/opaque-key guidance — that's resolved on our side for the private key.
Remaining question is specifically about the certificate, provisioned via EL2GO and stored in /etc/ele/ alongside the private key . Since a certificate is public data, we need to extract it as plain DER to hand to mbedtls_x509_crt_parse_der() for the TLS handshake — unlike the key, it doesn't need to stay opaque.
What is the supported SMW/PSA call to retrieve the plaintext DER bytes for a provisioned certificate object?
Specifically: is it exposed via psa_ps_get() / psa_its_get() (PSA Protected Storage / Internal Trusted Storage) using the object ID as the UID, or through a different SMW API? We see protected_storage.h and internal_trusted_storage.h in the installed SMW headers but want to confirm this is the intended path for certificate objects before building against it.
Hello @NEXUSNERD
Hope you are doing very well.
On the i.MX93, the provisioning flow is designed so that the private key remains protected by the ELE.
So, the blobs stored in /etc/ele/ are secure object representations that allow ELE to reload or reference the provisioned key material, and they are not intended to be treated as ordinary TLS key files.
You can take a look to the imx-secure-enclave (Mbed-TLS).
Best regards,
Salas.