How to Fix OPC UA Certificate Trust Errors

Back to Blog

First Checks: Which Side Is Rejecting?

The single most useful diagnostic fact is which end refused. If the client reports that the server's certificate is untrusted, the fix happens in the client's trust configuration. If the client's connection is rejected by the server - often surfacing as a generic security failure on the client side - the server's log tells the truth, and the fix happens in the server's trust list. Checking both logs before touching any store prevents the most common wasted hour in OPC UA commissioning: trusting the right certificate on the wrong end.

Remember that trust must exist in both directions before a secured connection forms. Fresh installations fail in both directions at once, which is normal and expected: the first connection attempt is how each side obtains the other's certificate to reject. The practical commissioning sequence is deliberate - attempt a connection, let it fail, then approve the newly rejected certificate on each side and try again.

Trust Lists and the Rejected Store

Every OPC UA application maintains a certificate store with a trusted list and, in most server implementations, a rejected area where certificates from unknown peers are parked after a failed attempt. That rejected store is the working surface for commissioning: the unknown certificate is already there, and trusting it is a move or approve operation in the server's administration tool rather than any manual file transfer. If the rejected store is empty after a failed connection, the attempt likely never reached the security handshake at all - look at network reachability and endpoint selection instead of certificates.

Self-signed certificates, which most industrial OPC UA applications use by default, must be trusted individually on every peer, which is manageable for a handful of connections and painful at scale. The alternative is issuing application certificates from a certificate authority and trusting the CA once on each application - then any certificate the CA issued is accepted, and renewals stop requiring a site-wide re-trust. When a CA is in use, remember the application also needs any intermediate certificates available to validate the chain, and an incomplete chain produces trust errors that look identical to a missing certificate.

Expiry, Regeneration, and Identity Mismatches

Certificates expire, and OPC UA applications correctly refuse expired ones. A connection that worked for years and failed overnight is the classic expiry signature, and the certificate's validity dates - visible in any certificate viewer - settle it immediately. The related failure is time itself: certificate validation compares against the local clock, so a device whose clock is wrong by years can reject perfectly valid certificates or accept expired ones. Embedded devices that lost their clock after a power cycle are the usual culprits, which makes time synchronization part of certificate troubleshooting.

Regeneration is subtler. When an application is reinstalled, its hostname changed, or its certificate deliberately renewed, it presents a new certificate - and every peer that trusted the old one now sees an unknown identity and rejects it. The old certificate sitting in the peer's trusted store does nothing; the new one must be trusted. Finally, OPC UA binds certificates to application identity: the application URI embedded in the certificate should match the URI the application declares in its application description. Stacks that enforce the match reject on mismatch, which typically appears after cloning configurations between machines or regenerating certificates with tools that filled the URI differently. The fix is regenerating the certificate with the correct URI rather than loosening validation.

When to Escalate, and Doing Trust Sustainably

Escalate to the vendor when the certificate is demonstrably trusted, valid, chain-complete, time-synced, and URI-matched, and the handshake still fails - at that point the suspects are stack bugs, unsupported security policies between the two products, or store corruption, all of which need vendor specifics. Bring both applications' logs for one failed attempt and exports of both certificates; that pair of files is usually enough for a support engineer to spot the mismatch quickly.

The unsustainable answer is disabling security to make the error disappear, which trades a commissioning problem for a permanent one. The sustainable pattern for a fleet - many devices, several clients, staff turnover - is a small internal CA, an inventory of certificate expiry dates, and renewal scheduled before expiry rather than after the outage. A monitoring platform such as Merobix connecting to many OPC UA servers benefits from exactly the same discipline on its own client certificate: one identity, trusted deliberately at each server, renewed on a calendar instead of in a crisis.

Frequently Asked Questions