Trust list
In OPC UA, the trust list is the set of certificates an application accepts as trust anchors: self-signed peer certificates, or the root and sub-CA certificates that issued them. It is one of four PKI stores - trusted, issuer, rejected and crl - and trust is per application instance and per direction.
Trusted is not the same as issuer
The trusted store holds anchors: putting a certificate there means you accept it, or anything it issued. The issuer store holds intermediate and root CA certificates needed only to complete a chain, and being in issuer does not confer trust. The usual working pattern with a two-tier PKI is the root in trusted and the sub-CA in issuer. Getting these two backwards produces BadCertificateUntrusted on a chain that looks complete, or BadCertificateChainIncomplete on one you thought you had trusted.
Trust is mutual and per instance
On a Sign or SignAndEncrypt channel both applications authenticate, so the client must trust the server's certificate and the server must trust the client's. Half-configured trust is the single most common OPC UA support ticket, and it presents asymmetrically: the connection is refused on the second handshake step, so the client-side log often blames the server. Each installed instance has its own stores, so ten clients on ten machines mean ten trust operations unless you are using a CA.
Where the stores physically are
The standard layout is a pki root containing certs, private and crl subdirectories and the own, issuer, trusted and rejected stores, with parallel issuerUser and trustedUser stores for user certificates and issuerHttps and trustedHttps for HTTPS transport certificates. Windows products commonly keep the application certificate in an X509Store instead, with the trust stores under %CommonApplicationData%\OPC Foundation\pki. Find the real path before editing anything - editing the wrong copy is a whole wasted session.
Managing it at fleet scale
Hand-copying certificates does not survive twenty devices. Part 12 defines a TrustList object on the server so a Global Discovery Server can push the list, and the pull model where a device requests its own certificate from the GDS. Either way you converge on trusting one issuer rather than n peers. Whichever route you take, keep the trust list under configuration management: an undocumented trust list is an undocumented access-control list.
Example
The standard PKI layout, and which directory means what
pki/
own/certs/ MyUaClient_[thumbprint].der # this instance's certificate
own/private/ MyUaClient_[thumbprint].pfx # its private key - protect this
trusted/certs/ PlantRootCA.der # anchors: accepted, and so is anything they issued
plc01_selfsigned.der
issuer/certs/ PlantSubCA_Line3.der # chain completion only - NOT trusted
issuer/crl/ PlantSubCA_Line3.crl
rejected/certs/ unknown_server_[thumbprint].der # parked here for an admin to promote
crl/ PlantRootCA.crlDefined in: Part 2 - Security Model; Part 12 - Discovery and Global Services for the TrustList object.
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.