OPC Client DA/UA can’t connect to node-red-contrib-opcua server

Anybody can connect Factory I/O to Node-RED embedded server of node-red-contrib-opcua 0.2.89?
Since the version 2.4.5, the situation with my problem to connect to node-opcua server has improved: Factory I/O connects to a stand alone server like a charm :wink:
For my tests I’m using the very simple server shared by @brunovgr in problem “Node-opcua server”.

My problem is that Factory I/O doesn’t want to connect to the embedded server (node OpcUa-Server) of node-red-contrib-opcua 0.2.89.
I get exactly the same message than in my previous problem 28 days ago with a standalone server:

> Server did not return an endpointdescription that matched the one used to create the secure channel

However, I can connect to the Node-RED embedded server with the stand alone node-opcua-sample client
=> this is the reason why I think Factory I/O OPC Client DA/UA driver has still a problem
Screenshot 2020-11-17 094411 fio|690x353

Thanks for your help!

@mommeja I believe it’s a certificate related problem. I’m unable to connect to recent versions of node-opcua with any other opc ua client (even by changing certificates between server and client). I tried several opc ua clients such as Prosys, Softing, etc, but without success. The included node-opcua-sample client is the only one that works.

Maybe you could submit an issue to the node-opcua team: https://github.com/node-opcua/node-opcua/issues

@brunovgr I suspect a certificate problem too, for the following reason:
I have at least one OPC-UA client (other than node-opcua clients) that works with node-opcua: Unified Automation UAExpert.
The first time I’m connecting this client to node-opcua (the one embedded in Node-RED), UAExpert is asking me to trust the server certificate (see screen capture attached). Once I explicitly trust it, UAExpert is putting the certificate into its own trusted certificate store, and then it works well.
So at this time, I am trying to follow Factory I/O OPC UA Certificates and User Identity documentation to reproduce the same logic than with UAExpert.

@brunovgr it’s actually not a problem with certificates.
Strangely, when Factory I/O requests a session creation to the opc ua server, it passes it’s endpoint url with lower case letters.
This results into a url mismatch if the endpoint url is actually not in lower case. In this situation the session creation request is rejected.
About wether or not a url is case sensitive, the w3c states:

URLs in general are case-sensitive (with the exception of machine names). There may be URLs, or parts of URLs, where case doesn’t matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive.

I believe Factory I/O should avoid transforming the endpoint url.
Do you know where I can create an issue?

@mommeja Can you tell me the steps you followed to identify this problem? I don’t see any problem in the OPC UA code, maybe the problem resides in the middleware we are using.

@brunovgr I added a trace point in the server code when the request is coming from the client.
Look at line 1560 here https://github.com/node-opcua/node-opcua/blob/master/packages/node-opcua-server/source/opcua_server.ts
Using contrib node-red-contrib-opcua, I actually added a trace point to the generated .js code in .node-red\node_modules\node-opcua-server\dist\opcua-server.js
My test endpoint is: opc.tcp://LAPTOP-J7AHFDQH:53880

Trace when UA Expert connects to my server:

    "requestHeader": {
        "authenticationToken": "ns=0;b=c6474ce444911d34fad3b32a6a6d8147",
        "timestamp": "2020-11-19T18:30:10.251Z",
        "requestHandle": 1001426,
        "returnDiagnostics": 0,
        "timeoutHint": 10000
    "clientDescription": {
        "applicationUri": "urn:LAPTOP-J7AHFDQH:UnifiedAutomation:UaExpert",
        "productUri": "urn:UnifiedAutomation:UaExpert",
        "applicationName": {
            "text": "Unified Automation UaExpert"
        "applicationType": "Client",
        "discoveryUrls": []
    "endpointUrl": "opc.tcp://LAPTOP-J7AHFDQH:53880",
    "sessionName": "urn:LAPTOP-J7AHFDQH:UnifiedAutomation:UaExpert",
    "requestedSessionTimeout": 1200000,
    "maxResponseMessageSize": 67108864

Trace when Factory I/O connects to my server:

“requestHeader”: {
“authenticationToken”: “ns=0;i=0”,
“timestamp”: “2020-11-19T18:30:12.118Z”,
“requestHandle”: 1,
“returnDiagnostics”: 0,
“timeoutHint”: 0
“clientDescription”: {
“applicationUri”: “urn:LAPTOP-J7AHFDQH:Factory IO”,
“productUri”: “urn:company:product”,
“applicationName”: {
“text”: “Factory IO”
“applicationType”: “Client”,
“discoveryUrls”: []
“serverUri”: “urn:NodeOPCUA-Server-default”,
“endpointUrl”: “opc.tcp://laptop-j7ahfdqh:53880/”,
“sessionName”: “OPC UA Driver”,
“clientNonce”: “WtJbuD6CdvlNxVaxCvAAcmPdCrKWjS8Uays4J67uD7w=”,
“requestedSessionTimeout”: 60000,
“maxResponseMessageSize”: 10485760

If you want to do a WebEx, or call me, please send a mail to mommeja@fr.ibm.com

@mommeja Thanks for your valuable feedback and for being so helpful.

I don’t think the problem is related to letter case. My point is, all OPC clients I test against the sample server (node_modules\node-opcua-samples\bin>node simple_server.js) report this error message.

We are currently investigating this issue and once we have something to share I’ll post it here.

1 Like

I advise you to test with the OPC-UA server (OpcUa-Server) embedded in Node-RED (node-red-contrib-opcua). It’s a real server.

My tests:
OpcUa-Client > OpcUa-Server ok
node-opcua-sample/simple_client.js > OpcUa-Server ok
UAExpert OPC UA Client > OpcUa-Server ok
ProSys OPCUA Browser > OpcUa-Server ok
Factory I/O OPC UA/DA > OpcUa-Server ko

Factory I/O OPC UA/DA > node-opcua-sample/sample_server.js ok
ProSys OPCUA Browser > node-opcua-sample/sample_server.js ok
UAExpert OPC UA Client > node-opcua-sample/sample_server.js ok

@mommeja I have just received feedback from our middleware provider and you are absolutely correct. The toolkit we use in our OPC UA driver is making the Uri lower case and terminating it with the ‘/’ character, which is not accepted by the server.

We are working on a preview release which will include several fixes, including this one. We are doing our best to release it as soon as possible.

1 Like

@mommeja We have just released Factory I/O v2.4.6 (Preview 2) which includes a fix addressing this issue. You can find it here: Factory I/O v2.4.6 preview 2 available

1 Like

Bruno excellent! We will download it.