Files
Cristi Pogacean 2cdf0de97f Fix scoped certificate-store resolution in GDS push operations (#4726)
# Description

Fix the remaining GDS push certificate paths that bypass instance-scoped
certificate stores, while preserving OPC UA 1.05.07 trust and
transaction requirements.

- Use the configured resolver/registry for previous-key loading, slot
resolution, application-store commit/rollback, issuer
import/compensation, and rejected-store opening.
- Validate application-certificate uploads through the configured
manager and the group's registered trust scope, instead of a temporary
manager that cannot see custom providers.
- Isolate per-call `AcceptError` validation cores from normal cached
trust decisions. Part 12 installation-time acceptance must neither reuse
nor populate the connection-validation cache.
- Compensate the application-certificate swap if opening the issuer
store fails, not only if importing an issuer fails.
- Add scoped-provider, cross-group trust, cache-isolation, and
compensation regressions. Reuse the portable PEM writer and short
temporary PKI paths so the tests work on .NET Framework too.
- Use source-generated failure logging without private-key bytes, and
document custom-store/pending-key requirements.

The branch starts at master `7f14fb864fc93532f3dbab1e1b5e2ba9b5f605c5`.
It excludes the unrelated LocalizedText commits, the local handoff, PLC
changes, logs, keys, certificates, and build outputs. No public API,
dependency, package version, global provider registration, or analyzer
configuration is changed.

### Specification review

The online Part 12 reference identifies version **1.05.07**. This is a
focused review and regression validation of the changed behavior, **not
a claim of complete stack conformance or CTT certification**.

| Requirement | Review / evidence |
| --- | --- |
| [Part 12,
7.10.5](https://reference.opcfoundation.org/specs/OPC-10000-12/7.10.5):
validate application certificates using the associated TrustList; ignore
the supplied issuer list | Existing issuer-argument regressions
retained. New flat-layout scoped-provider cases accept a CA installed in
the selected trusted/issuer store and reject one installed only in
another scope. |
| [Part 4,
6.1.3](https://reference.opcfoundation.org/specs/OPC-10000-4/6.1.3) and
Part 12, 7.10.5: suppressible installation errors must not bypass normal
peer trust or non-suppressible failures | Missing-issuer,
signature/revocation, explicit-trust, and validation-core tests; new
two-way cache-isolation cases with `UseValidatedCertificates = true`;
normal peer validation remains untrusted after issuer-only push
acceptance. |
| Part 12, 7.10.5: matching private key, encrypted channel and
SecurityAdmin | Existing access/key/type tests retained; scoped
own-store upload cases cover no uploaded key and PEM. PFX and
regenerated-key cases remain in the selected suite. |
| [Part 12,
7.10.2](https://reference.opcfoundation.org/specs/OPC-10000-12/7.10.2),
[7.10.9](https://reference.opcfoundation.org/specs/OPC-10000-12/7.10.9),
and
[7.10.11](https://reference.opcfoundation.org/specs/OPC-10000-12/7.10.11):
staging, ApplyChanges, cancellation, ownership and compensation |
Push/transaction/rollback suites; new custom-provider compensation cases
cover both issuer-import and store-open failure, retaining the old
application certificate and pre-existing issuers. |
| [Part 12,
7.10.7](https://reference.opcfoundation.org/specs/OPC-10000-12/7.10.7):
do not delete endpoint-referenced certificates | Existing ApplyChanges
endpoint-reference and delete/create replacement tests retained. |
| [Part 12,
7.10.10](https://reference.opcfoundation.org/specs/OPC-10000-12/7.10.10):
CSR key handling and persistence | Existing-key scoped CSR test, SDK
pending-key/cancel cases, and supporting PLC encrypted round
trips/restarts. Arbitrary custom backends still require a durable
pending-key implementation; the separate PLC implementation is not
included here. |

### Validation

Windows, .NET SDK 10.0.401, Release, NUnit/VSTest. Build analyzers
remained enforced: **no `WarningsNotAsErrors`, suppressions, or analyzer
downgrades**. `NuGetAudit=false` was needed because the local nuget.org
TLS connection failed; no repository audit setting was changed.

| Selection | Result |
| --- | --- |
| SDK GDS push/trust/transaction/rollback, net10.0 | **192 passed, 0
failed** |
| SDK certificate-manager/provider/explicit-trust/validation-core,
net10.0 | **180 passed, 0 failed** |
| SDK certificate-manager/provider/explicit-trust/validation-core, net48
| **180 passed, 0 failed** |
| SDK GDS push/trust/transaction/rollback, net48 | **192 passed, 0
failed** |
| Final portable-PEM/compensation tests, net10.0 | **5 passed, 0
failed** |
| Supporting PLC GDS/pending-key/compatibility selection, net10.0 | **29
passed, 0 failed** against this SDK source |

The PLC tests exercise encrypted UA calls, signed PEM/CSR updates,
persistence, fresh connections and restarts across Directory,
FlatDirectory and KubernetesSecret providers. The Kubernetes API is an
in-memory double, **not a real Kubernetes deployment**. PLC tests and
its durable pending-key implementation are local companion-repository
changes, not SDK PR contents or independently reproducible CI evidence
from this branch alone.

Commands below use the same isolated artifact locations as the
validation run, expressed relative to the user profile:

```powershell
$files = Join-Path $env:USERPROFILE '.copilot\session-state\003a7438-0312-4c10-beed-cd95c0fe400e\files'
$sdk = Join-Path $files 'sdk-build'
$net48 = Join-Path $files 'solution-net48'
$push = 'FullyQualifiedName~ConfigurationNodeManagerPushTests|FullyQualifiedName~ConfigurationNodeManagerPushValidationTests|FullyQualifiedName~PushComplianceRegressionTests|FullyQualifiedName~PushRollbackCancellationRegressionTests|FullyQualifiedName~PushConfigurationTransactionCoordinatorTests'
$manager = 'FullyQualifiedName~CertificateManagerTests|FullyQualifiedName~CertificateManagerExplicitTrustTests|FullyQualifiedName~CertificateManagerProviderResolutionRegressionTests|FullyQualifiedName~CertificateValidationCoreTests'

# Passed: 192/192.
dotnet test .\tests\Opc.Ua.Server.Tests\Opc.Ua.Server.Tests.csproj -c Release -f net10.0 -m:1 --no-restore -p:GeneratePackageOnBuild=false -p:UseArtifactsOutput=true "-p:ArtifactsPath=$sdk" -p:NuGetAudit=false --filter $push

# Passed: 180/180.
dotnet test .\tests\Opc.Ua.Core.Tests\Opc.Ua.Core.Tests.csproj -c Release -f net10.0 --no-build --no-restore -p:UseArtifactsOutput=true "-p:ArtifactsPath=$sdk" --filter $manager

# Passed: 180/180.
dotnet test .\tests\Opc.Ua.Core.Tests\Opc.Ua.Core.Tests.csproj -c Release -f net48 --no-build --no-restore -p:CustomTestTarget=net48 -p:UseArtifactsOutput=true "-p:ArtifactsPath=$net48" --filter $manager

# Passed: 192/192 after the portable PEM writer and shorter temporary PKI paths.
dotnet test .\tests\Opc.Ua.Server.Tests\Opc.Ua.Server.Tests.csproj -c Release -f net48 -m:1 --no-restore -p:CustomTestTarget=net48 -p:GeneratePackageOnBuild=false -p:UseArtifactsOutput=true "-p:ArtifactsPath=$net48" -p:NuGetAudit=false --filter $push

# Passed: 5/5 after final test portability changes.
dotnet test .\tests\Opc.Ua.Server.Tests\Opc.Ua.Server.Tests.csproj -c Release -f net10.0 -m:1 --no-restore -p:GeneratePackageOnBuild=false -p:UseArtifactsOutput=true "-p:ArtifactsPath=$sdk" -p:NuGetAudit=false --filter 'FullyQualifiedName~CertificatePushUsesScopedOwnStoreProviderAsync|FullyQualifiedName~ApplyCertificateSlotChangeSelfCompensatesWhenIssuerImportFailsAfterAppCertSwapAsync'

# Passed: 29/29; the companion project and this SDK had been built together first.
dotnet test C:\src\iot-edge-opc-plc\tests\opc-plc-tests.csproj -c Release --no-build --no-restore -p:UseLocalOpcUaStack=true -p:OpcUaSourceRoot=C:\src\UA-.NETStandard -p:UseArtifactsOutput=true "-p:ArtifactsPath=$sdk" --filter 'FullyQualifiedName~GdsPush|FullyQualifiedName~PlcPendingCertificateKeyStoreTests|FullyQualifiedName~PreviewCompatibilityTests'
```

The `--no-restore` / `--no-build` invocations require prior
restoration/build. The initially empty artifact-directory `--no-restore`
invocation produced no test execution and is **not** counted. Initial
compile/test portability failures were fixed before the final results
above.

Full-solution attempts did **not** pass:

```powershell
# Failed/incomplete: AMB server startup timed out in two tests; stopped after failures.
dotnet test .\UA.slnx -c Release -f net48 -m:1 -p:CustomTestTarget=net48 -p:GeneratePackageOnBuild=false -p:UseArtifactsOutput=true "-p:ArtifactsPath=$net48" -p:NuGetAudit=false

# Failed: NU1301 restoring OpenUsd-related projects due to nuget.org TLS handshake failure.
dotnet test .\UA.slnx -c Release -f net10.0 -m:1 -p:CustomTestTarget=net10.0 -p:GeneratePackageOnBuild=false -p:UseArtifactsOutput=true "-p:ArtifactsPath=$(Join-Path $files 'solution-net10')" -p:NuGetAudit=false
```

A retry through an already configured local package source progressed
further, but the OneFuzz nested publish did not inherit the audit
override and caused **210 setup failures (NU1900)**; the broad run was
stopped. These runs are not a clean full-suite result. AMB startup
failures have not been baseline-qualified and are not claimed to be
fixed by this PR.

`git diff --check` passed. A changed-file whitespace check reported
seven pre-existing diagnostics at lines 371-424 of
`CertificateManagerTests.cs`, outside this change (new tests start at
line 563); no unrelated formatting sweep was made.

**Remaining gates:** successful full solution on net48/net10.0,
quantitative coverage, Linux, required CI/CodeQL, and applicable
CTT/interoperability qualification. Keep this PR draft until the
required gates are resolved; the tests above do not establish 100% OPC
UA compliance.

## Related Issues

_Reference all GitHub issues this PR addresses. If there is no issue
yet, open one and link it here._

_If this is a relatively large or complex change, a design must have
been discussed in the related tracking issue and signed off (which
becomes the Architectural Decision Record (ADR))._

- Fixes #4725.
- Follow-up to #4546, #4530 and #4531 for remaining certificate-push
consumers.

## Checklist

_Put an `x` in the boxes that apply. You can complete these step by step
after opening the PR._

- [x] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [x] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [x] I have added all necessary documentation.
- [x] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed.
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [ ] I have addressed **all** PR feedback received.

Tests were added and pass as recorded, but coverage was not measured.
CLA status is not asserted on behalf of the contributor.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-10-09 21:41:58 +02:00
..

OPC UA .NET Standard stack documentation

These guides lead from a first working application to advanced and experimental capabilities. Follow the numbered stages when you are learning. Choose only the paths that match your application, or use the contents list to find a feature.

Contents

How to use this index

Each stage builds on the earlier ones, but you do not need to read every guide. After stage 1, choose the client, server, or PubSub path. Stages 3 to 7 are optional; use the guides your application needs. A stage or group names the knowledge it assumes.

Labels describe the maturity of a package or model:

  • Preview package: the package family keeps a -preview version, even when the core packages are stable. See Versioning.
  • Draft model: the guide implements a working-group draft specification. Its namespace URIs and NodeIds are provisional.
  • Experimental: the guide marks the feature as experimental.

These labels are independent of difficulty. An advanced guide can describe a stable feature, and a released specification can ship in a preview package.

1. Get started

Run a client and server, then learn the terms that the other guides use.

2. Build your application

Choose the path for your application. The paths are independent: for example, a PubSub application needs neither a client nor a server.

Client path

Assumes Getting started.

  1. Dependency injection: client feature — configure a client in the .NET Generic Host.
  2. Managed sessions — connect, recover from connection loss, and close. To compare the managed and classic session APIs, see choosing a session API.
  3. Read, write, and call methods — resolve namespace URIs and browse paths, check the status of each operation, and call methods through a client generated from the model.
  4. Subscriptions — callback subscriptions for long-lived monitoring and streams for short observations.

Server path

Assumes Getting started.

  1. Dependency injection: server feature — host a server and configure its endpoints, security, and node managers.
  2. Node managers: start with a model — generate a node manager from your model and attach callbacks. Your first information model is a complete example.
  3. Runtime NodeSets — load NodeSet2 models without generated code when models change independently of your application.
  4. Asynchronous server support — implement service and node-manager callbacks asynchronously.

PubSub path

A PubSub application needs neither a client nor a server, so the Getting started exercise and the other two paths are optional here.

  1. Concepts: client/server and PubSub — publishers, subscribers, and datasets.
  2. Run a first publisher and subscriber — exchange signed and encrypted messages on one computer with the reference PubSub sample.
  3. PubSub guide — the fluent builder, hosting, configuration, encodings, and security.
  4. Transport selection — UDP, Ethernet, MQTT, and Kafka.

3. Add data types and application services

Assumes the client or server path. Choose the capabilities your application needs.

Data types and models

Application services

4. Use companion models

Companion specifications define models for particular industries and device types; Concepts explains how they relate to the base model. These libraries assume the server path and, for typed client access, the client path. The packages load the models that each model depends on.

  • Device Integration (OPC 10000-100) — devices, topology, and locking.
  • Asset Management Basics (OPC 10000-110; preview package) — make devices, machines, pumps or scales manageable assets: discovery, identification, health alarms, maintenance, documentation links and locations. Read Device Integration first.
  • Software update (OPC 10000-100) — software package storage, installation, and confirmation. Read Device Integration first.
  • ISA-95 (OPC 10030 and OPC 10031-4) — the common model and job control.
  • Positioning (OPC 10000-210 and OPC 10000-211; preview package) — relative frames and geographic positions.
  • Machinery (OPC 40001-1, -2, -3, -4 and -101; preview package) — machines with identification, server-driven state machines, process values, job management, energy and result transfer, based on the Industrial Automation, Device Integration, PA-DIM, ECM and ISA-95 models.
  • Pumps (OPC 40223; preview package) — pumps and vacuum pumps, published both as Device Integration devices and as Machinery machines.
  • Scales (OPC 40200 and OPC 30050; preview package) — weighing technology with every scale kind, scale systems, recipes and PackML state machines, based on the Machinery model.
  • Robotics (OPC 40010-1; preview package) — motion-device systems, based on the Industrial Automation and Device Integration models. The guide's draft Robot Intent model is listed in stage 7.
  • WoT connectivity (OPC 10100-1; preview package) — connect Web of Things assets. Its registry extension is listed in stage 7.

For more examples, including the Pumps and Machinery models, see the companion-model samples.

5. Prepare for production

Builds on the certificate trust you used in Getting started. Before you deploy a client or server, work through the production readiness checklist. It links to these guides for the details:

  1. Certificates — certificate stores, trust, and chain validation.
  2. Identity providers — authenticate users on clients and servers.
  3. Role-based user management — map identities to roles and permissions.
  4. Certificate manager — certificate lifecycle, rotation, and remote updates.
  5. Diagnostics — logging, metrics, tracing, auditing, and packet capture.
  6. Rate limiting — admission limits and busy signals during connection storms.
  7. Server resource isolation — per-caller limits and reserved capacity for startup and recovery.
  8. Profiles and facets — implemented profiles and platform boundaries.
  9. Container reference server — run the reference server in a container.

6. Advanced integration, reliability, and scale

Each group names the stages it assumes.

Transports and integration

Assumes the client or server path.

Session recovery and performance

The subscription guides assume the client path; the sizing guides assume Diagnostics.

Security infrastructure and fleet management

Assumes stage 5.

High availability and deployment

Assumes a working single server and stage 5.

  • High availability (preview package) — redundancy, failover, and distributed state.
  • Replica-consistent NodeIds (preview package) — keep node identifiers identical across replicas; required before replicating an address space.
  • Kubernetes (preview package) — cluster deployment, discovery, readiness, and secrets. Read high availability first.
  • PubSub high availability (preview package) — redundant publishers and subscribers. Assumes the PubSub path.

Native AOT publishing

Publish an application as a native executable without a JIT compiler; start with Native AOT: publish an application. Feature-specific guidance:

7. Draft and experimental capabilities

These guides implement working-group drafts or experimental extensions. Namespace URIs, NodeIds, and APIs can change before the specifications are published, so evaluate them before you depend on them in production. Each guide describes its current limitations.

  • xRegistry (draft model; preview package) — the generic registry base model, resource storage, and federation.
  • AI model management (draft model; preview package) — model catalogues, deployments, inference, and learning jobs. Builds on xRegistry.
  • Vision (draft model; preview package) — perception, media, feedback, and client workflows.
  • Robot Intent (draft model; preview package) — task-level motion commands. Does not require the Robotics model.
  • OpenUSD (draft models; preview package) — bind values to OpenUSD scenes and materialize scenes in the address space.
  • WoT Connectivity 1.1 registry (draft model; preview package) — registry and materialization. Read WoT connectivity first.
  • KeyCredential issued-token bridge (experimental).

These samples combine several draft or preview capabilities. Read the guides for their models first:

  • Bin picking cell — Robot Intent, Vision, and an OpenUSD scene.
  • Visual inspection cell — Vision, AI model management, and ISA-95 job control.
  • WoT aggregation sample — load Device Integration, Machinery, and Pumps models from WoT documents through the WoT Connectivity 1.1 registry, and bind them to two OPC UA source servers.
  • Generator sample model (draft model) — generating-set simulation and scene composition.

Reference and upgrade

The Windows Forms reference applications are maintained in the Samples repository.

Contributing and maintaining the SDK

These documents describe building and maintaining this repository, not using the SDK in an application: