Using SE051 OpenSSL 3.0 Provider with Node.js / Passing URIs vs Reference PEMs (Follow-up to Ticket

AbhijeetG_1215 — Fri, 15 May 2026 14:03:13 GMT

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-scheme-is/m-p/1866179

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:

JavaScript

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.

Re: Using SE051 OpenSSL 3.0 Provider with Node.js / Passing URIs vs Reference PEMs (Follow-up to Tic

tksec — Mon, 18 May 2026 13:30:23 GMT

Just looking at the release note/changelog of v20 node.js still doesn't support OpenSSL 3.0 providers. They now just make it clear in the documentation, that they rely on the engine concept (https://github.com/nodejs/node/pull/53329/changes).

Back then I ended up patching node.js to support key ids. Mainly by using the OSSL_STORE API (https://docs.openssl.org/3.0/man7/ossl_store/) instead of the PEM function in https://github.com/nodejs/node/blob/3b19867caaef6b85c65e44dc60274dce2b240d22/src/crypto/crypto_context.cc#L1699. This allowed for loading any key type.
Of course some adaptions were needed as well in the callers and config structs to match data types, etc.

topic Re: Using SE051 OpenSSL 3.0 Provider with Node.js / Passing URIs vs Reference PEMs (Follow-up to Tic in Smart Cards and Secure Element

Using SE051 OpenSSL 3.0 Provider with Node.js / Passing URIs vs Reference PEMs (Follow-up to Ticket

Re: Using SE051 OpenSSL 3.0 Provider with Node.js / Passing URIs vs Reference PEMs (Follow-up to Tic