OPC-UA client cannot connect to BechhoffTwinCAT 3 OPC UA using certificate

[oliveirars]

Hi there.

I am using the Eclipse Milo to connect to some OPC-UA servers and one of them (BechhoffTwinCAT 3 OPC UA) is denying the secure connection. The response error code is UaException: status=Bad_InvalidArgument, message=One or more arguments are invalid.

The client application chooses an endpoint that matches message security mode=SignAndEncrypt and security policy=Basic256Sha256 and the client's configuration is something like that:

OpcUaClientConfigBuilder configBuilder = OpcUaClientConfig.builder()
  .setEndpoint(endpoint)
  .setCertificateValidator(certificateValidator)
  .setApplicationName(LocalizedText.english(environment.programName() + ' ' + environment.version()))
  .setApplicationUri(applicationUri)
  .setIdentityProvider(identityProvider)
  .setKeepAliveInterval(UInteger.valueOf(keepAliveInterval))
  .setKeepAliveFailuresAllowed(UInteger.valueOf(keepAliveFailuresAllowed));
  .setKeyPair(keyPairAndCertificateChain.getKeyPair())
  .setCertificate(keyPairAndCertificateChain.getCertificate())
  .setCertificateChain(keyPairAndCertificateChain.getCertificateChain());

I talked to the server's administrator and he told me that the message security mode is not correct or is being sent as None. I couldn't find the point where this information could be set. I thought the chosen endpoint had these security information parameters. Here is part of the log I've received from the server side:

16:50:48.416Z|3|0A5C* UaServer_EndpointCallback/SecureChannelOpened - ClientCertificateThumbprint: 68C947177DCAA3311D5FE02EFD708527DE837719
16:50:48.416Z|6|0A5C* --> UaServer::secureChannelCreated
16:50:48.416Z|4|0A5C* [uastack] UaDir::mkpath: Path already exists!
16:50:48.416Z|6|0A5C* <-- UaServer::secureChannelCreated
16:50:48.416Z|7|0A5C* [uastack] OpcUa_SecureListener_ChannelManager_ReleaseChannel: SecureChannel 0465AE10 with id 3674905091 refs 2->1!
16:50:48.416Z|7|0A5C* [uastack] OpcUa_SecureListener_ChannelManager_ReleaseChannel: SecureChannel 0465AE10 with id 3674905091 refs 1->0!
16:50:48.416Z|7|0A5C* [uastack] OpcUa_SecureListener_ChannelManager_GetChannelByTransportConnection: Searched SecureChannel 0465AE10 with id 3674905091 refs 0->1!
16:50:48.416Z|7|0A5C* [uastack] OpcUa_SecureListener_ChannelManager_ReleaseChannel: SecureChannel 0465AE10 with id 3674905091 refs 1->0!
16:50:48.416Z|2|0A5C* [uastack] OpcUa_TcpListener_ReadEventHandler: Process Request returned an error (0x80AB0000)!
16:50:48.417Z|4|0A5C* [uastack] OpcUa_TcpListener_SendErrorMessage: to [::ffff:10.120.10.58]:54120 (socket 057FECEC) with StatusCode 0x80AB0000
16:50:48.475Z|6|0A5C* [uastack] OpcUa_Endpoint_OnSecureChannelEvent: ID 3674905092 open event with status 0x80AB0000!
16:50:48.475Z|1|0A5C* UaServer_EndpointCallback: SecureChannel 3674905092 open failed! [status=0x80ab0000]
16:50:48.475Z|3|0A5C* UaServer_EndpointCallback/SecureChannelOpened: RequestedLifetime 0
16:50:48.475Z|3|0A5C* UaServer_EndpointCallback/SecureChannelOpened: Security Mode 0 Security Policy http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256
16:50:48.475Z|3|0A5C* UaServer_EndpointCallback/SecureChannelOpened - ClientCertificate:

Does someone have any idea about what could be the problem?

[kevinherron]

Maybe you can provide a Wireshark capture?

That said, in the past I've seen Bad_InvalidArgument used by servers when they don't like something about the provided certificate.

[oliveirars]

Hi, Kevin. Thanks for your attention.

We suspect this is the problem, but we don't have any concrete evidence about what the server doesn't like in the certificate. The client certificate is rejected and "moved/registered to the rejected folder" on the server side.

The server admin said the security mode sent is 0 (None). Can this information be part of the certificate somehow?

I will ask him for the Wireshark capture.

[kevinherron]

It's not part of the certificate, no.

If you can provide the Wireshark capture and a copy of your client certificate that might be useful.

[kevinherron]

Also, if your certificate is self-signed, the server may be enforcing this new OPC UA 1.05 behavior re: the cA bit.

#1110

2a58010

[oliveirars]

I couldn't have the Wireshark capture from the real scenario.

However, I have a question about a capture I did in my local environment. I noticed that after the first ACK, an OpenSecureChannelRequest is sent to the server. The message has None as MessageSecurityMode.

Would it be possible that this field is being stored by the server and then a conflict occurs with messages having SignAndEncrypt as the mode?

[kevinherron]

No, this just looks like the "standard" connection opening sequence that most clients do.

1. open a secure channel, call GetEndpoints service, then close that channel
2. select one of the available endpoints
3. open a secure channel to one of the selected endpoints

In your screenshot the useful information is probably in packet 6305 and 6308, but you may need security disabled to be able to see all the details.

[oliveirars]

Yes, it is the standard connection process.

Disabling the security makes the application work (and the OpenSecureChannelRequest will have None as MessageSecurityMode). I was wondering if, somehow, the first channel's configuration could be kept on the server side and cause the inconsistency.

From what you said, it is not expected. The first channel is closed, and another one is created in packets 6305/6308

I will check for more information.

Thank you so much for your help.

[kevinherron]

Disabling the security makes the application work (and the OpenSecureChannelRequest will have None as MessageSecurityMode).

This is more evidence it could be the certificate issue I alluded to above.

[oliveirars]

We decided to upgrade the Milo library from 0.3.8 (yes, we were using an old version) to the newest one (0.6.11), and the problem was solved. Maybe some update about security was added to the newer version, right? We couldn't precisely identify the root cause, but it is nice to have things working again.

I'd like to thank your attention and help with the issue. Your considerations help us in the investigation process, avoiding wrong paths. Thank you so much!