Rejected store
In OPC UA, the rejected store is the PKI directory where an application parks a certificate it just refused. It exists for one purpose: to give an administrator the exact peer certificate to inspect and promote into the trusted store, without needing access to the peer machine or a second connection attempt.
It is a workflow, not a quarantine
The last step of certificate validation is to write the failing certificate to the rejected store. That turns first-contact trust bootstrapping into a two-step, auditable procedure: the client attempts a secure connection and fails, the administrator finds one new file in rejected, checks its subject, thumbprint and SAN against what was expected, and moves it into trusted. The next attempt succeeds. This is the intended and supported way to establish trust between two applications, and it is why auto-accept is never necessary.
How to read it
Files are named after the application and the certificate thumbprint, so the thumbprint is what you match against the peer's own record of its certificate. Verify the thumbprint out of band - from the device's own configuration page or from the engineer who generated it - before promoting. Promoting whatever appeared in rejected without checking is auto-accept with extra steps, and gives the same man-in-the-middle exposure.
It is also your best diagnostic
A populated rejected store proves the handshake reached certificate validation, which rules out routing, firewall and endpoint-URL problems immediately. An empty rejected store during a failing secure connection tells you the opposite: the failure happened before validation, so look at the transport, the endpoint URL and the policy and mode match. Checking both PKI directories - yours and the peer's - is the fastest way to work out which side is refusing whom.
Housekeeping
Nothing prunes it. On an internet-exposed or scanned server it fills with certificates from every probe, and on a fleet it fills with certificates from applications regenerating their identity - which is itself the signal that some container is missing a persistent pki volume. Watch the directory: a repeatedly changing thumbprint from the same application name is a non-persistent PKI, and a flood of unfamiliar names is a server that should not be reachable.
Example
The promote-from-rejected workflow on Linux
# 1. attempt the secure connection once - it fails with BadCertificateUntrusted
# 2. see what the server parked
ls -l ~/.local/share/"OPC Foundation"/pki/rejected/certs/
MyUaClient_3f9a1c...der
# 3. check it is really the peer you expect - compare subject, SAN and thumbprint
openssl x509 -in MyUaClient_3f9a1c...der -inform der -noout -subject -fingerprint -sha1
# 4. promote, then retry
mv MyUaClient_3f9a1c...der ../../trusted/certs/Defined in: Part 12 - Discovery and Global Services, PKI store layout; Part 4 - Services for the validation sequence.
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.