Trusting the console certificate¶
Why the browser warns¶
The node serves its console over HTTPS. It issues its own certificate from a private certificate authority (CA) that it creates at first start. That CA is constrained to this node's names, so it cannot vouch for any other site.
No public CA can vouch for a device on a plant network. Your browser has never seen this CA, so it warns. The warning is expected until the CA is trusted on the computer you browse from.
Trusting the CA is a decision about the node, not about the browser. Confirm the fingerprint before you trust it, against a source you reached by another route. It is shown on Settings > Management TLS after you sign in, or ask an administrator for it.
Why some browsers show no "proceed" option¶
Some browsers show a warning with no way to continue. This is HTTP Strict Transport Security (HSTS). Once any service on a host name has told the browser to insist on valid TLS, the browser applies that to every port of the host and hides the bypass.
Trusting the node's CA is the fix. Flowgate itself asks for HSTS only once it serves TLS.
Until the CA is trusted, open the console from the node itself at https://127.0.0.1:<port>/. HSTS
is remembered per host name, so the loopback address is not blocked; the browser still warns, but it
lets you proceed. The Windows installer's Finished page names this address when the trust option is
left unchecked.
The installer option¶
On Windows, the installer offers Trust this node's certificate authority on this computer. It is checked by default. It imports the node's CA into the Trusted Root Certification Authorities store of the computer, so every browser that uses that store trusts the node.
For a silent install, pass /FGTRUSTCA=1.
After the CA is trusted, close and reopen the browser. A browser remembers that you clicked through its warning earlier in the session and keeps showing "Not secure" beside a certificate it now finds valid, until it is restarted.
To do it later, run this from an elevated prompt:
"<program folder>\flowgate-updater.exe" --trust-mgmt-ca
Other computers¶
On any other computer, download the CA from Settings > Management TLS > Download this node's CA
certificate, or open https://<node>:<port>/pki/ca.pem. Then import it:
- Windows: open
certlm.msc, right-click Trusted Root Certification Authorities, choose All Tasks, Import, and select the file. - macOS: add the file to the System keychain, then set "When using this certificate" to Always Trust.
- Linux: on Debian and Ubuntu, copy it into
/usr/local/share/ca-certificates/with a.crtextension and runsudo update-ca-certificates. On RHEL and its relatives, copy it into/etc/pki/ca-trust/source/anchors/and runsudo update-ca-trust. - Firefox: Firefox keeps its own store. Either import the file there, or turn on
security.enterprise_roots.enabledso it uses the operating system store.
Which names the certificate covers¶
When health.tls.hostnames is configured, the certificate covers exactly those names.
Otherwise it covers the short host name, the fully qualified name and the addresses the node had at its first start.
An address or name added later is not covered. Settings > Management TLS then shows a notice
listing the names not covered. If the node is reached by other names, configure
health.tls.hostnames to list them, then re-root.
Re-rooting¶
To cover new names, re-root the node:
- Delete the
ca-fingerprintfile in the node's management TLS folder. - Restart the node.
- Trust the new CA again on every client.
Plan for this. HSTS makes a stale trust a hard stop for one day: a browser that remembers the old CA will refuse the new certificate until the new CA is trusted.