Status code · Certificates
BadCertificateHostNameInvalid
BadSAN / hostname
BadCertificateHostNameInvalid means the host part of the endpoint URL you dialled does not appear in the server certificate's Subject Alternative Name. Either connect using a name that is in the SAN, or reissue the certificate with every DNS name and IP address clients will actually use.
Defined behaviour: The HostName used to connect to a server does not match a HostName in the certificate. (our description of the condition this code reports)
What you actually see
The channel opens far enough to validate the certificate and then fails with a domain or hostname mismatch, typically right after you switch from a hostname to an IP address or vice versa.
Why it happens
- You connected by IP but the SAN only lists a DNS nameValidation step 6 compares the host component of the endpoint URL against the DNS and IP entries in the certificate's Subject Alternative Name extension. opc.tcp://192.168.10.24:4840 will not match a SAN containing only DNS:plc-01.plant.local. There is no implicit resolution - the strings are compared, not the addresses.
- Short name versus fully qualified domain nameA SAN entry of DNS:server01.corp.example.com does not satisfy a connection to opc.tcp://server01:4840, and the reverse is equally true. Stacks differ in how strictly they treat the short-name case, so a client that worked stops working after an SDK upgrade.
- The certificate was generated on a host that has since been renamed or clonedSelf-signed application instance certificates are usually generated once, using the machine name at that moment. Renaming the host, moving the server into a container with a random hostname, or cloning a VM leaves a certificate whose SAN names a machine that no longer exists.
- Traffic arrives through NAT, a load balancer or a reverse proxyClients dial the external name or the NAT address, but the certificate was issued for the internal name the server knows about. Every externally visible name and address needs to be in the SAN, because the client compares against the URL it dialled, not the one the server thinks it has.
- The SAN has the name only in the Subject CNA common name of CN=plc-01.plant.local is not a substitute. OPC UA domain validation reads the subjectAltName extension. Certificates produced by tooling that still relies on CN alone fail this check even though the name looks correct in a certificate viewer.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read the SAN out of the server certificateExport the server certificate (UaExpert's Manage Certificates dialog, or the file in the rejected store) and run openssl x509 -in server.der -inform der -noout -text, then look at the X509v3 Subject Alternative Name block. Note every DNS, IP and URI entry it contains.
- Compare it to the exact URL you are diallingTake the host component of your endpoint URL verbatim - not the resolved address - and check it appears as a DNS or IP entry. This one comparison decides the whole case, and it is usually obvious once both strings are side by side.
- If you control the client, dial a name that is in the SANThis is the fast outage fix. Add a hosts-file or DNS entry so the SAN name resolves to the right address, then connect using that name. Be aware the server also advertises its own EndpointDescription.EndpointUrl, which may push you back to a different host string.
- Otherwise reissue the server certificate with a complete SANGenerate with every name clients use, for example -addext "subjectAltName=URI:urn:plant:plc-01:server,DNS:plc-01.plant.local,DNS:plc-01,IP:192.168.10.24". Keep the URI entry - dropping it converts this problem into BadCertificateUriInvalid.
- Redistribute and re-trustInstall the new certificate as the server's own certificate, then update every client's trusted store because the thumbprint has changed. Restart the server so the new certificate is presented in OpenSecureChannel.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | UaExpert reports the mismatch in the certificate validation dialog and names both the URL host and the certificate entries. You can accept it for the session because this error is suppressible, which is fine for diagnosis and wrong for production. |
| UA-.NETStandard (C#) | Domain validation happens in CertificateValidator and the error is suppressible via the CertificateValidation event. The application configuration has no switch to relax hostname checking independently, so the honest fix is a correct SAN. |
| asyncua (Python) | The server builds its endpoint URL from the hostname it detects; set it explicitly with Server.set_endpoint("opc.tcp://plc-01.plant.local:4840/freeopcua/server/") so the advertised URL and the certificate SAN agree. asyncua's certificate helper can write SAN entries when you generate a self-signed certificate. |
| node-opcua | OPCUAServer takes alternateHostname so the server can advertise several endpoint URLs; the certificate must carry all of them in its SAN. node-opcua's certificate manager generates SAN entries from the supplied applicationUri and hostnames. |
| OPC Publisher | Publisher connects to the URL in its configuration file, so a mismatch here is a configuration-versus-certificate question. The documented openssl recipe includes both the URI and DNS SAN entries for exactly this reason. |
| Siemens S7-1500 | The controller's certificate is generated from the device configuration in TIA Portal. If you address the PLC by IP but the certificate was built around a device name, regenerate it in the security settings with the IP address included rather than trying to relax the client. |
What it looks like in the log
Certificate validation failed. Error: BadCertificateHostNameInvalid. The HostName used to connect to a server does not match a HostName in the certificate.
Domain validation failed: endpoint host '192.168.10.24' not found in certificate SAN [DNS:plc-01.plant.local]Confirm the fix
Connect using the exact URL again and confirm the session activates, then re-run the same connection from a second client on a different subnet to prove the SAN covers every name in use.
Stop it happening again
Standardise on FQDN endpoint URLs, and make SAN generation part of your certificate template so every application instance certificate carries the URI entry plus all DNS names and IPs the device is reachable on.
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.