Why that module will not install on your gateway

What the gateway is actually checking

Ignition will not install a module that is not signed unless the gateway is in developer mode. The gateway blocks the install rather than letting you click through a warning, and it says so: an unsigned module appears in the Quarantined section of the Modules page, with the reason it was held.

Quarantine is not a new mechanism. Ignition has held untrusted and unsigned modules aside since 7.7.8 and 7.8.3, so a gateway declining a module has been telling you why for close to a decade. What Ignition 8.3.2 added is a menu on the Modules page for acting on a quarantined module — reviewing and accepting its certificate or licence, or deleting it outright. That changes how you deal with a quarantined module, not whether the gateway requires a signature.

Signing, and the acceptance step people forget

A module can be signed with a code signing certificate from a certificate authority, or with a self-signed certificate the developer generates. Both satisfy the signing requirement, so neither needs developer mode.

Neither, however, guarantees a silent install. The first time a gateway sees a module signed with a given certificate, it can ask you to review and accept that certificate — and a module can sit in quarantine waiting for exactly that. This catches people out because it looks like the unsigned-module failure and is not: one is a missing signature, the other is a signature you have not yet vouched for.

What the two certificate types differ on is what the signature attests. A certificate authority verified an identity. A self-signed certificate tells you that later builds came from the same signer you accepted the first time, which is tamper-evidence rather than identity. Ignition records the certificate fingerprint when you accept it and recognises it thereafter.

The flag is gateway-wide

Developer mode is a JVM system property, -Dignition.allowunsignedmodules=true, normally set in the gateway’s configuration file at data/ignition.conf and applied on restart. On containerised gateways it is commonly passed as a container argument instead, which matters later.

It is a property of the gateway, not of a module. That single fact is the whole argument. The setting cannot be scoped to the one module you wanted to install: once it is on, that gateway accepts any unsigned module presented to it until somebody removes it. A decision made to solve a five-minute problem becomes a standing property of a production server.

The flag itself is not displayed anywhere in the gateway web interface, though its consequences are — an unsigned module has no certificate to show on the Modules page. The person who set it usually knows. The person who inherits the gateway two years later usually does not.

What the risk actually is

It is worth being precise here, because the case is often overstated and does not need to be.

Developer mode is not a privilege boundary. Anyone who can place a .modl file on a gateway already has gateway administration or filesystem access, and gateway-scoped scripting already runs arbitrary code as the service account. Turning the flag on does not, by itself, give an outsider a way in that they did not already have — what it removes is the check that would have caught a tampered or substituted module on the way in.

The loss is provenance. Signing is a supply-chain control: it tells you a module came from the signer you accepted and has not been altered since. Switch it off and third-party code enters your gateway with nothing attesting where it came from — which is a real loss, and in a regulated or audited environment it is a finding, but it is a different claim from “this makes you hackable”.

What this means when you are buying

If a vendor ships an unsigned module, installing it means enabling unsigned modules on your gateway. The cost is not the few minutes of editing a config file and restarting; it is that the gateway stays more accepting afterwards, across every module rather than the one you trusted.

So it is a fair question to put to any vendor: is the module signed, and will it install on a standard production gateway without changing gateway settings? A vendor who cannot answer yes is asking you to modify your infrastructure as a precondition of evaluating their software.

The Parsley modules — CVI-RTSP (Ignition 8.1+), REST to Tags and Company News (both 8.3+) — are currently distributed as signed modules and install on a standard production gateway without developer mode. Signing and compatibility are ultimately controlled by Inductive Automation and can change between versions, which is why that sentence carries a “currently” rather than a promise.

If developer mode is already on

We have found gateways running with it enabled, usually because it was needed once and never revisited. It is worth checking rather than assuming.

Check data/ignition.conf for the property. On a containerised gateway, check the container arguments or the compose command: as well — that is where it is usually set, and a gateway running that way will show nothing in the config file.

Turning it off is not quite free. Any unsigned module currently installed will be quarantined at the next startup rather than simply continuing without the flag, so the honest sequence is: find out what depends on it first, then decide. If nothing does, it costs a restart. If something does, that is worth knowing explicitly, because it means part of your production stack is unsigned and the gateway has been configured around that fact.

Common questions

References

• Inductive Automation SDK — Sign a Module (8.3)
• Inductive Automation — Gateway Configuration File: Loading Unsigned Modules, Developer Mode
• Inductive Automation — Installing or Upgrading a Module (8.3)
• Inductive Automation — Third Party Modules: Signing Options and quarantine (7.9, historical)