Hi,
I am attempting to setup a OPC UA connection where ignition is the client and codesys v3.5 is the server. Both are hosted on the same machine. I am able to connect to the codesys opcua server with the uaexpert just fine. When I attempt to connect with ignition I see an error on the status page of the ignition gateway.
UaException: status=Bad_CertificateUseNotAllowed, message=The Certificate may not be used for the requested operation.
- On the ignition side i can see the cert from the codesys server and it is trusted.
- On the codesys side i can see the cert from both the uaexpert client as well as the ignition client and both are trusted.
Any ideas why I can connect with UAexpert but not with ignition? The settings appear to the same for both connections in terms of the communication method and signing and encryption and authentication.
Regards,
Adam
What version of Ignition are you using?
Is there a stack trace to go along with that error? I think this means the server doesn't like something about the Ignition client certificate... but I have no idea what it could be complaining about.
edit: ah, it could also means we don't like something about the server certificate. There's an advanced setting on the connection to disable certificate validation, you can try that and see if it's the Ignition side.
What version of Ignition are you using?
Version: 8.1.26 (b2023032308)
Is there a stack trace to go along with that error?
UaException: status=Bad_CertificateUseNotAllowed, message=The Certificate may not be used for the requested operation.
at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientAcknowledgeHandler.onError(UascClientAcknowledgeHandler.java:258)
at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientAcknowledgeHandler.decode(UascClientAcknowledgeHandler.java:167)
at io.netty.handler.codec.ByteToMessageCodec$1.decode(ByteToMessageCodec.java:42)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:510)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:449)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:279)
at io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Unknown Source)
8.1.26 (b2023032308)
Azul Systems, Inc. 11.0.18
There's an advanced setting on the connection to disable certificate validation, you can try that and see if it's the Ignition side
I tried that, no difference
Yep, that's it. The server is rejecting the client certificate. I don't know why, you'll probably have to talk to Codesys about what kind of logging they have or how you can figure that out.
If you can provide an export of the UaExpert client certificate and the Ignition client certificate I can take a look and see if there's a meaningful difference as far as OPC UA requirements go.
Ill upload them now, none of this stuff is for production its just testbed so it does not matter.
This is the codesys opcua server cert
DESKTOP-G0I7O6P.cer (1.1 KB)
These are the certs from the two different clients that are trying to connect , where only one of them is working. Both are marked as trusted on the codesys side.
Ignition OPC UA Client.cer (1.1 KB)
UaExpert@DESKTOP-G0I7O6P.cer (1.1 KB)
On the codesys side I see the same message repeated in the log every few minutes.
Well... I have a guess about what's wrong, but it's an obscure technical detail about how self-signed certificates should be generated in a recent revision of OPC 1.05, and you'd need someone at Codesys to confirm this is why they are rejecting it, but:
The Ignition client cert has the cA bit in the BasicConstraints extension set to true, with the path length omitted. The UaExpert cert has the cA bit true and the path length set explicitly to 0.
The recent change was that the cA bit should now be set to false for self-signed certs, and I think there was an exception made for true, but only if the path length was explicitly set to 0.
This is all a hazy memory that I'm going to have to try to verify with the UA security working group, and there's nothing you can really do in the meantime except connect to the server without security and get in touch with Codesys to verify this is even what's going on.
Thank you for checking this out, I appreciate it.
connect to the server without security
I would love to, but codesys does not appear to allow that as an option.
The three available policies to choose from all require either signing or signing and encryption.
That EnableSelfSignedCertBackwardInteroperability option is making me think my theory is correct...
We'll have to make a change in a future version that generates certificates with the pathLen explicitly set to 0. I don't really have any ideas for a workaround until then.
Just out of curiosity I disabled the backwards interopability option to see what happened. When I did that the uaexpert was no longer able to connect either, and produced a similar error message.
The fault from the ignition gateway remained unchanged.
Yep, with that disabled, I would expect both client connections to fail because both client certs have the cA bit set to true.
Hoping to have a fix for this in a nightly release next week some time.
1 Like
That is great. I am not that familiar with Ignition, will those nightly releases be available for download for the public?
Yeah, there is a section on the downloads page for nightly releases. Just change the version in the dropdown menu.
The nightly build that will be available to download tomorrow (2023-04-05) should have a fix for this.
Once installed, you will need to regenerate your OPC UA client certificate in the OPC UA > Security section of the Ignition Gateway.
3 Likes
Ill try the latest release and let you know how it goes.
