Subject Alternative Name

Two checks, two different status codes

Certificate validation performs domain validation and ApplicationUri validation as distinct steps. Domain validation compares the host part of the endpoint URL the client actually used against the DNS and IP entries in the SAN, and fails with BadCertificateHostNameInvalid. ApplicationUri validation compares the URI: entry against the ApplicationUri in the ApplicationDescription, and fails with BadCertificateUriInvalid. Both are suppressible through a validation callback, which is why an auto-accept client appears to work and a correctly configured one does not.

List every name a peer might use

Clients connect by short hostname, by fully qualified name, by IP address, through a NAT address, and through a reverse-connect endpoint - and each of those is a different string. The Common Name in the subject DN is not consulted for this check at all; only the SAN is. So a certificate whose SAN carries DNS:plc01 fails the moment someone types opc.tcp://plc01.plant.local:4840 or the IP address. Enumerate the real access paths before you issue, including the ones your maintenance laptop will use.

Getting the URI entry right

The URI: entry is a full URI, normally shaped as urn:hostname:vendor:application, and it must be byte-identical to the ApplicationUri the application reports. Products build that string from the machine hostname at first start, so renaming a host, cloning a VM or moving to a container with a random hostname silently changes the ApplicationUri while the certificate keeps the old one. Read the ApplicationUri out of the running application, do not assume the configured value.

Reissue rather than edit

The SAN is inside the signed certificate, so it cannot be corrected without generating a new certificate and having every peer trust it again. Plan the name list once, per environment, and keep it in the deployment configuration rather than in an engineer's shell history. Where names really do change, that is the argument for a Global Discovery Server issuing certificates rather than hand-rolled openssl.

Example

Reading the SAN out of a peer certificate that is being rejected

openssl x509 -in rejected/certs/MyUaServer_[thumbprint].der -inform der -noout -text \
  | grep -A3 "Subject Alternative Name"

  X509v3 Subject Alternative Name:
      URI:urn:plc01:Contoso:MyUaServer, DNS:plc01

# Client connected to opc.tcp://10.20.3.11:4840  -> no IP entry -> BadCertificateHostNameInvalid
# ApplicationDescription says urn:plc01.plant.local:Contoso:MyUaServer
#                                  -> URI entry differs   -> BadCertificateUriInvalid

Defined in: Part 6 - Mappings, certificate requirements; Part 4 - Services for the validation steps.

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.