Skip to content

README.md

Latest commit

 

History

History
449 lines (381 loc) · 35.4 KB

README.md

File metadata and controls

449 lines (381 loc) · 35.4 KB
Raw

UA .Net Standard Global Discovery Server and Client

Introduction

This Global Discovery Server and Client implement the Global Discovery and Certificate Management Server profile as specified in the OPC Unified Architecture Specification Part 12: Discovery and Global Services, release 1.05.07. What v1.05.07 added over the earlier releases - the transactional push model, the new GetCertificates / DeleteCertificate / CheckRevocationStatus Methods, the ApplicationAdmin privilege, the ManagedApplications folder and the Optional ServerConfiguration members - is described under OPC UA Part 12 v1.05.07 features.

The Solution is split into these projects:

  • GlobalDiscoveryServer: Global Discovery Server for .Net (Windows) that uses Entity Framework Core with a SQL server as registration and certificate database.
  • GlobalDiscoveryServerLibrary: Common Global Discovery Server classes for .Net 4.6 and .Net Standard.
  • NetCoreGlobalDiscoveryServer: Global Discovery Server for .Net Standard with Json database implementation to demonstrate the abstracted database registration and certificate authority interface. (The gdsdb.json is not a secure database and should only be used for testing).
  • GlobalDiscoveryClient: Global Discovery Client for .Net 4.6. with Windows forms user interface.
  • GlobalDiscoveryClientControls: Global Discovery Client reusable controls for .Net 4.6.
  • GlobalDiscoveryClientLibrary: Common Global Discovery Client classes for .Net 4.6 and .Net Standard.
  • GlobalDiscoveryClientTest: Unit tests for .Net Standard Global Discovery client and server libraries.

Where the client keeps its logic

The three panels of GlobalDiscoveryClient - registration, certificate and trust list - keep what they do to the server in a Model/ namespace beside them, the way the Workshop clients do (see Samples/Client.Common):

Model What it does
RegistrationModel finds, registers and unregisters the application record, and checks the fields a record is built from
CertificateModel finds the certificate an application runs on, asks the GDS for a new one in either the pull or the push model, and puts the answer in its store or its files
TrustListModel reads a trust list off a push server, pulls the one the GDS holds into the local stores, and pushes it back

Nothing in those models references Windows Forms, which Tests/SampleClientModels.Tests/ModelContractTests checks by reflection. The two questions a person has to answer stayed with the panels and reach the models as delegates: whether an existing certificate file may be overwritten, and which record is meant when the GDS holds several for one application uri.

How to build and run the Windows OPC UA Global Discovery Server

  1. Open the solution UA Global Discovery Server.sln with VisualStudio.
  2. Choose the project GlobalDiscoveryServer in the Solution Explorer and set it with a right click as Startup Project.
  3. The server uses Entity Framework Core and requires a SQL server. By default the server connects to the data source Data Source=(localdb)\MSSQLLocalDB, the SQL Server Express LocalDB instance that is installed with Visual Studio. The default location for the database files is the user home directory. To use a different SQL server (for example a full SQL Server instance or another LocalDB instance name) modify the gdsdbEntities and usersdbEntities connection strings in the app.config file.
  4. Hit Ctrl-F5 to build and execute the sample.
  5. The server loads and initializes all Certificates.
  6. On the first start the server automatically creates the gdsdb and usersdb databases (via Entity Framework Core EnsureCreated) and seeds the required tables and default data from the embedded scripts \DB\gdsdb.edmx.sql and \DB\usersdb.edmx.sql. No manual database creation or script execution is required. The account used by the connection string must have permission to create databases on the target SQL server.
  7. The server is now running and waiting for the connection of a GDS client.

How to build and run the console OPC UA Global Discovery Server on Windows, Linux and iOS

This section describes how to run the NetCoreGlobalDiscoveryServer.

Please follow instructions in this article to setup the dotnet command line environment for your platform.

Start the server

  1. Open a command prompt.
  2. Now navigate to the folder SampleApplications/Samples/GDS/NetCoreGlobalDiscoveryServer.
  3. Execute dotnet restore. This command calls into NuGet to restore the tree of dependencies. In latest .Net versions this command is optional.
  4. To run the server type dotnet run.
  5. The server loads and initializes all Certificates.
  6. The server is now running and waiting for the connection of a GDS client.

