Certificate warnings

Hi,
Are there any smart way to illustrate or trigger an alarm regarding certificates valid to date?
The OPC tags in Ignition started to behave strangely in a project I'm working on. The tags came from a Kepserver containing data gathered from different PLCs. Some PLC’s displayed all tag data while others had no data, only the info “uncertain_lastknownvalue”. My initial belief was the there was something wrong with the Kepserver but there I could browse all tags and they displayed the latest data. Went over to the Ignition gateway and under the ‘Status’ tab -> ‘OPC Connection’ I could see the status of the connection to the Kepserver was toggling between ‘faulted’ and ‘connected’ with the cryptic fault message “java.lang.Exception: session inactive: id=NodeId{ns=1….” which didn’t help. After some time I found that the certificate (Ignition gateway -> Config -> Opcua -> Security) issued by the Kepserver had expired. I renewed the certificate and reconnected and after that everything was fine. The connection between different tags behave strangely to a OPC certificate being out of date far from straight forward. In the ‘Security’ window of the gateway there is a column ‘Expiration’. Is there any built in function that could grab that data and prompt a user take action? If not would it be possible to build one yourself? Due to the strange symptoms of problem the functionality is very much needed.
If anyone could help out on this matter it would be much appreciated.

There isn't any warnings right now, though this is something we're opening to adding, at least for Ignition's own certificates.

That said, I have a hard time believing that was your problem. When a certificate expires the connection will stop working. No weird behavior, no getting to the 'Connected' state and then faulting. Tags uncertain or bad quality and remaining that way.

I'm using version 8.1.18 if that could be of any use. Since this data is real time production data I'm not allowed to reset the certificate to expire tomorrow and see the effects. But I can see if I can setup a similar scenario in an test environment and see the out come.
I'll past the error message in full in case it could be of any use;

For reference SESOPS0125 is the server with the Ignition gateway, SESOPS0089 is the server for Kepware runing KEPServerEX V6;

java.lang.Exception: session inactive: id=NodeId{ns=1, id=853e76d6-d2b0-4e02-9ca6-9ae0f6f7a91b} name=ignition[Ignition-SESOPS0125]_SESOPS0089_1693986260496
at com.inductiveautomation.ignition.gateway.opcua.client.connection.OpcUaConnection$MiloSessionActivityListener.onSessionInactive(OpcUaConnection.kt:498)
at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.lambda$null$39(SessionFsmFactory.java:577)
at java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(Unknown Source)
at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.lambda$configureActiveState$40(SessionFsmFactory.java:577)
at com.digitalpetri.strictmachine.dsl.ActionBuilder$PredicatedTransitionAction.execute(ActionBuilder.java:119)
at com.digitalpetri.strictmachine.StrictMachine$PollAndEvaluate.lambda$run$0(StrictMachine.java:242)
at java.base/java.util.ArrayList.forEach(Unknown Source)
at com.digitalpetri.strictmachine.StrictMachine$PollAndEvaluate.run(StrictMachine.java:227)
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)

8.1.18 (b2022061518)
Azul Systems, Inc. 11.0.15

This is a somewhat generic Exception that just means we lost the connection/session to the server for some reason.

My point, though, is that if a certificate is expired on either side you shouldn't be able to get to a place where there is a connection to lose.

Is there anything in your Gateway logs around this time?


The ip-address 10.2.16.66 is that of the Kepserver

None of this indicates a problem with expiring certificates so far. Maybe you should work with support.

This will probably end up needing a Wireshark capture to diagnose, after having disabled security on the connection to Kepware. It looks like somebody has perhaps an off-by-one error somewhere.