The URI specified in the ApplicationDescription does not match the URI in the certificate

[GavEB77]

Hi, I'm working with a customer where I have configured KepServerEX as an OPCUA tunnel taking data from an OPCDA Server and providing it to an OPCUA Client. The OPCUA Client is a product called Tridium Niagara. We didn't apply a security policy initially however the latest version of Niagara requires that Basic256Sha256 is required. I have selected to use sign; sign and encrypt and configured the OPCUA side on KepServerEx.

However, when I trust the Niagara OPCUA Client Certificate and try to connect Niagara to KepServerEx it fails with Niagara logging the following message, The URI specified in the ApplicationDescription does not match the URI in the certificate.

The Certificate that I am using is the self signed certificate created by KepServerEx using OpenSSL. Also, to note the KepServerEx is installed on one virtual server and Niagara is installed on another. Whenever we create a new KepServerEx certificate it uses the credentials of the user logged in as part of the URI. 

I've also modified the endpoint so that it takes the hostname of the virtual server because I thought that maybe because the endpoint had an IP address and the Certficate had the hostname in its Subject Alternative Name.

Is there any way to modify the URI for KepServeEx certificate? Has there been any similar cases?

Any advice on how I can resolve this issue would be greatly appreciated?

Kind regards,

Gavin

[VladimirN]

Take a look here - "Changing Application URI in client object": https://github.com/FreeOpcUa/python-opcua/issues/776

[GavEB77]

Thank you @VladimirN I will look at this information.

[GavEB77]

Thank you for the information @VladimirN unfortunately it relates specifically to an OPCUA client built with Python. I think the issue resides on the OPCUA Client side, the OPCUA Client in Niagara. 

The self-signed certificate generated by KepServerEx is fine, special characters are substituted with '%20' which is standard practice. I'm not leading the testing, it is being led by the customer but my next step would be to use Wireshark to monitor the initial handshake to determine the information Niagara is sending in its certificate. However I'm not sure whether the customer would be able to install Wireshark, it might be flagged by their IT department.

Thanks for the advice anyway @VladimirN it helped narrow the issue.