Integrating the v2 Local Discovery Server (LDS) library with the GDS

Starting with UA .NET Standard v2 the stack ships a managed Local Discovery Server as the NuGet package OPCFoundation.NetStandard.Opc.Ua.Lds.Server. It implements the Local Discovery Server (LDS) and the Local Discovery Server with Multicast Extension (LDS-ME) as specified in OPC UA Part 12, and is a managed, cross-platform replacement for the legacy C++ LDS.

Roles of the LDS and the GDS

The LDS and the GDS are complementary discovery components and are meant to run side by side:

  • The LDS / LDS-ME is a local directory. Servers on the same host register themselves with the LDS through RegisterServer / RegisterServer2, and the LDS-ME re-publishes those endpoints over mDNS so that other nodes on the local network can find them. Clients call FindServers and FindServersOnNetwork on the LDS to enumerate what is currently reachable. The LDS keeps only volatile, TTL-based records and performs no certificate management.
  • The GDS is a global, persistent directory and certificate authority. It stores approved ApplicationRecordDataType entries in its database and issues/manages certificates and trust lists.

Integrating the two lets the GDS reuse the network view that the LDS-ME already maintains, instead of every server having to register with the GDS explicitly. This is the feature tracked in issue #329 – GDS autopopulate from LDSes: the GDS periodically scans one or more LDSes for servers on the network and, after an administrator approves them, adds records to its own database.

Relevant LDS library API

The package exposes the pieces you need to host an LDS and to read what it has discovered:

  • Opc.Ua.Lds.Server.LdsServer – a DiscoveryServerBase subclass that answers FindServers, FindServersOnNetwork, GetEndpoints, RegisterServer and RegisterServer2. Host it from a small executable the same way the sample GDS hosts GlobalDiscoverySampleServer.
  • Opc.Ua.Lds.Server.IRegisteredServerStore – the backing store for explicit registrations and mDNS-observed network records. Useful members:
    • IReadOnlyList<ServerOnNetworkRecord> SnapshotNetworkRecords() – all currently known network records.
    • (IList<ServerOnNetwork> records, DateTime lastCounterResetTime) ListOnNetwork(startingRecordId, maxRecordsToReturn, serverCapabilityFilter) – the same paginated view returned by FindServersOnNetwork.
    • IList<ApplicationDescription> Find(serverUriFilter, requestedLocaleIds) – translated application descriptions for the active registrations.

How the GDS pulls records from an LDS

