Hello NXP Support Team,
I am following up on a similar issue raised in a previous thread: https://community.nxp.com/t5/Secure-Authentication/OpenSSL-doesn-t-handle-refpem-key-correctly-nxp-s...
In that ticket, @Kan_Li clarified to @tksec that the .refpem key format is primarily usable for the legacy OpenSSL engine. However, the questions regarding OpenSSL 3.0 Provider integration with Node.js remained unresolved.
We are developing on an iWave board utilizing the #SE051 Secure Element. We are attempting to establish an mTLS (Client Authentication) connection using a Node.js application and the modern OpenSSL Provider.
Our Environment:
Secure Element: SE051 variant C
Middleware / SDK: Plug & Trust MW v4.7.1
Hardware Protocol: Version 7 (SCP03 Enabled)
Node.js Version: v16.11.1
OpenSSL Version: 3.0.x
Because OpenSSL 3.0 has deprecated Engines, we are required to use the modern se05x OpenSSL Provider (libsssProvider.so) instead of the legacy e_sss engine.
The Core Issue: As @tksec pointed out in the previous thread, Node.js applications use functions like PEM_read_bio_PrivateKey which strictly expect a standard PEM-formatted string/buffer.
The modern OpenSSL 3.0 sssProvider requires the key to be passed as a Direct Provider URI (e.g., "nxp:0x7D000002" or "nxp:/path/to/tls_client_key_ref.pem").
When we attempt to pass this URI into the Node.js https.Agent, the application crashes before the TLS handshake even begins:
const https = require('https');
const agent = new https.Agent({
cert: fs.readFileSync('device_cert.pem'),
key: "nxp:0x7D000002", // Fails: Node.js expects a raw PEM buffer here
rejectUnauthorized: true
});
// Error: ERR_OSSL_PEM_NO_START_LINE
Node.js validates the key parameter before handing it to OpenSSL. Because "nxp:" lacks a -----BEGIN PRIVATE KEY----- header, it aborts immediately.
Our Questions:
Will updating Node.js (e.g., to v18/v20, which natively integrates OpenSSL 3.0) inherently solve this URI parsing issue, or does the Node TLS layer still reject Provider URIs?
Does the NXP provider need to be modified to fix this? Are there any plans or existing solutions to improve the provider code so it can parse legacy .refpem files directly? Allowing high-level languages like Node.js to pass a dummy PEM buffer would completely bypass the URI crashing issue.
Thank you for your time and guidance.
