In our facility we use Mitsubishi Q Series PLC’s to control our process. We are attempting to use MX OPC, software by Mitsubishi, to enable OPC-UA based communications. However, when I try and connect the Ignition client to they system I get a connection fault. The error that is displayed is:
status=Bad_CertificateUriInvalid, description=The URI specified in the ApplicationDescription does not match the URI in the Certificate.
When i check the product settings for MX OPC it shows the ApplicationURI field as blank. Should there be an application URI or is this something that I need to fix with the security certificates?
It needs to match whatever the application URI in the certificate is. If you can get the certificate and upload it here I can take a look at it.
Since I just made this account it will not let me upload files to the forum.
Ok, so the URI in the certificate is “urn:USNV021S0217:Mitsubishi:MX OPC Server UA”
So, in theory, you’d want your application URI to match that.
The reality, though, is that it’s an invalid URI, and Ignition (8.0, anyway) won’t be able to connect until you can get the server to generate a certificate that contains a valid URI. URIs are not allowed to contain spaces unless they’re encoded as %20.
Ok thank you for the help. Sounds like an issue I need to address with Mitsubishi.
That’s probably best. I’m not familiar with their software so I don’t know if you can regenerate the certificate with the config tool or if you can influence the URI that gets put into the certificate.
It might turn out that if you can regenerate the cert after setting a correct URI in the spot you mentioned previously that will be enough.
How can i check the certificate URI after I regenerate it?
It’s a component of the Subject Alternative Name extension on the certificate. Your OS may be able to view certificates in enough detail to find it. If not, I use a tool called KeyStore Explorer, which while not primarily meant for viewing certificates, does allow you to do so.
Ya cant change how it makes that URI doesn’t seem like that location does anything. Just when i thought i found a way to enable OPC-UA with my mitsubishi PLC’s…
Kepware has a Mitsubishi driver.
Ya unfortunately Kepware needs the mitsubishi cpu to be configured to output data in the binary format but ours are configured to use ascii. would cause major MES disruptions to change that.
Was trying to find a method that didn’t require significant network changes or downtime to production but its starting to seem like we might just have to bite that bullet.
So I think i was successfully able to change the ApplicationUri and the ServerUri, found the fields buried in an XML document. When i try to connect using the new certificate i get a “status=Bad_SecurityChecksFailed, description=An error occurred verifying security.”
do i need to update the certificate on the ignition end?
You probably need to trust the certificates in both applications now.
In Ignition, it’s on the gateway under Configure > OPC UA > Security. Then go to the Client tab and you should see the MX OPC server certificate there with a button to mark it as trusted.
So i think the security certificate issue has been resolved but now I am getting this error not sure how to handle it.
connection closed
UaException: status=Bad_ConnectionClosed, message=connection closed
at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientMessageHandler.channelInactive(UascClientMessageHandler.java:152)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:242)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:228)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:221)
at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:390)
at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:355)
at io.netty.handler.codec.ByteToMessageCodec.channelInactive(ByteToMessageCodec.java:118)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:242)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:228)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:221)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1403)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:242)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:228)
at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:912)
at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:827)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:495)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:905)
at java.base/java.lang.Thread.run(Unknown Source)
8.0.0 (b2019040718)
Azul Systems, Inc. 11.0.2
This still might be a security issue. Can you look in the gateway logs for additional messages that might be related?
You might also want to get upgraded to 8.0.3 ASAP.
I will upgrade to 8.03 now. Looks like still a certificate issue.
UcascClientMessageHandler
io.netty.handler.codec.DeoderException: UaException: status=Bad_SecurityChecksFailed, message=certificate path validation failed