Note
What a station checks before loading a module
Signing is not a formality bolted on at the end. It is a load-time gate with three settings, and the default one refuses unsigned code.
- Module signing
- Certificates
- Deployment
The three modes
A Niagara host decides how strict to be about module signatures with a single
system property, niagara.moduleVerificationMode. It takes three
values, and the distinction between them is about the certificate, not
about whether a signature exists.
| Mode | What the host requires |
|---|---|
| low | Warnings only — an unsigned module still loads. Documented as an option that will be removed in a future release, so anything depending on it has a deadline whether or not anyone has written it down. |
| medium | The current default. Modules must be signed by a valid, trusted certificate. Trusted means present in that host's trust store — which is a per-host fact, not a property of your certificate. |
| high | Valid, trusted and CA-issued. An internal CA is acceptable, so this does not automatically mean buying a certificate, but it does rule out a bare self-signed key. |
Default is medium, and that is the number that matters. An unsigned module does not install on a stock station or a stock controller. Not "warns", not "logs" — refused.
Medium became the default in Niagara 4.9
The default moved in two steps, not one. Niagara 4.8 shipped with the verification mode at low; 4.9 raised the shipped default to medium. A host running 4.9 or later gets medium behaviour out of the box. A host still on 4.8 does not — which is why a jar that installed unsigned for years stops installing the moment the host is upgraded, with no change to the jar itself.
Trusted is a property of the host
The most common surprise is a module that installs on one host and is refused by the next, with the same jar and the same signature. Nothing about the module changed; the second host does not have the signing certificate in its trust store.
This is why "is it signed?" is the wrong question when something will not install. The question is "is this certificate trusted by this host, and does this host demand a CA behind it?" The answer is per host, and on an estate assembled over several years the answer varies across the estate.
You cannot talk a station out of it at the command line
There is a matching property, a command-line property blacklist, whose job is to stop somebody setting the verification mode — among other security-relevant properties — as a launch argument. The intent is plain: the strictness of module verification is a decision made in the host's configuration by whoever administers it, not something a process can lower for itself on the way up.
Treat a plan that involves relaxing verification as a plan that will be rejected during commissioning.
Program objects are gated separately
Modules are not the only executable thing in a station. Program objects have their own signing requirement, with its own property, defaulting to permissive — unsigned program objects run. A site that has tightened module verification and left program objects alone has a gap it very likely does not know about, and closing it is a one-line configuration change plus the work of signing what is already there.
Practical consequences
- Sign in development, not at the end. A build that produces unsigned jars for months and signs once before delivery discovers every trust and packaging problem on the day of delivery.
- Decide self-signed or CA early. Self-signed with the certificate distributed to the estate's trust stores is coherent for an internal estate. Anything sold or shipped to third parties needs a CA behind it, and obtaining a code-signing certificate now requires hardware key storage — which takes lead time and money, so it belongs in the plan, not the last week.
- Record which certificate signed which release. When a certificate expires or is replaced, the question "what is out there signed by the old one" needs an answer that is not an estate-wide search.
Related
Where this comes up in the work
Custom modules & drivers
Bespoke Niagara rt, wb and ux modules and drivers written against the Baja API: pure Java, signed, and stamped to install across a mixed estate.
Station engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
More notes
Other things worth writing down
How to build and load a custom Niagara 4 module
What a Niagara module actually is on disk, the two ways to build one, and the three Software Manager refusals that actually mean something.
- Module development
- Build tooling
- Deployment
The certificate on a new JACE
Every station starts with a self-signed certificate it generated itself. What that is good for, what it is not, and what breaks on the day it expires.
- TLS
- Certificates
- Commissioning
Commissioning a JACE-8000 without locking yourself out
The factory address, the passphrase and the account you are made to delete — the commissioning steps that strand a new controller.
- JACE
- Commissioning
- Deployment
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.