How to Verify an OPC UA Server Endpoint With a Test Client

Back to Blog

Discover the Endpoints With GetEndpoints

Point the test client at the server's discovery URL and call GetEndpoints. This unsecured call returns the list of endpoints the server actually offers: their URLs, the security policies available, the message security modes, and the accepted user token types. It is the ground truth for what the server supports, and it needs no certificate trust to run, so it works even when a full connection would not.

Compare the returned endpoint URL against the one you were given. Servers frequently advertise an endpoint URL that differs from the address you dialed - a hostname instead of an IP, or an internal name unreachable from your network. That mismatch is a leading cause of connections that discover fine but then fail to activate. For the anatomy of that string, see the OPC UA endpoint URL.

Confirm the Security Policy and Message Mode Offered

Read the security policy and message security mode on each endpoint in the list. If your site requires signed and encrypted traffic, confirm the server actually offers an endpoint with SignAndEncrypt on a strong policy, and that a plaintext None endpoint is not the only option. If the only secured policy on offer is one your client cannot speak, you have found the incompatibility before wasting time on certificates.

Pick the endpoint you intend to use in production now, from this list, rather than letting the client auto-select. Auto-select often lands on None because it connects easiest, and then you have verified the wrong thing. To choose deliberately, understand the tradeoff in message security mode Sign vs SignAndEncrypt.

Connect on the Intended Secure Endpoint

Now connect the test client on the exact secured endpoint you chose. This is where certificate trust is exercised: the client presents its application instance certificate and must trust the server's, in both directions. If this step fails while GetEndpoints succeeded, the fault is certificate trust, not reachability - a clean isolation you only get by testing the layers separately. Work that failure with fixing OPC UA certificate trust errors.

A successful secure connect means the transport and mutual trust are proven. Do not skip straight to production here; you have confirmed the pipe is secure but not yet that your user identity is accepted. Keep the test client on the secured endpoint for the next check so identity is tested over the real security, not over None.

Authenticate as the Production Identity and Browse

Activate the session using the same user token production will use - anonymous, username and password, or a user certificate. Testing with anonymous when production uses a named user proves nothing, because the server may treat the two identities completely differently for both connection and later reads. Match the real identity here.

With the session active, browse to one node you know should exist and read its value. A good value with good quality confirms the full stack end to end: reachable, secured, authenticated, and authorized for at least that node. If browse works but the read is denied, that is an access-rights result, not a connection one - handled in fixing OPC UA reads that fail after browse succeeds.

Verify Before Handing Off to Production

Record exactly what worked: the endpoint URL you connected on, the security policy and mode, the user identity, and the node you read. That record is the configuration your production client should mirror. A verification that ends without a written-down known-good configuration forces the next person to rediscover it.

Then configure the production client to those exact values rather than letting it auto-negotiate. If production behaves differently from the test client, the difference is now a short list - identity, endpoint, or policy - because you proved each one. That is the payoff of testing the layers in order instead of all at once.

Common Mistakes

The classic mistake is connecting on the None endpoint to get a quick success and declaring the server verified, when production will use a secured endpoint that behaves differently. The second is testing with anonymous access and a different identity than production, which skips the authorization layer entirely.

Another is ignoring the endpoint URL the server returns from GetEndpoints and continuing to dial the address you started with, so the connection later fails on a name your network cannot resolve. And do not verify through your production stack: a throwaway test client is what lets you see which single layer failed.

Frequently Asked Questions