IEC 62541 · Utility

Part 12: Discovery and Global Services

Document number	OPC 10000-12
IEC designation	IEC 62541-12
Colloquially	Part 12
Group	Utility

Discovery

A Local Discovery Server runs on a host, listens on port 4840, and answers FindServers so a client can enumerate the OPC UA servers on that machine. Servers register themselves with it through RegisterServer and must re-register periodically. FindServersOnNetwork extends this across a subnet using multicast DNS, returning servers along with their capability codes so a client can filter for the ones implementing a particular companion model before connecting to any of them.

The Global Discovery Server and certificate management

A GDS is the enterprise-scale counterpart: it registers applications, issues their certificates and distributes trust lists. Two models exist. In the pull model the application asks the GDS for a certificate and fetches its trust list itself. In the push model an operator or tool pushes a certificate and trust list into the device, using the ServerConfiguration object and the TrustList object that a push-capable server exposes in its own address space. Certificate groups and certificate types let one application hold separate RSA and elliptic-curve identities.

Credentials and authorisation beyond OPC UA

Later editions add two services that reach outside the protocol. A key credential service issues an application the credentials it needs for a non-OPC-UA service, typically an MQTT broker or a REST API, so a device does not need broker passwords baked into its firmware. An authorisation service issues access tokens in an OAuth2-shaped request and finish flow, which is the mechanism behind the IssuedToken user identity type.

The PKI layout on disk

An annex defines the folder structure every mainstream stack implements, and knowing it is the difference between fixing a trust problem in a minute and guessing for an afternoon. Under a PKI root there are separate stores: own holds this application's certificate and private key; trusted holds trust anchors, meaning self-signed peers or a CA you have decided to trust; issuer holds CA certificates needed only to complete a chain, without conferring trust; rejected parks certificates that failed validation. The user and HTTPS variants repeat the trusted and issuer split for user certificates and transport certificates. Each store has certs, private and crl subfolders.

What it defines

Concept	What it is
Local Discovery Server	A per-host service on port 4840 that answers FindServers for the servers registered with it. Advertises its own discovery facet.
FindServers and RegisterServer	The registration loop. A server re-registers on a timer, so a server that appears and then disappears from a discovery list is usually failing to renew.
FindServersOnNetwork	Subnet-wide discovery over multicast DNS, returning capability codes alongside each server so you can filter by companion model before connecting.
Global Discovery Server	Application registration plus certificate authority plus trust-list distribution. The answer to managing certificates across hundreds of devices.
Pull and push models	Pull: the application requests its own certificate and trust list. Push: a tool writes them into the device through ServerConfiguration and TrustList. Devices support one, the other, or neither.
TrustList object	The address-space representation of a trust list, with methods to open, read, write and close it plus a version counter. This is how a trust list is updated over OPC UA itself.
Certificate groups and types	Let one application hold distinct identities and trust lists per key type, so an RSA and an elliptic-curve certificate coexist without collision.
Key credential service	Issues an application credentials for a non-OPC-UA service such as an MQTT broker, so secrets are provisioned rather than configured by hand.
Authorisation service	Issues access tokens through a request-and-finish flow, backing the IssuedToken user identity type used for JWT and OAuth2 logins.
Standard PKI stores	own, trusted, issuer, rejected, and the trustedUser, issuerUser, trustedHttps and issuerHttps variants, each with certs, private and crl subfolders.

Do you need to read it?

Whoever owns certificates on a site, and whoever has to make a fleet of devices trust each other without visiting each one. Commissioning engineers need the PKI store semantics, because that is where trust problems are actually solved. Architects need the pull and push distinction before selecting hardware, since it is a device capability you cannot add later.

Traps that trace back to this part

• The issuer store is not a trust store. Dropping a CA certificate into issuer completes the chain but confers no trust, so validation proceeds to the end and still returns BadCertificateUntrusted against a chain that looks perfect. Trust anchors belong in trusted; issuer is only for intermediates you need in order to build the path.
• The rejected store is a workflow, not a log. A peer certificate that failed validation is written there so an administrator can inspect it and promote the file into trusted. A large share of cannot-connect tickets are one file move, and engineers who do not know the store exists instead regenerate certificates.
• In a container, the PKI directory must be a persistent volume. Otherwise every restart generates a fresh application instance certificate with a fresh key, the peer's trust list still holds the old one, and a system that worked yesterday fails after an unrelated redeploy.
• Every CA certificate in a chain is expected to assert both keyCertSign and cRLSign in its KeyUsage extension. Corporate CAs routinely omit cRLSign, and strict stacks then reject the chain with a bare BadCertificateInvalid that names nothing useful. Check the issuing CA's key usage before suspecting the leaf certificate.

Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.