OPC-UA connection failed after upgrade to 8.1.0 Bad_CertificateUriInvalid

Ignition
1

Update: Disabling ‘Certificate Validation Enabled’ fixed the problem for now. I guess the validation changed somewhere between 8.0.10 and 8.1.

I just upgraded Ignition to 8.1.0 and the connection to a OPC-UA server (TANI) stopped working.

The status page shows a certificate error. Thats strange, because security is set to None.

UaException: status=Bad_CertificateUriInvalid, message=The URI specified in the ApplicationDescription does not match the URI in the Certificate.
	at org.eclipse.milo.opcua.stack.core.util.validation.CertificateValidationUtil.checkApplicationUri(CertificateValidationUtil.java:685)
	at org.eclipse.milo.opcua.stack.client.security.DefaultClientCertificateValidator.validateCertificateChain(DefaultClientCertificateValidator.java:100)
	at org.eclipse.milo.opcua.sdk.client.api.identity.UsernameProvider.getIdentityToken(UsernameProvider.java:162)
	at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.activateSession(SessionFsmFactory.java:881)
	at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.lambda$configureActivatingState$17(SessionFsmFactory.java:345)
	at com.digitalpetri.strictmachine.dsl.ActionBuilder$PredicatedTransitionAction.execute(ActionBuilder.java:76)
	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.0 (b2020110211)
Azul Systems, Inc. 11.0.7

This message appears in the gateway log every few seconds

INFO   | jvm 1    | 2020/11/29 16:53:30 | W [o.e.m.o.s.c.s.OpcUaBinaryStreamEncoder] [15:53:30]: Not a built-in type: class java.math.BigInteger

Any ideas?

2

It could be a legit mismatch between what’s in the certificate or what’s in the endpoints or it could be something else - can you get a Wireshark capture of the connection being made?

I’m not sure where the BigInteger thing is coming from… something in Ignition is sticking a BigInteger into an OPC write probably, but not sure offhand how to track that down.

3

Here is the wireshark capture. On my test system i have a working connection to this UA-server, but i am not able to create a new one that is not faulted. Only visible difference is upper-lower case in the endpoint address (‘srv’ vs ‘SRV’).
opcua.zip (3.4 KB)

Is there a logger that would help me trace the origin of thet BigInteger message?

4

Jython doesn't use java.lang.Long by default for anything. Its long() type is implemented with BigInteger, so anything 64-bit passed to an untyped interface will be BigInteger.

5

TANI server is not configured correctly:

wireshark
wireshark1710×836 150 KB

cert
cert1324×1910 377 KB

The URI in the certificate must match the one in the ApplicationDescription returned in the endpoints. You said you are not using security, but you must be using a username and password, which in this case requires the server’s certificate be used to encrypt the credentials for transit and therefore requires that it is trusted and pass all validation checks.

6

Thank you for your help.

The hostname of the virtual machine was changed since the first setup of the TANI server. I had to delete the certificate and restart the service to create a new certificate with the correct uri.

7

This is one reason Ignition no longer uses hostname or IP in the application URI it generates.

8

Hi Kevin,

could you please give me more details how to configure TANI server?
thanking you in advance

kind regards,