Skip to content
Ask A Question
  • There are no suggestions because the search field is empty.

Issues Connecting AVEVA OIGateway to TOP Server via OPC UA with Encryption and Authentication

I'm trying to connect AVEVA OIGateway to TOP Server via OPC UA. This is successful with connections that are not using encryption or username/password authentication. But when enabling encryption and authentication, the connection fails.

I've double-checked that:
  • The OPC UA Server interface is enabled in TOP Server (under Project Properties -> OPC UA)
  • The OPC UA endpoint in TOP Server I'm trying to connect to is:
    • Enabled
    • Has the same security policy and sign/encrypt setting enabled that my OIGateway connection is using
    • Is NOT set to "Localhost only" for the Network Adapter (unless TOP Server is on the same machine as OIGateway)
  • The OIGateway certificate has been trusted in the Trusted Clients section of the TOP Server OPC UA Configuration Manager
  • The correct endpoint URL (including port) has been entered for the connection in OIGateway (as compared to the endpoint URL in TOP Server).
  • There is no firewall blocking the port used by the TOP Server UA endpoint.
What else could be the issue?
 
There may be an issue with the OIGateway's own UA security certificate. The security certificate for OIGateway bases it's URI off of the machine name when OIGateway was initially installed - if the user later renames the computer in the domain or workgroup, the certificate is no longer valid (since the machine name in certificate no longer matches the actual machine name) and needs to be reissued.
This is a non-obvious issue as it's entirely possible to still trust OIGateway's certificate in TOP Server. The key is for the user to confirm that the URI (listed as the second column in the Trusted Clients section of the OPC UA Configuration Manager in TOP Server) has the correct machine name (format is "urn:{machine name}::OIGateway OPCUA") - it's key that the machine name listed is actually the correct name of the machine where OIGateway is installed.
If it isn't, the certificate for OIGateway has to be reissued. Unfortunately, there is no convenient button for reissuing the certificate like there is for TOP Server. The method to follow is:
  1. Stop OIGateway completely.
  2. Find and delete OIGateway's UA certificate (currently, this directory should be C:\ProgramData\Wonderware\OI-Server\$Operations Integration Supervisory Servers$\OI.GATEWAY\CertificateStores but it is subject to change)
  3. Start OIGateway (this should result in the certificate being issued again with the current machine name as part of the URI).