Ignition 8.3 Module Vendor Name Comes From the Cert Subject

The Vendor column stays blank for this custom Perspective module for two reasons. The build ships unsigned (skipModlSigning.set(true)). The fallback vendor source, vendorName in module.xml, is not set anywhere in the ignitionModule block and is not read correctly by Ignition 8.3 early-access gateway builds.

Inductive Automation has stated how the released 8.3 gateway resolves the author/vendor name:

• It reads the subjectName of the module signing certificate first.
• If no certificate is supplied, it falls back to vendorName in module.xml.

They acknowledged that this does not work in current beta builds and plan to repair it before final release. Separately, a self-signed certificate's Common Name (CN) has been observed as the vendor string in the 8.3 gateway. The practical path is to sign the module with a certificate that carries the vendor in its subject.

Which hop carries the vendor name from build.gradle.kts to the module list?

The vendor string has to survive five hops. It is lost at the first one.

A .modl file is a zip archive. Inspect what actually left the build before touching the gateway.

1. Copy FalconGroupModules.modl and rename the copy to .zip.
2. Open module.xml. Confirm the id is au.com.falcon.group.modules and check whether any vendor element exists.
3. List the archive root for signature and certificate entries.

Check: the current unsigned build shows module.xml and the scoped jars, with no certificate entry. That confirms hop 3 carries nothing for hop 4 to read.

Why does an unsigned 8.3 early-access build leave the Vendor column blank?

With signing skipped, the gateway can only use the module.xml fallback. On early-access builds that path fails regardless of what the XML contains. Adding vendorName by hand to an unsigned archive will not produce a visible vendor until the gateway fix lands. Hand-editing a signed archive breaks its signature.

The vendor statement says subjectName. The field report points at CN. The subject name is the full distinguished name, and the gateway may display either CN or the whole DN depending on build. Set CN and O to the same vendor string. The display is then correct whichever field the gateway renders.

Check: confirm the gateway build number on the Status page before signing. If signing still leaves the column blank, you then know the defect sits at hop 4 and not in your build.

How do I put the vendor string into a self-signed certificate?

Java's keytool generates the key pair and self-signed certificate in one step. The -dname argument writes the subject that the gateway reads. The parameters below match a working 8.3 setup: RSA, 2048-bit key, 3650-day (roughly 10-year) validity, JKS keystore.

Pull the passwords from environment variables rather than literal strings. The same values have to reach the Gradle signing step, and a script checked into source control with PASSWORD inline leaks the signing key.

Check: run keytool -list -v -keystore mykeystore1.jks -alias myalias1. The Owner: line must read CN=Example Vendor, ... O=Example Vendor. Also confirm the validity dates cover your deployment window.

How do I produce the certificate chain file the module signer consumes?

The Ignition module signer takes three inputs: the keystore, the alias, and a certificate chain file (.p7b). The export command used with the key pair above is:

-exportcert -rfc writes a PEM-encoded X.509 certificate. The .p7b extension does not change the encoding. For a self-signed certificate the chain is one certificate long, and this export has been used to sign 8.3 modules.

The signer may reject the file with a chain or format error. In that case, wrap the same certificate in a true PKCS#7 container with OpenSSL (openssl crl2pkcs7 -nocrl -certfile myalias1.pem -out myalias1.p7b) and point the signer at that file.

Check: run keytool -printcert -file myalias1.p7b. It must print the same Owner:A mismatch means you exported the wrong alias.

How do I switch the Gradle build from unsigned to signed?

In the ignitionModule block, skipModlSigning.set(true) is the switch that removes hop 3's certificate.

1. Delete skipModlSigning.set(true) or set it to false.
2. Supply the five signing inputs to the io.ia.sdk.modl plugin: keystore file (mykeystore1.jks), keystore password, certificate alias (myalias1), certificate/key password, and chain file (myalias1.p7b). The plugin reads these as Gradle properties. Take the exact property names from the ignition-module-tools README for the plugin version you pin (0.1.1 here).
3. Put the property values in gradle.properties under your Gradle user home, not in the project directory, so passwords stay out of the repository.
4. Leave freeModule.set(true) and license.set("license.html") as they are. Licensing and signing are independent.
5. Bump version in allprojects (for example 1.0.0 to 1.0.1). The gateway install in section 6 then gives an unambiguous version check.
6. Run deepClean, then the build, so no cached unsigned archive is reused.

If a signing property is missing, the build fails at the signing task instead of producing an unsigned file. That failure is the intended behavior once skipModlSigning is off.

Check: open the new .modl as a zip. Certificate and signature entries now sit alongside module.xml, and the version in module.xml reads 1.0.1.

How do I push the rebuilt .modl past the stale-version upgrade bug?

8.3 early-access gateways have a second, related defect. After Install or Upgrade Module with a higher version, the gateway restarts but sometimes keeps running the previous version. A vendor-name test on a stale module proves nothing, so remove the old copy first.

1. In the gateway module list, uninstall the existing FalconGroupModules entry.
2. Restart the gateway.
3. Install the newly signed .modl.
4. When the gateway presents the module certificate, review the subject shown and accept it. A self-signed certificate is not chained to a public CA, so the gateway asks for explicit trust.
5. Accept the license.html terms and let the gateway finish loading the module.

Check: the module list shows version 1.0.1. If it still shows 1.0.0, the uninstall did not take. Repeat steps 1-3 before judging the vendor field.

Does the vendor now appear end to end from build script to gateway module list?

Walk every hop once more against the signed build.

1. Keystore: keytool -list -v shows the myalias1 owner as CN=Example Vendor with a matching O=.
2. Chain file: keytool -printcert -file myalias1.p7b shows the same subject and fingerprint.
3. Archive: the .modl contains certificate and signature entries, and module.xml carries au.com.falcon.group.modules at version 1.0.1.
4. Gateway install: the certificate prompt displays your subject, not a blank or foreign organization.
5. Dependency load: the module loads after com.inductiveautomation.perspective in Gateway and Designer scopes (GD) without faults in the gateway log.
6. Hook classes: the OneComponentGatewayHook starts on the gateway, and a Designer launch loads OneComponentDesignerHook.
7. Module list: the Vendor column for FalconGroupModules reads Example Vendor. If every earlier step passes and this column is still blank, the gateway build carries the unrepaired early-access defect. Re-run this same step on a newer 8.3 gateway build with the identical .modl.

FAQ