XLReporter Connection to Ignition OPC-UA Server

We’re migrating an XLReporter project from an RSLinx connector to an Ignition OPC-UA Server and having some issues getting things talking. XLReporter is installed on the same OS as the Gateway (Ignition 8).

In XLReporter I can successfully discover the OPC-UA server using the port: 62541/discovery. We’re using the default credentials of opcuauser/password.

When testing the connection we’re getting a simple error in XLReporter: Error establishing a connection. I can’t see any errors in the logs on the Ignition Gateway after testing the connection.

The only other piece of information I have is that when attempting to discover the OPC-UA server using port: 62541 (no /discovery appended), I get the following error in Ignition’s logs:

UascServerAsymmetricHandler	07May2020 13:23:55	Error installing security token: StatusCode{name=Bad_SecurityChecksFailed, value=0x80130000, quality=bad}

org.eclipse.milo.opcua.stack.core.UaException: no matching endpoint found: transportProfile=TCP_UASC_UABINARY, endpointUrl=opc.tcp://localhost:62541/, securityPolicy=None, securityMode=None

at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.lambda$openSecureChannel$3(UascServerAsymmetricHandler.java:407)

at java.base/java.util.Optional.orElseThrow(Unknown Source)

at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.openSecureChannel(UascServerAsymmetricHandler.java:397)

at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.lambda$sendOpenSecureChannelResponse$1(UascServerAsymmetricHandler.java:301)

at org.eclipse.milo.opcua.stack.core.channel.SerializationQueue.lambda$encode$0(SerializationQueue.java:57)

at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$Task.run(ExecutionQueue.java:119)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.base/java.lang.Thread.run(Unknown Source)

When using 62541/discovery I get no such errors, making me think that the discovery is indeed working, but testing the connection still does not work. Any ideas on what to try next?

This error is happening because XLReporter is trying to connect to “opc.tcp://localhost:62541/” with SecurityPolicy None.

By default, Ignition’s server only allows secured connections to this endpoint. The discovery endpoint is the only endpoint that allows unsecured connections.

This all sounds like a problem with XLReporter’s client, but you might be able to work around it in Ignition by configuring the Ignition OPC UA Server to allow unsecured connections as well.

Configure > OPC UA > Server Settings:

You’ll have to restart after changing anything here for it to take effect.

Gateway or just the OPC-UA Module?

Well, in theory just the OPC UA module. Out of habit I always restart everything.

Okay, a bit of progress. I set the security policy to None and saw no immediate improvement. Busted out Wireshark and saw that XLReporter was trying to use the static IP address of the server for communications, not localhost or

I added the IP address of the server to the Bind Addresses list, and after testing the connection got a new error in the gateway logs:

[remote=/] Exception caught; sent ErrorMessage{error=StatusCode{name=Bad_SecurityChecksFailed, value=0x80130000, quality=bad}, reason=certificate path validation failed}

Then, went under Configure > OPC UA > Security > Server and accepted the quarantined certificate that showed up for XLReporterOPC.UA. My server security page looks like this now

Now when I test the connection from XLReporter, I get this error:

UascServerAsymmetricHandler	07May2020 15:16:56	Error decoding asymmetric message: could not verify signature
org.eclipse.milo.opcua.stack.core.UaException: could not verify signature

at org.eclipse.milo.opcua.stack.core.channel.ChunkDecoder$AsymmetricDecoder.verifyChunk(ChunkDecoder.java:318)

at org.eclipse.milo.opcua.stack.core.channel.ChunkDecoder$AbstractDecoder.decode(ChunkDecoder.java:150)

at org.eclipse.milo.opcua.stack.core.channel.ChunkDecoder.decode(ChunkDecoder.java:84)

at org.eclipse.milo.opcua.stack.core.channel.ChunkDecoder.decodeAsymmetric(ChunkDecoder.java:64)

at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.lambda$onOpenSecureChannel$0(UascServerAsymmetricHandler.java:248)

at org.eclipse.milo.opcua.stack.core.channel.SerializationQueue.lambda$decode$1(SerializationQueue.java:61)

at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$Task.run(ExecutionQueue.java:119)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.base/java.lang.Thread.run(Unknown Source)

Something’s strange about that because it implies that XLReporter is connecting with some security enabled, but didn’t you just enable no security and configure it to connect without?

Here’s everything:




There’s not a whole lot of options in the XLReporter interface.

If you want to send me a Wireshark capture I’ll take a look, but taken at face value the last error you got is indicating that XLReporter is not correctly signing a message chunk in its OpenSecureChannelRequest to Ignition. I’m not even sure Wireshark will show me anything useful at the point.

You may need to contact the vendor for help.

Yeah there doesn’t look to be like anything interesting or suspicious happening in Wireshark. Thanks for the help, hopefully Sytech has some answers. Just for future reference we’re currently on version 12.61 of XLReporter.

Were you able to get this working? I am having similar issues with XLReporter v14.2 and Ignition v8.1.5.

I tried following the “Using XLReporter with Ignition OPC-UA” document from the sytech website. But couldn’t get it to connect when trying the “Test Connection” button in XLReporter.

When I found your post, I tried the settings in your screenshot and was finally able to make some progress. When I press the Test Connection button, the certificate shows up in Ignition and I was able to get it to the trusted certificates.

But now I can’t get past this step. When I press the Test Connection button, I get the error:

“There is a trust issue between the server and this client. Verify the client is trusted by the server. Server certificates can be imported under options.”

I have tried calling Sytech tech support, but they couldn’t help. They said they were going to try it on their own test setup.

Any ideas?

Unfortunately no. The client wasn’t doing anything heavy with XLReporter, so when it became obvious it was going to be a pain to get things working we just rebuilt the report in Ignition.

Thanks for the update. I may have to do something similar.

I just wanted to update this post for anyone trying to get XLReporter working in the future. I spoke with SyTech technical support and they were able to find a configuration that worked. But be aware that this configuration removes all security from the OPC server and you will also have to update the Igntion OPC Client configuration to match the new settings.

Here are the Ignition OPC server settings:

Here are the XLReporter OPC client settings:
XLReporter Client Settings 1
XLReporter Client Settings 2
You will need to replace “” with your gateway’s IP address in both of the settings above.

XLReporter is looking into why using localhost doesn’t work, so I’m guessing there will be an update in the future. But in the meantime, hopefully this helps anyone trying to get this working.

1 Like

Hopefully they’re also looking into why they can’t connect without disabling security :grimacing:


Better late than never, I suppose, but I was able to get it working.

The default port used is 62541, but I changed that to 4096 as well as disabling the security policy by setting it to None. Not ideal, but the connection does establish.

Change your ip address to whatever your gateway is running on like rberghammer said. Restart the OPC UA module.

Then in XLReporter, you'll want to match it up with the same gateway ip address.


For whatever reason, mine did not like the 62541 port. Keep in mind you'll need to update your endpoint in the OPC Connections page. Hope this helps.