From the GDS side the LDS is just another discovery endpoint, so the scan can be driven entirely with the standard UA client discovery services — no direct reference to the LDS assembly is required:

  1. List the servers the LDS knows about. Call FindServersOnNetwork on each configured LDS discovery URL (default opc.tcp://<lds-host>:4840). Each returned ServerOnNetwork record carries a RecordId, ServerName, DiscoveryUrl and the advertised ServerCapabilities. Page through the results using the startingRecordId / maxRecordsToReturn arguments exactly as the sample ViewServersOnNetworkDialog does against the GDS.
  2. Resolve full application information. For every candidate DiscoveryUrl, call FindServers (and optionally GetEndpoints) to obtain the complete ApplicationDescription (application URI, product URI, application type, discovery URLs, and — from the endpoints — the application instance certificate).
  3. Stage the candidates for approval. Do not register discovered servers automatically. Present them to a user holding the DiscoveryAdmin role (see GDS Users); auto-populating the GDS without review would let any server on the network insert itself into the global directory.
  4. Register approved applications. Map each approved ApplicationDescription to an ApplicationRecordDataType and persist it through the GDS applications database, e.g. ApplicationsDatabaseBase.RegisterApplication(...) (implemented by SqlApplicationsDatabase for the Windows/SQL server and by JsonApplicationsDatabase for the .NET console server). Once registered, the application can request a CA-signed certificate and trust list through the normal GDS pull workflow.

This scan-and-stage flow is implemented in the NetCoreGlobalDiscoveryServer sample. Once the console GDS is running, type scan at the prompt to enumerate the configured LDSes, review each discovered server, and register the ones you approve (help lists the available commands). The scanner lives in Samples/GDS/ConsoleServer/LdsGdsScanner.cs and the list of LDS discovery URLs it scans is read from the <LdsScannerConfiguration> extension in Opc.Ua.GlobalDiscoveryServer.Config.xml (see Configuration below). A companion LDS host you can scan against ships as the ConsoleLds sample.

The following sketch shows the scan-and-stage step (the approval gate and the final RegisterApplication call are left to the host application):

// 'ldsUrl' is a configured LDS discovery URL, e.g. "opc.tcp://lds-host:4840".
// 'discovery' is an Opc.Ua.DiscoveryClient created for that URL.
var candidates = new List<ServerOnNetwork>();
uint startingRecordId = 0;

while (true)
{
    // FindServersOnNetwork mirrors IRegisteredServerStore.ListOnNetwork on the LDS side.
    var onNetwork = await discovery.FindServersOnNetworkAsync(
        startingRecordId,
        maxRecordsToReturn: 100,
        serverCapabilityFilter: null);

    if (onNetwork.Servers.Count == 0)
    {
        break;
    }

    candidates.AddRange(onNetwork.Servers);
    startingRecordId = onNetwork.Servers.Max(s => s.RecordId) + 1;
}

foreach (var server in candidates)
{
    // Resolve the full ApplicationDescription(s) behind each discovery URL.
    using var serverDiscovery = DiscoveryClient.Create(new Uri(server.DiscoveryUrl));
    ApplicationDescriptionCollection apps = await serverDiscovery.FindServersAsync(null);

    // -> hand 'apps' to a DiscoveryAdmin for approval, then map the approved
    //    entries to ApplicationRecordDataType and call RegisterApplication on
    //    the GDS applications database.
}

Configuration

Two related settings already exist in the GDS config (Opc.Ua.GlobalDiscoveryServer.Config.xml, under ServerConfiguration):

  • RegistrationEndpoint – the discovery endpoint the GDS registers itself with on start-up. In the sample it points at opc.tcp://localhost:4840, i.e. a local LDS. Point this at your LDS so the GDS becomes visible through it.
  • MultiCastDnsEnabled – set to true to let the GDS announce itself over mDNS through an LDS-ME.

The scan direction (the GDS reading servers from one or more LDSes) is not represented by an existing element, so the sample adds its own <LdsScannerConfiguration> extension element with a list of LDS discovery URLs, which the scan command reads when driving the scan above (see Samples/GDS/ConsoleServer/LdsScannerConfiguration.cs). The default LDS discovery URL is opc.tcp://<lds-host>:4840. In every case make sure the GDS trusts each LDS application certificate (copy it from the GDS rejected store to trusted/certs, see GDS Certificate stores) so the discovery calls can use a secure channel.

Merging AliasNames from registered servers into a GDS master list

OPC UA Part 17 (AliasNames) lets a server expose an Aliases directory that maps human-friendly names (for example TagVariables and Topics) onto the NodeIds they resolve to. The GDS is the natural place to aggregate those per-server alias directories into a single, global view. This is the feature tracked in issue #274 – How GDS pulls the AliasNames from Registered servers:

When a Server registers with the GDS, the GDS shall merge the AliasNames of the registering Server into a master AliasNames list on the GDS.

Both sample GDS servers (the Windows GlobalDiscoveryServer and the cross-platform NetCoreGlobalDiscoveryServer) now implement this. The master list is served through the standard Part 17 well-known nodes on the GDS itself — Aliases (i=23470), TagVariables (i=23479) and Topics (i=23488) — so any UA client can browse the aggregated aliases on the GDS exactly as it would on an individual server.

How the merge works

The shared implementation lives in Samples/GDS/Common/GlobalDiscoveryServerAliasMerger.cs and Samples/GDS/Common/SampleGlobalDiscoveryServer.cs, which are linked into both sample projects.

  1. Master store. GlobalDiscoveryServerAliasMerger owns an in-memory Part 17 InMemoryAliasNameStore laid out with the standard Aliases root and its TagVariables / Topics sub-categories. The SampleGlobalDiscoveryServer subclass registers this store with the server's IAliasNameStoreRegistry in OnServerStarted, so the well-known alias nodes on the GDS dispatch through it.
  2. Pull on registration. When a server registers, the applications database raises a registration event and the merger connects out to that server as a UA client and calls the Part 17 FindAlias service (with the % wildcard) to read every alias the server publishes.
  3. Merge. The pulled aliases are written into the GDS master Aliases category, tagged with the contributing server's application URI as their TargetServer. The merger tracks each server's contribution, so a re-registration (or the periodic refresh) cleanly replaces that server's previous aliases instead of duplicating them.
  4. Periodic refresh. A background worker re-scans every registered server on an interval (default five minutes) so the master list also reflects alias changes made after registration.

Authentication of the pull

The GDS never captures a registering server's user credentials, so it cannot impersonate a named user when reading that server's aliases. The pull is therefore performed anonymously over a secured (Sign / SignAndEncrypt) channel authenticated with the GDS application instance certificate. For the merge to succeed:

  • The server must offer a secure endpoint that permits anonymous access to the Part 17 FindAlias service.
  • The server must trust the GDS application certificate (and the GDS must trust the server's certificate) so the secure channel can be established — copy the certificates between the trust lists exactly as for the LDS scan above.

Servers that require a named user or a user certificate to read their aliases are simply skipped, and the failure is logged; nothing else about registration is affected.

OPC UA Part 12 v1.05.07 features

The stack implements the whole of OPC 10000-12 v1.05.07; these samples show what a host and a client have to do about it. Everything in this section works against both sample servers.

Transactional push management (§7.10.2, §7.10.9, §7.10.11, §7.10.17)

Every Certificate and TrustList Method of ServerConfiguration is now staged: UpdateCertificate, DeleteCertificate, CreateSelfSignedCertificate and the TrustList updates change nothing until ApplyChanges commits them, and CancelChanges throws the pending work away. Only one Session may have a transaction open at a time; another one is told Bad_TransactionPending.

The Server Status panel of the GDS client is where this becomes visible:

  • Supports Transactions — the SupportsTransactions Property (§7.10.2). It has no well-known singleton-instance NodeId, so the panel resolves it by browse path.
  • Transaction Result / Start / End / Affects — the TransactionDiagnostics Object (§7.10.17). Its children report Bad_OutOfService before the first transaction, Bad_InvalidState while one is open and Good once one has completed, so the panel shows the StatusCode next to the value.
  • Has Secure Element and In Application Setup — the Optional identity Properties of §7.10.3.
  • Apply Changes commits the transaction, Cancel Changes discards it. Cancelling leaves the session up and only refreshes the diagnostics; applying closes the sessions the change invalidated.

Certificate lists and per-slot Methods (§7.9.8, §7.9.11, §7.10.6 - §7.10.8)

The Certificates... button on the Certificate panel of the GDS client opens a list of the certificates the other side holds, one row per CertificateType. What it offers depends on the registration type:

  • Pull management — the list comes from the GDS GetCertificates Method (§7.9.8), and Check Revocation calls CheckRevocationStatus (§7.9.11), which answers with a StatusCode and the ValidityTime until which that answer holds.
  • Push management — the list comes from the ServerConfiguration.GetCertificates Method (§7.10.8). Delete (staged) calls DeleteCertificate (§7.10.7) and Create Self-Signed (staged) calls CreateSelfSignedCertificate (§7.10.6), which gives a server a working certificate with no CA involved at all. Both only stage their change - commit it with Apply Changes on the Server Status panel, or drop it with Cancel Changes.

Note that GetCertificates is the one §7.10 Method that does not read a null CertificateGroup as the DefaultApplicationGroup; the group has to be named or the server answers Bad_InvalidArgument.

The ApplicationAdmin privilege (§7.2)

ApplicationAdmin sits between DiscoveryAdmin (may administer every application) and ApplicationSelfAdmin (may administer only the application whose certificate authenticated the channel): the holder may administer a configured subset of the registered applications.

The role alone grants nothing - the GDS also has to know which applications. That mapping is what Samples/GDS/Common/GdsApplicationAdminUserDatabase.cs adds: it decorates the user database of either sample server with an IGdsUserDatabase implementation and keeps the grants in a small JSON file next to it, so neither the JSON nor the SQL user store needs a schema change. From there the stack does the rest: GlobalDiscoverySampleServer seeds GdsRoleBasedIdentity.AdministeredApplicationIds during user-name authentication and AuthorizationHelper checks every Method call against it.

Type admins at the prompt of the console GDS to list the current grants and bind registered applications to a user. The standard user ApplicationAdmin (PW demo) holds the role and starts out with no grants.

The ManagedApplications folder (§7.10.14 - §7.10.16)

A GDS may expose the configuration of the other applications it manages, each as an ApplicationConfigurationType instance under the well-known ManagedApplications folder, with a ConfigurationFile that follows the CloseAndUpdate / ConfirmUpdate lifecycle. The stack's DefaultManagedApplicationsNodeManager builds those nodes; Samples/GDS/Common/GdsManagedApplicationsDataStore.cs answers the two questions it cannot answer on its own - which applications to expose (every application registered with this GDS) and where their configuration lives (a file per application under the GDS database store path). Writes are guarded by an optimistic-concurrency check on the configuration version.

The folder is filled while the address space is built, so applications registered afterwards appear on the next restart.

The Optional ServerConfiguration surface (§7.10.3, §7.10.13, §7.10.20)

ConfigurationNodeManager suppresses each of these members unless the host configures it, so the sample servers hand it a ServerConfigurationOptions:

  • HasSecureElement — false: the samples keep their private keys in the file system, not in a TPM.
  • InApplicationSetup — false: the GDS is commissioned, not in the OPC 10000-21 setup state.
  • ResetToServerDefaults (§7.10.13) — backed by SampleServerConfigurationResetProvider, which restores the trusted-peer store to the snapshot taken at start-up. The specification leaves "default settings" vendor-defined; the sample reads it as "undo the trust decisions made while this server was running" and deliberately leaves the application instance certificate and the CA material alone. The server shuts down after the reset.
  • ConfigurationFile (§7.10.20) — backed by SampleApplicationConfigurationFileProvider, which serves the GDS's own configuration XML over the standard FileType read/update flow. It requires confirmation: the previous file is kept until the client reconnects and calls ConfirmUpdate, and restored if it does not. A configuration written this way takes effect on the next server start.

These nodes are only visible to the SecurityAdmin Role - log in as sysadmin to browse them.

Device onboarding (OPC 10000-21)

Part 21 provisioning starts with tickets: signed blobs a manufacturer issues to name the devices a customer may onboard. The customer loads them into a registrar, and a device that later presents a matching identity is accepted without an administrator registering it by hand.

The sample servers expose the registrar administration Object - RegisterTickets and UnregisterTickets, bound to an in-memory ticket store - through Samples/GDS/Common/DeviceRegistrarNodeManager.cs. The Onboarding panel of the GDS client loads ticket files and calls those Methods through the stack's OnboardingClient; type tickets at the prompt of the console GDS to see what the registrar holds.

What to pick in the file dialog. A ticket is an EncodedTicket - a ByteString whose content Part 21 leaves to the device manufacturer. There is no standard file extension for one, and the sample cannot decode it either, because the companion model that defines the ticket types is not in the shipped packages (see the caveats below). The sample registrar therefore stores the blob verbatim and keys it by its SHA-256 hash, so any file works as a stand-in - which is why the dialog keeps an All Files entry alongside the conventional *.ticket / *.tkt / *.bin extensions. Pick any small file to see the round trip: register it, run tickets on the console GDS to see it listed, then unregister it again.

Two caveats, both about the SDK rather than about Part 21: the Onboarding companion model ships as a design file in the stack repository but its generated node classes are not in the Opc.Ua.Gds package, so the sample builds the nodes by hand under BaseObjectType in a namespace of its own; and the Method BrowseNames are created in namespace 0 because OnboardingClient resolves them with an ns=0 browse path. The device-facing ProvideIdentities flow is not part of the sample.

GDS Users

The sample GDS servers only implement the username/password authentication. The following combinations can be used to connect to the servers:

  • DiscoveryAdmin
  • CertificateAuthorityAdmin
  • ApplicationAdmin
  • System Administrator:
    • Username: sysadmin, PW: demo
    • This user is defined for server push management and has the ability to access the server configuration nodes of the GDS server to update the server certificate and the trust lists. Server push configuration management is not a requirement for a GDS server and only supported here to demonstrate the functionality. It is also the only user the Optional ServerConfiguration members are visible to.
    • Roles: CertificateAuthorityAdmin, DiscoveryAdmin, SecurityAdmin, ConfigureAdmin Deprecated
  • GDS Administrator:
    • Username: appadmin, PW: demo
    • This user has the ability to register and unregister applications and to issue new certificates. It should be used by the GDS Client application to connect.
  • GDS User:
    • Username: appuser, PW: demo
    • This user has only a limited ability to search for applications.

Certificates

The global discovery server creates the CA certificates for all configured certificate groups on the first start.

By default, a global discovery server accepts any incoming secure connection with an authenticated user (GDS Users).

The console server certificates are stored in %LocalApplicationData%/OPC Foundation/GDS/PKI while the Windows .Net 4.6 server stores the certificates in %CommonApplicationData%\OPC Foundation\GDS\PKI. %CommonApplicationData% maps to the path set by the environment variable ProgramData on Windows.

On Linux and macOS %LocalApplicationData% maps to ~/root/.local/share.

On Windows %LocalApplicationData% maps to %USERPROFILE%\AppData\Local.

GDS Certificate stores

Under PKI, the following stores contain certificates under certs, CRLs under crl or private keys under private.

  • own contains the GDS public certificate and private key.
  • rejected contains the rejected client certificates. To trust a client certificate, copy the rejected certificate to the trusted/certs folder.
  • trusted contains trusted client and CAs certificates and CRLs.
  • issuers contains CAs certificates and CRLs needed for validation of certificate chains.

GDS CA Certificate stores

Under PKI, the following stores contain certificates under certs, CRLs under crl or private keys under private.

  • authorities contains the public certificates, CRLs and private keys of the CA authorities.
  • applications contains the public certificates of all applications registered with the GDS.
  • PKI/CA contains folders for all supported certificate groups. At this point only the DefaultApplicationGroup default is supported.
    • PKI/CA/default contains the issuer and trusted list for the default application group. Each store contains the CA certificates and CRLs.

Customize the GDS CA Certificates

To customize the CA certificate search for <SubjectName>CN=IOP-2017 CA, O=OPC Foundation</SubjectName> and enter your new subject. Then search the code and the configuration files for SomeCompany and enter your company name as appropriate.

How to build and run the Windows OPC UA Global Discovery Client

  1. Open the solution UA Global Discovery Server.sln with VisualStudio.
  2. Choose the project GlobalDiscoveryClient in the Solution Explorer and set it with a right click as Startup Project.
  3. Hit Ctrl-F5 to build and execute the sample.
  4. Press the Registration button to connect to a running GDS. Use the GDS Administrator credentials in GDS Users to connect and to be able to register applications and to issue certificates.
  5. Select the appropriate Registration Type: Client or Server Pull Management or Server Push Management and proceed with the registration.

Client or Server Pull Management

  1. Always Clear registration form to start a new or to update an existing registration.
  2. Register the application in one of the described ways under Pull Registration.
  3. Press the Certificate button. Inspect an existing certificate in the form. To issue a CA signed certificate press Request New certificate which triggers either a certificate signing request or a new keypair request, whichever is more appropriate. After a short while the new CA signed certificates are issued and the GDS client may ask to override existing certificates.
  4. Press the Trust List button. Inspect the existing trusted and issuer list of the application. To add the CA certificate and the CRL to the trusted list press the Merge with GDS button.

Pull Registration

Manually enter the registration for an application

  1. In this case the entries in the Client - or Server - Pull management form must be filled in. Some fields are ignored if the application type is Client, some fields are optional.
  • Application ID: The unique identifier assigned by the GDS to the application.
  • Application Name: The default name of the Application.
  • Application URI: The URI for the Application. This URI is also stored in the application certificate extensions.
  • Product URI: A globally unique URI for the product associated with the Application. This URI is assigned by the vendor of the Application.
  • Discovery URLs: The list of discovery URLs for a Server Application.
  • Server Capabilities: The list of Server capability identifiers for the Application.
  • To use an existing store with or without existing public/private key:
    • Certificate Store Path: local X509 store (CurrentUser\UA_MachineDefault) or directory store.
    • Certificate Subject Name: The certificate distinguished name.
  • or the path to new or existing public/private key pair:
    • Certificate Public Key Path: A DER encoded certificate with a public key.
    • Certificate Private Key Path: A PFX or PEM encoded private key.
  • Trust List Store Path: optional to copy the GDS CA public certificate to the trusted store.
  • Issuer List Store Path: optional to copy the GDS CA public certificate to the issuer store.
  • Domains: Enter the domain names to be added to the certificate extension as hostnames or IP addresses.
  1. Register the application or Apply Changes.
  2. The Application ID should display a proper NodeId after registration.
  3. Save the configuration for future use.
  4. Continue with Certificateand Trust Listmanagement.

Load the existing certificate to register an application

The manual registration is simplified if there is already an existing certificate available, with or without private key.

  1. Select Clientor Server - Pull Management.
  2. Load existing certificate in the Certificate Public Key Path field.
  3. Fill in remaining fields.
  4. Continue with step 2 in the previous section.

Load registration from a sample configuration file

The GDS client can fill in the full information from a UA .Net Standard application configuration. However, for legacy .Net applications Windows certificate stores are not permitted.

  1. Load configuration, for example chose UA-.NETStandard\SampleApplications\Samples\Client.Net4\Opc.Ua.SampleClient.Config.xml
  2. The registration type is Server - Pull management, because the UA Sample Client is also a server.
  3. Register the UA Sample Client. The Application ID should now contain a valid NodeId.
  4. Press the Certificate button and Request New certificate. After a short while the UA Sample Server/Client certificate is updated with a CA signed application certificate.
  5. Press the Trust List button to add the CA certificate and CRL with Merge with GDS to the application trusted store.
  6. UA Sample Client is now ready to use and trust the GDS issued and CA signed certificates.

UA Sample Server Registration

Server Push Management

Push configuration requires server configuration node support and a session with the managed server.

  1. Select Server - Push Management
  2. Press Pick Server to connect to the managed server. Special system administrator credentials might be necessary to access the server configuration nodes - see GDS Users.
  3. Fill the remaining registration fields which can not be extracted from the server endpoint information.
  4. Register the application or Apply Changes.
  5. The Application ID should display a proper NodeId after registration.
  6. Press the Server Status and then the green arrow connect button to inspect the status. Being connected is mandatory to remote manage the server in the next steps.
  7. Press the Certificate button. Inspect an existing certificate in the form. To issue a CA signed certificate press Request New certificate, which triggers a certificate signing request. After a short while the new CA signed certificates is updated on the server directly. After the update, the GDS client user might be asked to Apply Changes in the Server Status form.
  8. Press the Trust List button. Reloadthe trust list from the managed server. Manage the certificates and Merge with GDS to add the GDS CA certificate to the trust list. Push To Server to save the updated trust list on the server.
  9. Press the Server Status button and then press Apply Changes to update the security settings on the server. After a regular certificate update the managed server may require a reboot or at least closes all sessions and requires a reconnect. Press the green arrow connect button to reconnect to the server using the new certificate.
  10. Press the Certificate button and inspect the new CA signed certificate to verify the new certificate is being used for the new session.

Nothing between step 3 and step 8 has actually changed the server: every Certificate and TrustList Method of the v1.05.07 push model only stages its work, and Apply Changes is what commits it. The Server Status panel shows where the transaction stands (Supports Transactions, Transaction Result, Transaction Start / End, Transaction Affects), and Cancel Changes next to Apply Changes throws the staged work away without touching the server. Use the Certificates... button on the Certificate panel to see which certificate the server has in which slot, to empty a slot, or to have the server create a self-signed certificate for one - see Certificate lists and per-slot Methods.