GDS Push Management and Reverse Connect: managing certificates on devices you cannot reach

TL;DR

• Push management (OPC 10000-12, §7.4) lets a Global Discovery Server commission a device that does nothing but expose the standard ServerConfiguration object. The device's private key never leaves it.
• Push has one hidden assumption: the GDS can open a connection to every device. Behind NAT, or across a site boundary, it cannot.
• Reverse Connect (OPC 10000-6, §7.1.2.6) flips the direction of the TCP connection, not the roles. The device dials the GDS console, and the console runs the same pushes over that connection.
• The Sterfive GDS admits a device only after an operator approves it, and checks the device's certificate against the identity it announced.

Two ways to commission a certificate

A Global Discovery Server (GDS) has to get certificates and trust lists onto OPC UA applications. The specification defines two models, and we covered the fundamentals in What is an OPC UA GDS?.

Push is the model that suits the hard cases. A PLC, a machine controller or a third-party gateway is a passive OPC UA server. You cannot teach it to register anywhere, but it can implement ServerConfiguration, and that is all Push needs.

A Push onboarding follows a fixed sequence:

1. The GDS installs the CA trust list on the device.
2. The GDS asks the device to create a signing request.
3. The device returns a CSR. The private key stays on the device.
4. The CA signs the CSR.
5. The GDS installs the certificate and asks the device to apply it.

The same sequence covers rotation before expiry, and trust list updates when the CA changes.

The assumption hiding inside Push

Read the sequence again. Every step is a GDS call toward the device. Push management assumes the GDS can open a TCP connection to every device it manages.

On one flat plant network, that holds. In real deployments it often does not:

• The GDS runs in a cloud host or a central data center, and the devices are in factories behind NAT.
• A machine builder manages equipment at customer sites, where the customer's firewall allows nothing inbound.
• A site security policy forbids inbound connections into the OT network, but allows outbound ones.

The usual answers are a VPN per site, a port forward per device, or a jump host. Each of them works, and each opens a path into the network you are trying to protect, which is a poor trade for a feature whose purpose is security.

Reverse Connect: the device dials, the GDS drives

OPC UA already contains a way to invert the connection. Reverse Connect, defined in OPC 10000-6 §7.1.2.6, lets a server open the TCP connection to a client that is listening. The server announces itself with a ReverseHello message carrying its ApplicationUri and the endpoint URL to use. From that point, the connection behaves like any other OPC UA connection: the client opens a secure channel, creates a session, and calls methods.

Only the direction of connection setup changes. The GDS is still the client and the device is still the server, so every Push call works unchanged. The device only needs to reach one outbound TCP port on the GDS host.

sequenceDiagram
    participant D as Device (behind NAT)
    participant G as GDS console
    D->>G: TCP connect, ReverseHello (ApplicationUri, endpoint URL)
    Note over G: known and admitted device
    G->>D: OpenSecureChannel, CreateSession
    G->>D: trust list, CreateSigningRequest, UpdateCertificate
    D-->>G: CSR, private key stays on the device

The device keeps a connection open to the console and dials again after each one closes. The firewall rule on the site side is one outbound port. On the GDS side it is one inbound port.

What it looks like in the Sterfive GDS

The Admin Console has a Reverse Connect listener, off by default. You enable it with a Compose overlay that publishes one port (4841 by default):

docker compose -f docker-compose.yml -f ../docker-compose.reverse-connect.yml \
  --env-file .env --env-file .env.secrets up -d

On the device, you add opc.tcp://<gds-host>:4841 to its Reverse Connect client list. The setting is called differently in each product; look for "Reverse Connect" or "ReverseHello".

Then the workflow is deliberately explicit:

1. The device dials. The console does not know it yet, so it records the device on the Reverse Connect page as Pending and closes the connection. This is what the specification requires for a server the client does not recognize.
2. An operator decides. A user holding the DiscoveryAdmin role admits or rejects the device. The decision goes into the audit journal.
3. The device is kept connected. From its next connection on, an admitted device stays parked and ready.
4. You onboard it like any other. The onboarding wizard, Quick Execute, provisioning-mode runs, rotations and fleet health all work unchanged. Each operation waits for the device's next connection when none is ready, so the device's redial delay adds to the operation time.

An admitted device is marked Reverse Connect only. While it is, the console refuses any operation that would dial it, including when the listener is stopped. The console never opens a connection toward such a device, and never silently falls back to one. If the device later becomes reachable, you switch it to Direct on the same page.

The security question: who is really on the other end?

Reverse Connect raises an obvious concern. The ReverseHello is not authenticated. Anyone who can reach the port can announce any ApplicationUri. A GDS that trusted the announcement would let an attacker impersonate a device, and then receive a signed certificate meant for that device.

The console does not trust it, in three layers:

1. Nothing is accepted on announcement alone. An unknown ApplicationUri is only recorded as pending, and a human admits it.
2. The certificate must match the announcement. Before a secure connection, the console reads the device's certificate over the device's own connection, and refuses it unless it names the announced ApplicationUri. The event is audited.
3. The secure channel proves the key. It proves the device holds the private key of that certificate. Before any certificate is issued, the console also requires the device to present a certificate the GDS itself issued to that application, exactly as for a device it dials.

Credentials work as for a direct connection. Reverse Connect changes who opens the socket, not who is authorized to do what.

Why not just a VPN?

A VPN is a fine answer for some sites, and Reverse Connect does not replace one. It is a better fit when:

• The GDS cannot be given a route into the site. One outbound port is much easier to approve than a tunnel.
• You manage many small sites. There is no per-site VPN or per-device port forward to maintain. Devices only need to know one address.
• You want the security tool not to weaken the network it protects. Nothing listens on the device side, so there is no inbound path to defend.

It uses a mechanism the OPC UA specification already defines, so a device does not need a proprietary agent, only a standard Reverse Connect client.

Try it without a factory

We publish a demo device that you can run on any computer with Node.js. It supports Reverse Connect and can be set to refuse every inbound connection, so a demo on one machine proves that nothing dialed the device:

DEMO_REVERSE_CONNECT_URL=opc.tcp://localhost:4841 npx @sterfive/opcua-demo-device

Start the GDS with the Reverse Connect overlay, watch the device appear as Pending, admit it, and run the onboarding wizard against it.

Key takeaways

1. Push commissions passive devices through ServerConfiguration, and the private key never leaves the device.
2. Push assumes the GDS can dial the device. Behind NAT or a site firewall, that assumption breaks.
3. Reverse Connect lets the device dial the GDS instead, and every Push operation then runs unchanged over that connection.
4. Because the ReverseHello is unauthenticated, a safe GDS admits devices explicitly, verifies the certificate against the announced identity, and never falls back to dialing.

References

1. OPC Foundation, OPC UA Part 12: Discovery and Global Services, §7.3 Pull Management and §7.4 Push Management. opcfoundation.org
2. OPC Foundation, OPC UA Part 6: Mappings, §7.1.2.6 Reverse Connect. opcfoundation.org

Sterfive builds OPC UA GDS, a Global Discovery Server with a web Admin Console, an isolated CA and Push management out of the box. If you manage devices across network boundaries, talk to our engineers.