Issuer store

The distinction that makes two-tier PKI work

With a root CA and a sub-CA per line, you put the root in trusted and each sub-CA in issuer. Chain building then walks peer certificate to sub-CA to root, and the root is an anchor, so the chain validates. Put the sub-CA in trusted instead and you have anchored trust at the intermediate, which works but silently widens or narrows your trust boundary in ways nobody documented. Put it in neither and the chain cannot be completed at all.

CRLs live here too

Each CA in the issuer store needs its current revocation list in the matching crl directory. A missing or expired CRL does not produce a clear message: you get BadCertificateRevocationUnknown for the peer certificate or BadCertificateIssuerRevocationUnknown for a CA in its chain. Both are suppressible, so a lenient client connects and a strict one does not, which is why the same certificate works in UaExpert and fails in your production client.

The corporate-CA failure

OPC UA requires every CA certificate in a chain to assert both keyCertSign and cRLSign in its KeyUsage extension. Many corporate and cloud-issued CAs set keyCertSign and omit cRLSign, because for TLS nobody cares. Strict OPC UA stacks reject such a CA, often with an unhelpful BadCertificateInvalid that names the peer certificate rather than the CA. If the enterprise PKI team says the certificate is fine, this is the extension to ask them about.

Parallel stores for other purposes

There are two more pairs. issuerUser and trustedUser apply the same split to X.509 user identity tokens, so the CA that issues machine identities need not be the CA that issues operator identities. issuerHttps and trustedHttps do the same for HTTPS transport certificates. Products differ in which of these they actually implement, and putting a user CA into the application issuer store is a common wasted hour.

Example

Checking the KeyUsage bits on a CA certificate before blaming the peer

openssl x509 -in issuer/certs/PlantSubCA_Line3.der -inform der -noout -text \
  | grep -A2 "X509v3 Key Usage"

  X509v3 Key Usage: critical
      Certificate Sign

# Missing CRL Sign. OPC UA requires keyCertSign AND cRLSign on every CA in the chain.
# Strict stacks reject this and usually report BadCertificateInvalid.

# also confirm the CRL is present and current:
openssl crl -in issuer/crl/PlantSubCA_Line3.crl -noout -lastupdate -nextupdate

Defined in: Part 12 - Discovery and Global Services, PKI store layout; Part 6 - Mappings for the CA KeyUsage requirement.

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.