Niagara TLS and Certificates Troubleshooting Guide (Workbench, Web, and Station-to-Station)

TLS failures in Niagara typically fall into three categories: (1) trust problems (untrusted CA or missing chain), (2) certificate lifecycle problems (expired, not-yet-valid, or hostname mismatch), or (3) protocol and port mismatch (fox vs foxs vs foxwss, HTTP vs HTTPS). Use this checklist to diagnose quickly.

Problem

You cannot connect to a station or platform securely; Workbench shows TLS errors; the browser shows certificate warnings; or station-to-station links fail after security changes.

Root Cause

• The station or platform is presenting a certificate that clients do not trust, or clients have not approved it.
• The certificate is not valid for the hostname being used (SAN/CN mismatch) or is expired.
• You are using the wrong protocol/port combination (fox vs foxs vs foxwss; HTTP vs HTTPS).

Solution

Step A: Identify how you are connecting

Connection type	Protocol	Notes
Browser (Web UI)	HTTP / HTTPS	Standard web ports
Workbench to Station	fox / foxs	fox = unencrypted, foxs = TLS
Station-to-Station driver	foxs	Typically encrypted
WebSocket-based	foxwss	If enabled; uses standard web ports

Step B: Confirm the expected ports

Protocol	Default port	Notes
fox (unencrypted)	1911	Not recommended for production
foxs (TLS)	4911	Niagara secure baseline
foxwss (Fox over WebSocket)	443	Leverages standard HTTPS port

Step C: Certificate validity checks

• Verify system time on the host and client—time skew causes "not yet valid" failures.
• Confirm the hostname used in the URL is covered by the certificate identity fields (SAN or CN).
• Confirm the certificate expiry date and plan renewal cycles proactively.

Step D: Workbench trust and approval workflow

If you see certificate-related UI errors (including help or webstation access issues), check Workbench certificate management. Unapproved hosts and certificates must be approved or regenerated before smooth operation. This is the same failure mode seen in "Cannot Load Help" issues.

Step E: Post-hardening connectivity breaks

After hardening changes (HTTPS-only enforcement, stronger authentication policies), station-to-station connections may fail unless all supervisors and JACEs are updated to the new credentials and to HTTPS/foxs endpoints.

Step F: When to rebuild vs when to re-trust

Symptom	Action
Valid certificate, but not trusted	Fix trust chain or approve in Workbench
Expired or wrong hostname	Re-issue and redeploy across Fox/Web/Platform endpoints
Port mismatch	Update connection string to correct protocol and port

Field Notes / Gotchas

• foxwss is designed to use port 443, which often passes through firewalls without special rules—useful for cloud-connected scenarios.
• If you regenerate a station certificate, any Workbench installations that previously approved the old certificate will flag the new one. Re-approve on each client.
• Always check system clocks first—incorrect time is a common and fast-to-diagnose cause of TLS failures.