OPC UA Connections Faulted After Upgrading from Ignition 7.9.9 to 8.0.2

Once we upgraded to Ignition 8, both of my OPC-UA servers I had connected faulted. I thought I had found the problem once I found some certificates quarantined in the Security section of the OPC-UA configuration, but after I marked both of the certificates as trusted, only one of my servers reconnected. The other is still faulted with the log:

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.2 (b2019060511)
Azul Systems, Inc. 11.0.3

I also noticed that one of the certificates was expired. I marked the expired certificate trusted and it appeared under the trusted certificates section, but moments later it would reappear as quarantined so it would be listed as both trusted and quarantined.

Are there any ideas as to what the problem could be? Is it the expired certificate?

It’s most likely the expired certificate. You’ll have to regenerate it in the configuration software for that server.

Also - is there an additional error in your gateway logs?

Something like:

"[remote=...] Exception caught: ..."

hopefully with a more accurate failure message?

Yes, there is an error in the gateway log of that nature.

So it appears that the expired certificate is causing the problem. Now I just have to figure out how to regenerate the certificate from my server.

These are the reasons I haven’t updated yet. Wish I could, wish current users could get an extended ‘extra’ license to run a new server for say, 60 days. This way I can move my projects when I get time instead of selling out and updating.

No harm in asking your sales rep.

Also, since it would be a dev server you migrated to slowly, what harm would there be in just running it in trial mode and resetting the trial when it runs out?

I’ve totally hijacked this thread, my apologizes.
I want to do a restore from my 7.9.10 backup and enable projects one at a time, disabling them on my master and redirecting the clients. Trial mode isn’t a viable option for that. I will ask for an extended key, I’m starting a project to remove WW from our site and would like to use the Perspective module for it.
Thanks Kevin, sorry Kyle.

Careful with that strategy, you’re going to have double the load on all your PLCs / OPC servers / databases while you have both Ignition’s running… and take extra care if you have history enabled that you don’t start storing history from 2 gateways with the same system name.

yes, thank you for the additional thoughts. I would enable the PLCs after I moved the project, then disable the original. My IT department is the bomb, all my servers and networks are very stout and they work very close with me. I’ve accidentally drove my MSSQL to 1200 queries/sec, it took it, but normal is around 120 to 250. Be careful of queries bringing back loads of data, running in a dedicated timer script that can’t finish before you ask for more data :slight_smile: This was mostly because the WW server is so slow.

Great news! I was able to generate a new certificate from my server and that fixed the problem. My device reconnected as soon as I trusted the new certificate. Thanks for the help!

1 Like

Thanks for coming back to update.

Hi,
is it somehow possible in Ignition to trust expired certificates? I’m having troubles with a B&R PLC’s certificate that is expired. With other OPC UA clients I have the possibility to accept the certificate manually. The problem will also recur in a few years when now valid certificates will finally expire. And not for every PLC it will be possible to get a new certificate.

It’s not possible to disable that check, you’ll have to disable security for the connection if you can’t get a valid certificate installed.

1 Like