Note
The certificate on a new JACE
A controller is secure out of the box in the narrow sense that the traffic is encrypted. It is not authenticated, and the difference only becomes visible later.
- TLS
- Certificates
- Commissioning
Where the first certificate comes from
The first time a Workbench installation, a platform or a station starts after
commissioning, the system generates a default self-signed server certificate with
the alias tridium, using its own 2048-bit private key. Nobody asked for
it and nothing prompts you about it.
It is self-signed in the literal sense: open it and the Issuer DN and the Subject DN are the same name. There is no authority above it saying it is what it claims to be.
What it is actually for. Tridium's documentation is clear that the purpose is to allow secure access to a platform or station before a trusted certificate tree exists. It is the scaffolding for commissioning, not the finished security posture, and because a client cannot validate it, it is explicitly not recommended for robust long-term use.
Three things about the default certificate that surprise people
- It cannot be deleted. From Niagara 4.13 the default certificate
created on first platform access is also the recovery certificate, protected by
the global certificate password. On a host upgraded from before 4.13, an existing
tridiumcertificate carries on being used but does not serve as the recovery certificate — worth knowing before an upgrade, not after. - Do not export it to another host. Copying one platform's self-signed certificate into another platform's store is possible and is a downgrade in security every time.
- Accepting one is a commitment. Once you approve a self-signed certificate you are not asked again — and if its public key later changes, the green shield in Certificate Management becomes a yellow warning and access is denied until somebody accepts the new key. That is the correct behaviour and it looks exactly like a fault.
The platform settings worth checking on every commission
Right-click Platform, open Views > Platform Administration, then
Change TLS Settings:
| Setting | Default | Worth changing? |
|---|---|---|
| State | TLS only | No. Anything else on a controller reachable by more than one person is a decision to justify in writing. |
| Port | 5011 | Only if the site's firewall policy says so. |
| Certificate Alias | the default self-signed certificate | Yes, eventually — this is where a signed server certificate gets selected once one exists. |
| Protocol | TLSv1.2+ | Raise to TLSv1.3 where every client supports it. Never drop to TLSv1.0+ to make an old client work without writing down why. |
What expiry actually breaks, and what it does not
This is the part that makes certificate expiry dangerous rather than merely annoying: it does not fail all at once.
- Browsers start warning that the certificate is not trusted — and still connect.
- Workbench connects.
- FOXS connections between stations that use Allowed Hosts exemptions still connect.
- FOXS connections between stations without those exemptions fail to reconnect, and stay failed until the certificates are reissued.
So an estate can pass an expiry date looking fine, and lose exactly the station-to-station links that were set up properly. The sites that did the security work are the ones that break first.
Set the alarm now, not the reminder. An alarm extension can be
added to the server certificates under the SecurityService to raise an
alarm 30 days before expiry. Thirty days matters: if the site uses a third-party CA,
the reissue process can take a couple of weeks on its own. From Niagara 4.14 the
Signing Service can renew certificates, which shortens the internal case but not the
external one.
A reasonable order of work
- Commission on the default certificate. That is what it is for. Do not spend the first day of a job on PKI.
- Decide self-signed-root or third-party CA before handover, because the lead time is entirely different and only one of them is free.
- Issue and install the server certificates, then point the platform TLS settings and the station's web service at them.
- Add the 30-day expiry alarms and record every expiry date somewhere that outlives the engineer who set it.
Related
Where this comes up in the work
Station engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
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.
More notes
Other things worth writing down
Which Niagara version to stamp a module for
A module's declared dependency version is a floor, not a pin. Build against the newest SDK you have and stamp for the oldest station it has to load on.
- Module development
- Mixed estates
- Build tooling
What a station checks before loading a module
Niagara's three module verification modes, what each one demands of your certificate, and why the setting cannot be relaxed from the command line.
- Module signing
- Certificates
- Deployment
Pure Java, or it will not run on a JACE
A controller is an ARM host with a fraction of a server's memory. Native libraries, JNI and heavyweight dependencies do not survive the move from a PC.
- JACE
- Controllers
- Module development
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.