Application instance certificate
In OPC UA, an application instance certificate is the X.509v3 certificate that identifies one installed instance of a client or server. Its Subject Alternative Name must contain the application's ApplicationUri as a URI: entry plus the endpoint's DNS names or IP addresses, and it is what authenticates the application on every secure channel.
The requirements that are actually checked
X.509 version 3. The SAN must carry the ApplicationUri as a URI: entry, and it must match the ApplicationUri in the ApplicationDescription exactly, character for character - a mismatch is BadCertificateUriInvalid. The SAN must also carry the hostname or IP the client used, or you get BadCertificateHostNameInvalid. KeyUsage must include digitalSignature for signing and dataEncipherment for RSA key transport. Minimum RSA key size is 2048 bits. It is not a TLS certificate and a web-server certificate will not substitute.
Where the key and certificate live
The instance certificate and its private key go in the own store of the PKI directory, alongside the trusted, issuer, rejected and crl stores. On Windows the reference stack keeps application certificates in the X509Store CurrentUser\UA_MachineDefault, visible in certmgr.msc, with the trust stores under %CommonApplicationData%\OPC Foundation\pki - usually the hidden C:\ProgramData. On Linux and macOS the equivalent is under %LocalApplicationData%/OPC Foundation/pki. Knowing which of the two a product uses saves an afternoon.
Self-signed, CA-issued, or provisioned
A self-signed instance certificate works: each peer promotes it into their trusted store and the pair is authenticated. It does not scale, because trust is O(n squared) and there is no revocation path. A CA-issued certificate lets you trust one issuer instead of n peers, at the price of needing the issuer store and CRLs configured. For a fleet, provision through a Global Discovery Server using the pull or push model rather than by hand.
The private key is not required to be in a file
A private key can live in a TPM, a smart card, an HSM or a remote key service and never enter process memory. The reference stack exposes a pluggable CryptoProvider and a PKCS#11 package for hardware tokens. That matters where a compromised edge gateway must not yield a reusable machine identity - and it is worth asking a vendor about, because the answer is usually a flat file with 0644 permissions.
Example
Generating a conformant self-signed instance certificate - the SAN line is the part people get wrong
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 730 -nodes \
-subj "/CN=MyUaClient/O=Contoso" \
-addext "subjectAltName=URI:urn:edge01:Contoso:MyUaClient,DNS:edge01,DNS:edge01.plant.local,IP:10.20.3.11" \
-addext "keyUsage=nonRepudiation,digitalSignature,keyEncipherment,dataEncipherment" \
-addext "extendedKeyUsage=clientAuth,serverAuth"
# verify what you actually produced before shipping it:
openssl x509 -in cert.pem -noout -text | grep -A2 "Subject Alternative Name"
# URI:urn:edge01:Contoso:MyUaClient, DNS:edge01, DNS:edge01.plant.local, IP Address:10.20.3.11Defined in: Part 2 - Security Model; Part 4 - Services for the validation rules; Part 6 - Mappings for the certificate requirements.
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.