Status code · Certificates
BadCertificateUriInvalid
BadApplicationUri / SAN
BadCertificateUriInvalid means the ApplicationUri the peer declares does not match the URI entry in its certificate's Subject Alternative Name. The two must be identical strings. Fix it by aligning the application configuration's ApplicationUri with the certificate SAN, or reissuing the certificate with the correct URI entry.
Defined behaviour: The URI specified in the ApplicationDescription does not match the URI in the certificate. (our description of the condition this code reports)
What you actually see
Certificate validation gets past trust and hostname checks and then fails on the application URI, often immediately after someone copied a configuration file or a certificate between two applications.
Why it happens
- The ApplicationUri in the configuration was changed but the certificate was not reissuedValidation step 7 compares ApplicationDescription.ApplicationUri against the URI entry in the certificate SAN. Editing ApplicationUri in the application configuration - renaming an application, changing a company prefix - immediately invalidates the existing certificate for that application even though nothing about the key material changed.
- The certificate has no URI entry in its SAN at allCertificates minted by generic tooling or a corporate CA web form usually contain DNS names and no URI. OPC UA requires the ApplicationUri to be present as a URI: SAN entry. Without it there is nothing to match and the check fails outright.
- A certificate was reused across applicationsCopying one application's certificate and private key to a second application is a common shortcut. The second application declares its own ApplicationUri, which no longer matches the URI baked into the borrowed certificate. Each application instance needs its own certificate.
- Hostname substitution inside the URIMany stacks build a default ApplicationUri containing the machine name, such as urn:HOSTNAME:company:product. Some substitute the live hostname at runtime while the certificate froze the name at generation time, so a host rename, a clone or a container with a random hostname breaks the match.
- Trailing or case differencesThe comparison is a string comparison. urn:plant:plc-01:server and urn:plant:plc-01:server/ are different, as are differing cases in the part after the scheme. This is why the failure often survives what looks like a correct manual fix.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Print both stringsRead the certificate's URI SAN with openssl x509 -in cert.der -inform der -noout -text and note the URI: entry. Then read ApplicationUri from the application configuration file (ApplicationUri in a .NET Config.xml, the applicationUri option in node-opcua, the application_uri argument in asyncua).
- Decide which one is authoritativeIf the certificate came from a CA and is deployed widely, change the configuration to match it. If the ApplicationUri is what other systems reference - in a GDS registration, a trust list or an audit trail - reissue the certificate instead.
- Align the configuration if that is the cheaper sideSet ApplicationUri to the exact URI string from the certificate SAN, character for character, and restart. This is the fastest way out of an outage and needs no new trust distribution because the thumbprint does not change.
- Otherwise reissue the certificate with the URI in the SANFor example openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 730 -nodes -subj "/CN=MyServer/O=MyCompany" -addext "subjectAltName=URI:urn:plant:plc-01:server,DNS:plc-01.plant.local". Keep the DNS entries so you do not trade this error for BadCertificateHostNameInvalid.
- Redistribute the new certificateA reissued certificate has a new thumbprint, so every peer trust store that held the old one needs updating. If a Global Discovery Server manages your PKI, request the certificate through it so the ApplicationUri comes from the registration record and cannot drift.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | The ApplicationUri lives in ApplicationConfiguration.ApplicationUri; the stack will substitute the local hostname where the configuration contains the hostname placeholder. If you let it substitute, the certificate SAN must contain the substituted result, not the placeholder. |
| asyncua (Python) | Set server.set_application_uri("urn:plant:plc-01:server") and generate the certificate with the same URI. On the client side, Client.application_uri must match the client certificate you load with load_client_certificate, or the server rejects the client with this code. |
| node-opcua | OPCUAServer and OPCUAClient both take applicationUri, and the built-in certificate manager will generate a self-signed certificate whose SAN URI is derived from it. Regenerating after changing applicationUri is the reliable sequence; changing one without the other is what produces this error. |
| open62541 (C) | The application URI is set in the server or client config description and must match the URI in the certificate you pass to UA_ServerConfig_setDefaultWithSecurityPolicies. open62541 checks this, and a mismatch is a hard failure rather than a warning. |
| UaExpert | UaExpert's own client certificate carries its ApplicationUri. If a server rejects UaExpert with this code, regenerate UaExpert's application certificate from Settings, Manage Certificates rather than editing anything on the server. |
| OPC Publisher | Publisher's documented certificate recipe puts the ApplicationUri in the SAN as a URI: entry alongside the DNS name, and its ApplicationUri is configurable. When Publisher runs in a container with a persistent pki volume, the URI and certificate stay aligned across restarts. |
What it looks like in the log
Certificate validation failed. Error: BadCertificateUriInvalid. The URI specified in the ApplicationDescription does not match the URI in the certificate.
ApplicationUri mismatch: description 'urn:plant:plc-01:server' certificate SAN 'urn:PLC01:plant:plc-01:server'Confirm the fix
Reconnect and confirm the session activates. Then read the server's ServerStatus or the ApplicationDescription returned by FindServers and confirm the ApplicationUri it reports is the same string as the certificate SAN URI entry.
Stop it happening again
Treat ApplicationUri as an identity that is fixed at commissioning, keep it in the same configuration record used to request the certificate, and never copy a certificate and key pair between application instances.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.