TLS certificates & PKI

The appliance serves HTTPS from first boot. Where the certificate comes from is your choice — made once in the wizard and changeable any time after.

The four certificate modes

Mode	What happens	Choose it when
`selfsigned`default	The appliance generates its own three-tier chain (below) and serves it immediately. Works fully offline.	Labs, evaluations, and any site without an internal CA. Replace it later without reinstalling.
`import`	You provide a PEM certificate (full chain preferred) and its unencrypted private key.	You have an enterprise CA — best experience, nothing to install on clients.
`acme`	Obtains a certificate from Let’s Encrypt.	The FQDN resolves publicly and port 80 is reachable from the internet. Not usable on isolated networks.
`none`	Plain HTTP.	Almost never. Passkey/FIDO2 login will not work without HTTPS (why); password login still works.

The appliance-signed chain (selfsigned mode)

Rather than a single bare self-signed certificate, the appliance builds a proper miniature PKI:

Innovexus Root CA          10-year validity      ← install THIS on client machines
  └ Innovexus Issuing CA    5-year validity       (served in the TLS chain)
      └ server certificate  825-day validity      CN + SANs: your FQDN and the
                                                   appliance's IP addresses

Clients install only the root CA — the appliance serves the intermediate alongside the leaf. Installation steps per platform: FIDO2 & passkeys.
The leaf carries IP SANs too, so https://<ip>/ shows a clean padlock once the root is trusted (passkeys still require the FQDN).
Both CAs are registered in the web UI under ADMIN → PKI → Trusted Certificate Store, where the root can be downloaded and, when your organization’s PKI is ready, replaced.
The appliance withholds HSTS in this mode on purpose: pinning HTTPS on a certificate a client hasn’t trusted yet would lock operators out with no click-through.

Verifying what is served

innovexus> show certificate
subject=CN = innovexus.example.com
issuer=CN = Innovexus Issuing CA, O = Innovexus
notBefore=Aug 25 14:02:11 2026 GMT
notAfter=Nov 28 14:02:11 2028 GMT
X509v3 Subject Alternative Name:
    DNS:innovexus.example.com, IP Address:192.0.2.10
sha256 fingerprint: 4A:1B:…
source: appliance
root CA fingerprint: 9C:D2:…
(download the root CA from the web UI: ADMIN > PKI > Trusted Certificate Store)

Compare the root CA fingerprint here with the file you are about to trust on a workstation — they must match exactly.

Replacing the certificate later

From the CLI: configure tls re-runs just the certificate step — switch from selfsigned to import when your enterprise CA issues a certificate, or re-issue after a hostname change.
From the web UI: ADMIN → PKI offers generate/import for the appliance HTTPS certificate.
After changing the FQDN (configure hostname), always re-issue — the served name, the certificate subject and the WebAuthn RP ID must agree, and previously registered passkeys are bound to the old name (details).

Clock skew breaks certificates. A certificate minted by an appliance whose clock is wrong can be “not yet valid” for every client. The wizard asks for NTP before the certificate step for exactly this reason — if you skipped it, fix time first (Time, NTP & DNS), then configure tls.