What a station checks before loading a module

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.

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.

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.

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.