Files
UA-.NETStandard/docs/Profiles.md
romanett 7fe7794a19 Enable AES-GCM and ChaCha20-Poly1305 policies on net48 via BouncyCastle (stacked on #4703) (#4705)
> Follow-up to #4703 (now merged to master; this PR has been retargeted
to `master`).

Part of #4510. #4703 enabled the CBC ECC policies on net48 through a
BouncyCastle raw-ECDH polyfill. The AEAD policies were still unavailable
there because .NET Framework has no `AesGcm` or `ChaCha20Poly1305`. This
PR adds those ciphers the same way, so on net48 all of these are now
offered:
`ECC_{nistP256,nistP384,brainpoolP256r1,brainpoolP384r1}_AesGcm` /
`_ChaChaPoly`, `RSA_DH_AesGcm`, `RSA_DH_ChaChaPoly`.

## Changes
- **Polyfill**
`src/Opc.Ua.Security.Certificates/Org.BouncyCastle/AeadCiphers.cs`
(internal, `#if NETFRAMEWORK`, next to `EcdhRawAgreement`): `AesGcm` and
`ChaCha20Poly1305` types with the .NET 8 BCL surface. They wrap
BouncyCastle's `GcmBlockCipher(AesEngine)` and
`Org.BouncyCastle.Crypto.Modes.ChaCha20Poly1305`.
- A tag mismatch throws `CryptographicException`, never BC's
`InvalidCipherTextException`, so
`PlatformSymmetricCryptoProvider.DecryptAuthenticated` still returns
`false` and the channel still raises a protocol error.
- GCM releases plaintext blocks before it checks the tag, so plaintext
stays in a scratch buffer and is copied out only after the tag verifies.
On failure the destination is cleared, as the BCL does. Scratch buffers
and the key copy are zeroed.
- **Opc.Ua.Core**: aliases the polyfill types on `NETFRAMEWORK` and
removes the `NET8_0_OR_GREATER` gates in `SecurityPolicies`
(`SupportsAesGcmPolicy` / `SupportsChaCha20Poly1305Policy`),
`CryptoUtils` (`SymmetricEncryptAndSign` / `SymmetricDecryptAndVerify`,
AEAD helpers) and `PlatformSymmetricCryptoProvider`. The channel, the
provider facet and the encrypted ECC user tokens (`EncryptedSecret`,
through `CryptoUtils`) now run the same code on every target. .NET 8+
keeps the BCL ciphers.
- **FIPS** (requested by the #4703 session, after a2ecf13b1): under
`CryptoCompliancePolicy.FipsOnly`, `CryptoCompliance.IsPolicyPermitted`
now also withholds every AEAD policy on .NET Framework. That adds
`RSA_DH_AesGcm`, which is FIPS-approved and not ECC. The BouncyCastle
cipher runs outside any validated module and the user-token path
bypasses the provider registry, so the auditor cannot see it. Tests and
`docs/CryptoProvider.md` are updated to match.
- **Docs**: EccProfiles (Known Limitations), migration `certificates.md`
(and the bundled skill copy), ProductionChecklist, Profiles,
WhatsNewIn2.0, CryptoProvider. They state that on net48 these primitives
run in managed BouncyCastle, which is not a validated (FIPS) module and
not hardware-accelerated or hardened against cache-timing attacks like
CNG AES.

## Tests
- New `AeadPolyfillTests` (Core.Tests):
- Known answers: NIST GCM test cases 2/4 (AES-128) and 14/16 (AES-256),
plus RFC 8439 §2.8.2 for ChaCha20-Poly1305. They run through
`PlatformSymmetricCryptoProvider` on every TFM and through the polyfill
directly.
- Tampering with the tag, the ciphertext or the AAD gives `false` from
the provider, and `CryptographicException` with a cleared plaintext from
the polyfill.
  - Argument validation.
- **BCL cross-check:** on .NET 8+, Core.Tests also compiles
`AeadCiphers.cs` (`AEAD_POLYFILL_CROSSCHECK`, test-only
`BouncyCastle.Cryptography` reference). Polyfill and BCL must produce
identical ciphertext and tag, and each must decrypt the other's output:
3 algorithms × 8 message lengths (0 to 8192) × 3 AAD lengths.
- `CryptoProviderRegistryTests`: `RSA_DH_AesGcm` is permitted under
FipsOnly only off .NET Framework and withheld on it.
- Tests that `Assert.Ignore` when AEAD is unavailable now run on net48,
e.g. `EccSecretRejectsDifferentNegotiatedPolicyAsync` and the
`RSA_DH_AesGcm` server session tests.

### Local results
| Run | Result |
|---|---|
| Core.Tests net48, full (before the FIPS commit) | 6049 passed, 0
failed, 88 skipped |
| Core.Tests crypto/AEAD/ECC/EncryptedSecret/Nonce subset, net48 /
net10.0 | 278 / 343 passed, 0 skipped |
| Server.Tests session-security/ECC subset, net48 | 128 passed, 0
skipped |
| `EccInteropTests` net48 vs **open62541 1.5.8 (OpenSSL)** peer | all 16
AEAD cases pass, 4 of them two-renewal token-renewal runs
(`ECC_nistP256_AesGcm`/`_ChaChaPoly` × Sign/SignAndEncrypt ×
Anonymous/UserName, both directions). Remaining 8 failures are the
documented open62541 CBC Sign-only HKDF differences in
`expected-differences.json` |
| `EccInteropTests` net48 vs 1.5.378 LegacyPeer | unchanged 26 passed /
28 skipped |

Note on the acceptance criterion: the 1.5.378 LegacyPeer does not
implement the AEAD policies, so its
`_AesGcm`/`_ChaChaPoly`/`*AeadTokenRenewalAsync` cases skip on every TFM
("The peer (UA-.NETStandard) does not declare …"). Before this PR they
skipped on the 2.0 side; now they get past it and stop at the peer
check. The open62541 peer is the real cross-stack check of the net48
AEAD path against a non-BouncyCastle implementation.

## PubSub DTLS on net48
The DTLS 1.3 transport (`src/Opc.Ua.PubSub.Udp/Dtls`) was compiled out
on .NET Framework, so net48 registered no DTLS profiles. It now reuses
the same polyfills (`Opc.Ua.Security.Certificates` gains
`InternalsVisibleTo Opc.Ua.PubSub.Udp`):
- The `NET8_0_OR_GREATER` gates in the handshake, ECDHE, record
protection and profile probe are removed.
- Two .NET 8 APIs get net48 fallbacks: the AES-ECB record-number mask
uses `CreateEncryptor`, and the handshake random uses
`RandomNumberGenerator.Create`.
- The HKDF probe now checks the managed `DtlsHkdf` that the key schedule
actually uses.
- The public `IsAeadSupported` / `IsRawSharedSecretSupported` probes are
kept and now return `true` everywhere.
- The DTLS tests now also run on net48. The net48 "registers no
profiles" test now asserts that the NIST AEAD profiles are registered.
The socket transport-peer tests and the benchmarks stay .NET 8-only
because they use .NET 8 socket APIs.
- `docs/PubSub.md` DTLS profile table: the net48 column is updated.

Results: PubSub.Udp.Tests net48, full suite: **229 passed, 0 skipped**.
It includes complete NIST AEAD, brainpool and integrity-only handshakes
and ChaCha20 records. The DTLS subset is 76 on net48 vs 81 on net10.0;
the 5 still-gated socket-peer tests are the difference.

Note: DTLS profile selection does not consult `CryptoCompliancePolicy`
on any target. That is pre-existing and unchanged here.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 06:30:14 +02:00

35 KiB

OPC UA Profiles and Facets Support

This document describes which OPC UA Profiles and Facets are implemented in the OPC UA .NET Standard Stack, and where in the codebase / documentation each one lives.

Overview

The OPC UA .NET Standard Stack is a reference implementation that targets OPC UA specification version 1.05.07. The stack has been certified for compliance through an OPC Foundation Certification Test Lab and is continuously tested for compliance using the latest Compliance Test Tool (CTT).

The stack ships server- and client-side support for:

  • Part 9 (Alarms & Conditions)
  • Part 11 (Historical Access) and Part 13 (Aggregates)
  • Part 16 (State Machines)
  • Part 17 (Alias Names)
  • Part 18 (Role Management)
  • Part 20 (File Transfer)
  • Part 100 (Device Integration / Software Update)
  • OPC 10100-1 (WoT Connectivity)
  • OPC 40001-1 (Industrial Automation)
  • OPC 40010-1 (Robotics)
  • The Local Discovery Server

See What's New in 2.0 for the broader change narrative.

The canonical list of all OPC UA profile and facet URIs is maintained by the OPC Foundation at https://profiles.opcfoundation.org/. Where this document hyperlinks a URI, that URI is the same string the reference server advertises in ServerProfileArray; URIs not yet present in a shipping config are referred to by name and the reader should consult the OPC Foundation registry for the canonical URI form.

Contents

Server Profiles

The reference server (samples/Reference/ConsoleReferenceServer) advertises the following profiles in its ServerProfileArray:

Core Server Profiles

  • Standard UA Server Profile (2017) — The core OPC UA Server profile that includes:
    • Basic server capabilities
    • Discovery services
    • Session management
    • Subscription management
    • MonitoredItem services
    • View services (Browse, BrowseNext, TranslateBrowsePathsToNodeIds)
    • Attribute services (Read, Write, HistoryRead, HistoryUpdate)
    • Query services

Functional Facets

Local Discovery Server (LDS) Profile

The Opc.Ua.Lds.Server library plus the ConsoleLdsServer reference application implement the Local Discovery Server. The LDS application advertises the Local Discovery Server 2017 Facet (see samples/Lds/ConsoleLdsServer/Lds.Server.Config.xml).

Additional facets supported by the implementation (beyond the default advertised set)

Beyond the seven facets advertised by default in the reference server's ServerProfileArray, the master branch implements the following facets in the SDK. They can be enabled per-application by registering the corresponding NodeManager and, where applicable, adding the matching URI to ServerProfileArray (consult https://profiles.opcfoundation.org/ for the canonical URI string before claiming a facet):

  • Alarms and Conditions (Part 9) — Full server-side implementation with latched / silenced / out-of-service alarms, alarm groups, a suppression engine, and rate metrics. The reference server's AlarmNodeManager exposes a working sample. See Alarms and Conditions.
  • State Machine (Part 16) — StateMachineBuilder and the FluentFiniteStateMachineState extensibility in src/Opc.Ua.Server/StateMachines/. The reference server's BoilerStateMachineState is an end-to-end sample. See State Machines.
  • File Access (Part 20) — Server-side FileSystemNodeManager + IFileSystemProvider in src/Opc.Ua.Server/FileSystem/. The reference server enables it via the EnableFileSystemNodeManager option. The matching System.IO-style client lives in FileSystemClient.
  • Node Management (Part 4 service set) — INodeManagementAsyncNodeManager opt-in plus a per-NodeManager AllowNodeManagement gate for AddNodes / DeleteNodes / AddReferences / DeleteReferences. See Node Management.
  • Alias Names (Part 17) — AliasNameStore and the optional AliasNameNodeManager for AliasNameCategory / FindAlias / FindAliasVerbose / AddAliasesToCategory / DeleteAliasesFromCategory / LastChange. The reference server wires the standard Aliases and Topics nodes via ConfigureAliasNameStore. See Alias Names.
  • WoT Connectivity (OPC 10100-1) — Opc.Ua.WotCon / Opc.Ua.WotCon.Server / Opc.Ua.WotCon.Client library trio for surfacing OPC UA servers as Web-of-Things Thing Descriptions. See WoT Connectivity.
  • Device Integration (Part 100) — Opc.Ua.Di / Opc.Ua.Di.Server / Opc.Ua.Di.Client library trio, including the lock service and the software-update package store. See Device Integration and Software Update.
  • Relative Spatial Location and Global Positioning (Parts 210 and 211) — Opc.Ua.Positioning / Opc.Ua.Positioning.Server / Opc.Ua.Positioning.Client implement the released RSL and GPOS models, including RSL spatial lists and model changes plus the GPOS GlobalPosition, GlobalLocation, and Zones conformance units. See Positioning.
  • Robotics (OPC 40010-1) over Industrial Automation (OPC 40001-1) — Opc.Ua.Robotics / Opc.Ua.Robotics.Server / Opc.Ua.Robotics.Client library trio implementing the released Robotics 1.02 model over IA and Device Integration, with validated fluent topology builders for motion device systems, controllers, motion devices, axes, power trains, motors, gears, drives, safety states, and task controls. See Robotics.
  • Role Management (Part 18) — Server-side role administration plus a pluggable identity-provider model for anonymous, username, X.509, and token-issuer flows. The server automatically assigns the OPC UA Part 3 §4.9 TrustedApplication role; see also Role-Based User Management.
  • Auditing — The server raises audit events for security-relevant service calls (channel/secure-channel/session/activate/cancel). The audit and redaction APIs are provided by Opc.Ua.Server.
  • Model Change Tracking — Server-side ModelChangeAggregator with auto-emitted GeneralModelChangeEvent from CustomNodeManager; client-side per-node INodeCache.InvalidateNode. See Model Change Tracking.
  • Durable Subscriptions — Subscriptions that persist across reconnects. See Durable Subscriptions.
  • Complex Types — Custom structures and enumerations; see Complex Types.
  • Async server NodeManagers — TAP-based AsyncCustomNodeManager is the recommended base for new NodeManagers, and every NodeManager shipped with the stack has migrated to it. See Async Server Support.
  • Server redundancy (Part 4 §6.6) — AddServerRedundancy(...) publishes the Server.ServerRedundancy object, drives Server.ServiceLevel, and supports every RedundancySupport mode (None / Cold / Warm / Hot / HotAndMirrored / Transparent). Non-transparent modes advertise the NTRS discovery capability and return the peer set from FindServers; RequestServerStateChange supports administrator-driven Maintenance / NoData failover. Opt-in distributed high availability — address-space, session, and subscription mirroring over an in-package CRDT (eventual) or Raft (strong) shared store, plus a Kubernetes deployment — is provided by the Opc.Ua.Redundancy, .Server, .Client, and .Kubernetes packages. See High Availability.

Client Profiles

The client (Opc.Ua.Client) supports the standard UA Client functionality through two coexisting paths:

  • Classic Session — the lowest-level OPC UA session primitive, paired with SessionReconnectHandler for caller-driven reconnect.
  • ManagedSession — recommended for new code. Encapsulates the connection state machine, reconnect policy, and pluggable subscription engine behind a fluent builder. See Sessions, Reconnection, and Subscription Engines.

Client-side feature coverage:

  • Subscriptions and monitored items — Both the classic publish engine and the V2 subscription engine (ISubscriptionManager / DefaultSubscriptionEngine) are supported and selectable per session. The V2 surface includes a declarative + imperative SetTriggering API with N:M support and automatic replay on recreate / reconnect, plus an IStreamingSubscription (IAsyncEnumerable-based) facade for state-machine waits and short-lived monitoring (ManagedSession.DefaultStreaming, TakeUntilAsync / WithTimeoutAsync helpers). See Subscriptions and Monitored Items.
  • Transfer Subscriptions — Subscription transfer between servers; see Transfer Subscriptions. An opt-in SubscriptionRecoveryPolicy lets the client tolerate Good_SubscriptionTransferred notifications from the server.
  • Reverse Connect — Client can accept connections initiated by the server; see Reverse Connect.
  • Model Change Tracking — Client-side per-node cache invalidation driven by server-emitted model-change events; see Model Change Tracking.
  • File System Operations — Async, System.IO-style client over OPC UA file methods; see FileSystemClient.
  • Alarms and Conditions — Typed AlarmClient event records, fluent AlarmEventFilterBuilder, and IAsyncEnumerable alarm streaming via AlarmStreamExtensions; see Alarms and Conditions.
  • Historical Access — HistoryClient (session.Historian()) for raw, modified (including ModificationInfo), at-time, processed (aggregate), annotation, and event history reads / updates; see Historical Access.
  • State Machines — Streaming and read helpers (GetCurrentFiniteStateAsync, ObserveFiniteTransitionsAsync, WaitForStateAsync) on the source-generated *TypeClient proxies; see State Machines.
  • NodeSet Export — Extract a server's address space to NodeSet2 XML; see NodeSet Export.
  • Source-generated typed proxies — *TypeClient proxies for ObjectTypes inside loaded models give strongly-typed method-call signatures; see Source-Generated NodeManagers.
  • Complex types — Decode and consume server-defined structures and enumerations on the client; see Complex Types.

Transport Profiles

The stack implements the following transport profiles:

Client and server transports

  • UA TCP Transport (opc.tcp://) — Primary OPC UA binary transport over TCP.

    • Full UA Secure Conversation (UASC)
    • Binary encoding
    • Reverse-connect capability
  • HTTPS Binary Transport (opc.https:// and https://) — OPC UA binary protocol over HTTPS with TLS.

  • HTTPS JSON Transport (opc.https:// and https://) - OPC UA JSON (compact / reversible) over HTTPS (OPC UA Part 6 §7.4.5)

    • Compact JSON encoding (application/opcua+uajson)
    • TLS/SSL encryption only — no UA SecureChannel layer
    • Restricted to MessageSecurityMode.None; transport security is provided exclusively by TLS
  • WebSocket Secure (UA Binary) (opc.wss:// and wss://) - UA Binary + UASC over secure WebSockets (OPC UA Part 6 §7.5.2, sub-protocol opcua+uacp)

    • Same UASC SecureChannel pipeline as opc.tcp carried over WebSocket binary frames (one frame per MessageChunk)
    • Supports all security modes (None / Sign / SignAndEncrypt)
    • TLS/SSL encryption at the WebSocket layer
  • WebSocket Secure (JSON) (opc.wss:// and wss://) - OPC UA JSON over secure WebSockets (Part 6 §7.5.2, sub-protocol opcua+uajson)

    • Compact JSON encoding per WebSocket text frame
    • TLS/SSL encryption only — no UA SecureChannel layer
    • Restricted to MessageSecurityMode.None
  • HTTPS OpenAPI (opc.https:// and https://) - OPC UA OpenAPI Mapping (Part 6 §G.3) — official OPC Foundation profile/2338, URI http://opcfoundation.org/UA-Profile/Transport/https-uajson-openapi

    • Path-routed REST surface: POST /<service> (e.g. /read, /browse, /createsubscription)
    • Body is the bare <Service>Request / <Service>Response — no {UaTypeId, UaBody} envelope at the HTTPS layer
    • Compact (default, mandatory per §5.4.9) and Verbose JSON flavours selected via the application/json; encoding=compact|verbose media-type parameter
    • TLS/SSL encryption only — no UA SecureChannel layer
    • Restricted to MessageSecurityMode.None
    • Authentication via Anonymous, Bearer JWT, HTTP Basic, or Mutual TLS (see WebApi.md)
    • Server-side discovery emission: HttpsServiceHost emits this sub-profile as a discovery-only twin alongside each SecurityMode.None HTTPS-binary endpoint, so discovery-driven clients can find the OpenAPI endpoint without hard-coding the URL.
    • Shipped as part of the OPCFoundation.NetStandard.Opc.Ua.Bindings.Https package (net8+ only)
    • Surfaced via Profiles.HttpsOpenApiTransport
  • WSS OpenAPI (opc.wss:// and wss://) - OPC UA OpenAPI Mapping over secure WebSockets (Part 6 §7.5.2, sub-protocol opcua+openapi / opcua+openapi+<accesstoken>) — official OPC Foundation profile/2339, URI http://opcfoundation.org/UA-Profile/Transport/wss-uajson-openapi

    • Same on-wire {TypeId, Body} OPC UA JSON envelope as opcua+uajson, multiplexed over WebSocket text frames; distinguished by the negotiated sub-protocol and the advertised TransportProfileUri
    • Bearer-token variant negotiates the access token in the sub-protocol name (no Authorization header — required for browser fetch compatibility); the server extracts the token from the sub-protocol name and feeds it through the standard ISessionlessIdentityProvider pipeline
    • Server-side discovery emission: the WSS factories emit this sub-profile as a discovery-only twin alongside each SecurityMode.None WSS binary endpoint, mirroring the HTTPS OpenAPI emission.
    • Client surface: src/Opc.Ua.Client/WebApi/WebApiWssTransportChannel.cs; fluent shortcut ManagedSessionBuilder.UseWssOpenApiEndpoint(url); DI registration via services.AddWebApiTransportChannel() (registers both HTTPS and WSS WebApi channel factories).
    • Surfaced via Profiles.WssOpenApiTransport

PubSub transports

The PubSub library supports the following PubSub transport facets (URIs surfaced by Profiles.PubSub*Transport constants in src/Opc.Ua.Core/Security/Constants/SecurityConstants.cs). Facet machinery and conformance unit semantics are defined by Part 7 §4.3.

  • PubSub UDP UADP — UDP transport with UADP message encoding.
  • PubSub Ethernet UADP — Ethernet (Layer 2) transport with UADP message encoding (see PubSub transports).
  • PubSub MQTT UADP — MQTT transport with UADP message encoding.
  • PubSub MQTT JSON — MQTT transport with JSON message encoding.
  • Datagram-v2 connection profile — DatagramConnectionTransport2DataType (Part 14 §6.4.1.4) is honoured for UDP transports. The DiscoveryAnnounceRate, DiscoveryMaxMessageSize, and QosCategory fields drive discovery cadence and the IP DSCP TOS byte.
  • PubSub SKS pull / push — Part 14 §8.5.1 / §8.5.2: the AddPubSubSecurityKeyServiceClient extension implements the pull client (calls GetSecurityKeys on a remote SKS), and AddPubSubSecurityKeyServiceServer hosts the in-memory SKS with Get/SetSecurityKeys and AddSecurityGroup methods bound on the address space.
  • AES-128-CTR / AES-256-CTR with HMAC-SHA-256 — Part 14 §8.4.3 message security. Profiles registered as PubSubAes128CtrPolicy / PubSubAes256CtrPolicy; conformance to NIST SP 800-38A F.5.1 / F.5.5 is asserted by the test suite.
  • Anonymous certificate-based MQTT auth — the MQTT transport exposes the MqttClientAuthenticationOptions with the certificate-based variant from Part 14 §6.4.2.2.4.

PubSub additionally supports certificate-based MQTT authentication and considers WriterGroups in MQTT keep-alive calculations.

All transport profiles defined in OPC UA Part 6 §7.4 (HTTPS) and §7.5 (WebSockets) are supported, including the opcua+openapi and opcua+openapi+<accesstoken> WebSocket sub-protocols (Part 6 §7.5.2 Table 81).

Security Profiles

The stack supports the following security profiles for secure communication. The canonical set is defined in src/Opc.Ua.Core/Security/Constants/SecurityPolicies.cs.

RSA-based security policies

  • Basic256Sha256
    • 256-bit AES encryption
    • RSA-OAEP for key encryption
    • HMAC-SHA256 for message authentication
    • Minimum key size: 2048 bits
  • Aes128_Sha256_RsaOaep
    • 128-bit AES encryption
    • RSA-OAEP for key encryption
    • HMAC-SHA256 for message authentication
  • Aes256_Sha256_RsaPss
    • 256-bit AES encryption
    • RSA-PSS signatures
    • HMAC-SHA256 for message authentication

ECC-based security policies

ECC support is documented in detail in ECC Profiles.

Traditional ECC curves

Modern ECC curves (v2.0)

AES-GCM and ChaCha20-Poly1305 variants (v2.0)

Modern AEAD cipher alternatives for traditional ECC curves:

  • ECC_nistP256_AesGcm, ECC_nistP256_ChaChaPoly
  • ECC_nistP384_AesGcm, ECC_nistP384_ChaChaPoly
  • ECC_brainpoolP256r1_AesGcm, ECC_brainpoolP256r1_ChaChaPoly
  • ECC_brainpoolP384r1_AesGcm, ECC_brainpoolP384r1_ChaChaPoly

RSA Diffie-Hellman (v2.0)

  • RSA_DH_AesGcm — RSA Diffie-Hellman key agreement with AES-GCM
  • RSA_DH_ChaChaPoly — RSA Diffie-Hellman key agreement with ChaCha20-Poly1305

Platform requirements for ECC. Certificate creation, storage, and validation are distinct from ECC SecureChannel and user-token security policies. On .NET 8.0 or later those policies use the platform's raw ECDH agreement and authenticated ciphers; on .NET Framework the agreement and the AES-GCM and ChaCha20-Poly1305 ciphers run in the managed BouncyCastle implementation. Curve and cipher availability also depends on the OS and, on .NET 8+, the runtime probes (AesGcm.IsSupported / ChaCha20Poly1305.IsSupported). See the ECC platform limitations for the certificate-operation and channel-policy boundaries. PubSub has its own transport security limits.

Deprecated security policies

The following security policies are deprecated but still supported for backward compatibility:

Note. SHA-1 signed certificates are rejected by default (RejectSHA1SignedCertificates configuration option). These deprecated policies should only be enabled for compatibility with legacy systems.

Security policy None

  • None — No security.
    • For testing or isolated networks only.
    • Not recommended for production environments.

User Authentication

The stack supports the following user authentication mechanisms:

  • Anonymous — No user authentication.
  • Username / Password — User credentials encrypted using the active security policy.
  • X.509 Certificate — User authentication via X.509 certificates.
  • Issued Token — Includes JSON Web Tokens (JWT) and other IssuerEndpointUrl-driven flows (OAuth2 / OIDC / Entra). The Identity Providers pluggable model (IClientIdentityProvider, IUserTokenAuthenticator, IAccessTokenProvider, ITokenIssuer, IIdentityClaims) is the recommended way to wire these in.

Certificate Types

The stack supports the following certificate types for application authentication:

RSA certificates

  • RsaSha256ApplicationCertificateType — RSA with SHA-256 signatures
    • Default minimum key size: 2048 bits
    • Recommended for production use

ECC certificates

  • EccNistP256ApplicationCertificateType
  • EccNistP384ApplicationCertificateType
  • EccBrainpoolP256r1ApplicationCertificateType
  • EccBrainpoolP384r1ApplicationCertificateType

The RejectSHA1SignedCertificates configuration option (on by default) prevents SHA-1 signed certificates from being accepted. See Certificates and Certificate Manager for storage, ref-counted lifetime, and the segregated-interface design.

Global Discovery Server (GDS)

The stack ships a Global Discovery Server implementation covering the following OPC UA Part 12 areas:

  • Application registration and discovery.
  • Pull and Push certificate-management models, including pushing to arbitrary certificate groups and custom certificate groups on the GDS itself.
  • Sub-CA revocation without auto-creating an empty CRL.
  • Support for both RSA and ECC certificate types and CRLs.
  • AuthorizationService (OPC 10000-12 §9) — OAuth2-style StartRequestToken / FinishRequestToken issuance with a pluggable IAccessTokenProvider / ITokenIssuer.
  • KeyCredentialService (OPC 10000-12 §8) — Credential issuance for non-OPC UA services such as MQTT brokers and REST APIs, backed by IKeyCredentialRequestStore / ISecretStore.

See the GDS Developer Guide for the implemented facets, provider-dependent features, partial support, and hosting integration. This is not a claim that every optional Part 12 function is implemented or certified. The Local Discovery Server is a separate library (Opc.Ua.Lds.Server) and reference application (ConsoleLdsServer) that advertises the Local Discovery Server 2017 facet.

Message Encoding

The stack supports the following message encoding formats:

  • UA Binary — OPC UA binary encoding (primary for UA-TCP and HTTPS).
  • UA XML — OPC UA XML encoding (for configuration import / export and PubSub Dataset XML).
  • UA JSON — OPC UA JSON encoding for PubSub MQTT.
  • UADP — UA Data Protocol for PubSub.

The 2.0 release ships a new JSON decoder / encoder, array / matrix abstractions, and a first-class ByteString type. See the 2.0 migration guide — Encoders and Complex Types for the encoder/decoder migration details and Complex Types for client-side decode of server-defined types.

Specification Compliance

  • OPC UA Specification: Version 1.05.07.
  • Certification: Historical reference-server certification does not establish certification of the current release or of an application built with the SDK. Verify the certificate and tested profile scope for the exact product version.
  • Testing: Automated repository tests provide implementation evidence, not a substitute for certification. The GDS conformance matrix explicitly distinguishes its test evidence from CTT results.
  • Redundancy (Part 4 §6.6): Server and client redundancy are implemented (opt-in) — RedundancySupport, Server.ServiceLevel, non-transparent (ServerUriArray / RedundantServerArray) and transparent (CurrentServerId) modes, RequestServerStateChange, and client-side transparent failover via ManagedSession.WithServerRedundancy(); see High Availability.

Configuration

Server profile configuration

Server profiles are configured in the server configuration file using the ServerProfileArray element. The reference server's default array is:

<ServerConfiguration>
  <!-- see https://profiles.opcfoundation.org/ for the canonical list of profile and facet URIs -->
  <ServerProfileArray>
    <ua:String>http://opcfoundation.org/UA-Profile/Server/StandardUA2017</ua:String>
    <ua:String>http://opcfoundation.org/UA-Profile/Server/DataAccess</ua:String>
    <ua:String>http://opcfoundation.org/UA-Profile/Server/Methods</ua:String>
    <ua:String>http://opcfoundation.org/UA-Profile/Server/ReverseConnect</ua:String>
    <ua:String>http://opcfoundation.org/UA-Profile/Server/ClientRedundancy</ua:String>
  </ServerProfileArray>
</ServerConfiguration>

To advertise additional facets (Historical Access, Aggregates, Alarms & Conditions, File Access, Auditing, NodeManagement, State Machine, etc.) look up the canonical URI for the facet on https://profiles.opcfoundation.org/ and add it to ServerProfileArray. Only advertise a facet that the application genuinely implements — the Compliance Test Tool will exercise every claimed facet. Bringing the reference-server and CTT configs in line with the facets the stack actually implements is tracked in #3875.

Contributed profiles and conformance units

Node managers that implement IConformanceContributor, such as the companion node managers, contribute the facets and conformance units they actually wire. At startup the server registers them with the ConformanceUnitsManager and publishes the aggregate to Server/ServerCapabilities/ConformanceUnits and ServerProfileArray.

The manager keeps the registered contributors and reads them again on every PublishAsync, because the ServerCapabilities describe the current configuration of the server (OPC 10000-5 §6.3.2). A contributor whose support changes at runtime calls PublishAsync afterwards (the manager is ServerInternalData.ConformanceUnitsManager); a unit or profile that no contributor reports any more is withdrawn. Unregister removes a contributor. The profiles from the ServerProfileArray configuration are always kept.

Security policy configuration

Security policies are configured in the SecurityPolicies section:

<SecurityPolicies>
  <ServerSecurityPolicy>
    <SecurityMode>SignAndEncrypt_3</SecurityMode>
    <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</SecurityPolicyUri>
  </ServerSecurityPolicy>
  <ServerSecurityPolicy>
    <SecurityMode>SignAndEncrypt_3</SecurityMode>
    <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Aes128_Sha256_RsaOaep</SecurityPolicyUri>
  </ServerSecurityPolicy>
  <!-- ECC security policies -->
  <ServerSecurityPolicy>
    <SecurityMode>SignAndEncrypt_3</SecurityMode>
    <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP256</SecurityPolicyUri>
  </ServerSecurityPolicy>
</SecurityPolicies>

See the reference server configuration file for a complete example, or the CTT configuration file for the variant selected by --ctt.

  • What's New in 2.0 — Narrative tour of the 1.5.378 → 2.0 changes, grouped by theme and layer.
  • Migration Guide — Prescriptive, per-API migration reference.
  • Subscriptions and Monitored Items — V2 ISubscriptionManager, declarative + imperative SetTriggering (N:M, replay on recreate / reconnect), and IStreamingSubscription.
  • Async Server Support — TAP-based AsyncCustomNodeManager and the IAsyncNodeManager family.
  • Dependency Injection — services.AddOpcUa() and the IOpcUaBuilder hosting surface.
  • Native AOT — AOT publishing, AOT-clean source generators, and the AOT test matrix.

References