I am trying to use the OPC-UA client from an RTAC (SEL-3350) to communicate with an Ignition OPC-UA server on a virtual machine. I am having issues getting the two to connect. Has anyone connected to Ignition using the RTAC OPC-UA Client and if so, how did you get it to work?
Connection
The 0 is there in the IP Address just out of view.
Things I have Tried:
- Toggling the Anonymous Access Allowed checkbox.
- opc.tcp://10.100.100.70:62541/discovery in the RTAC
- opc.tcp://10.100.100.70:62541 in the RTAC
- Added the IP Address to the Endpoint addresses.
- Looked at Windows Firewall settings.
System:
- Operating system: Windows Server 2022
- Ignition version: IgnitionEdge 8.1.44
I did, but so long ago I don't remember much. The Ignition side was simple, the main issue I had was the RTAC wasn't setup correctly (which I wasn't in charge of), once it was setup correctly it connected just fine.
To add, the last time I checked the RTAC can't do redundancy and OPC-UA, so might be worth poking at that before you go too far down this path.
1 Like
Set the Bind Address to 0.0.0.0 and restart. You might also want to add the "None" SecurityPolicy while you're at it, e.g. None, Basic256Sha256. Turn on the "Exposed Tags" setting if you want other clients to be able to see your Ignition Tags and not just your configured devices.
Changes to these settings need a restart to take effect.
2 Likes
Changing the Bind Address to 0.0.0.0 and the security policy to None allow the RTAC to start importing data but the Ignition server faulted during the process.
The error message I am getting now is listed below.
UaException: status=Bad_ConfigurationError, message=no matching endpoints found
at com.inductiveautomation.ignition.gateway.opcua.client.ManagedClientKt.initialize(ManagedClient.kt:139)
at com.inductiveautomation.ignition.gateway.opcua.client.ManagedClientKt.access$initialize(ManagedClient.kt:1)
at com.inductiveautomation.ignition.gateway.opcua.client.ManagedClientKt$initialize$1.invokeSuspend(ManagedClient.kt)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
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)
The comment about redundancy is good to know because I have another project coming up that is similar to this with redundancy! I will definitely look into that.
You might need to run through discovery again for the Ignition loopback connection. It looks like maybe you didn’t include the Basic256Sha256 security policy or an IP addresss used in the configured connection isn’t there any more.
1 Like
Okay, I will check as soon as I can get connectivity back to the server.
The IP Address for the server and client changed to 172.16.70.33 and 172.16.70.20 respectively. When I go through discovery, I get an internal error after I select the server. Attached is my wrapper log
wrapper.log (2.4 MB)
Ugh, that markup error requires you to stop Ignition, delete the data/jar-cache folder wherever Ignition is installed, and start it again.
Can you post a screenshot of your server settings as it currently stands?
Ok those look fine, you'll just have to walk through the endpoint discovery again for the connection again, or if you can't get that working use "skip to advanced" and we'll have to manually update the discovery and endpoint URLs.
On a fresh install the loopback connection's URLs use "localhost" so that your server getting a new IP address doesn't cause the connection to break -- not sure what's going on for you.
Deleting the jar-cache file allowed to go through the discovery process again. However, I am getting security messages when trying to get the RTAC to connect.
wrapper.log (2.5 MB)
Have you trusted the RTAC client certificate yet?
If so, download it and attach it here and I'll take a look and see if there's anything wrong with it.
I trusted what I believe is the client.
Yeah that's probably it, click the Cloud Icon to download it and then upload it to the forum.
This is what appears in the wrapper log when I try to get the RTAC to connect.
INFO | jvm 1 | 2025/03/07 14:29:56 | E [o.e.m.o.s.s.t.u.UascServerAsymmetricHandler] [14:29:56.928]: [remote=/172.16.70.1:21837] Exception caught; sent ErrorMessage{error=StatusCode{name=Bad_CertificateUseNotAllowed, value=0x80180000, quality=bad}, reason=status=Bad_CertificateUseNotAllowed, description=The Certificate may not be used for the requested operation.}
INFO | jvm 1 | 2025/03/07 14:29:56 | io.netty.handler.codec.DecoderException: UaException: status=Bad_CertificateUseNotAllowed, message=The Certificate may not be used for the requested operation.
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:500)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1407)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:918)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
INFO | jvm 1 | 2025/03/07 14:29:56 | at java.base/java.lang.Thread.run(Unknown Source)
INFO | jvm 1 | 2025/03/07 14:29:56 | Caused by: org.eclipse.milo.opcua.stack.core.UaException: status=Bad_CertificateUseNotAllowed, description=The Certificate may not be used for the requested operation.
INFO | jvm 1 | 2025/03/07 14:29:56 | at org.eclipse.milo.opcua.stack.server.security.DefaultServerCertificateValidator.validateCertificateChain(DefaultServerCertificateValidator.java:117)
INFO | jvm 1 | 2025/03/07 14:29:56 | at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.onOpenSecureChannel(UascServerAsymmetricHandler.java:198)
INFO | jvm 1 | 2025/03/07 14:29:56 | at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.decode(UascServerAsymmetricHandler.java:120)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
INFO | jvm 1 | 2025/03/07 14:29:56 | at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
INFO | jvm 1 | 2025/03/07 14:29:56 | ... 16 common frames omitted
This certificate is missing some things that would make it a valid OPC UA application instance certificate. See UA Part 6: Mappings - 6.2.2 Application Instance Certificate;
- KeyUsage is missing
keyCertSign
- BasicConstraints is missing entirely
Do you have any control over the generation of this certificate? You may need support from SEL.
You might also be able to enable the "None" security policy and allow anonymous identities on the Ignition server and connect without security for now.
1 Like
When I set it to None, do I need to restart the OPC-UA driver?
Any change to the server settings page requires a restart of either the entire OPC UA module, or preferably the Ignition Gateway.
In Ignition 8.3 the Ignition OPC UA server itself will restart as necessary (temporarily disconnecting any connected clients), but restarting the Ignition Gateway won't be necessary any more.
1 Like
