Trusting the console's certificate

The console serves its surface over HTTPS. It has to: no browser will speak HTTP/2 without TLS, and HTTP/2 is what lets one tab hold every live meter, fader and stream the surface displays over a single connection.

The certificate it serves is one it issued itself, signed by its own local authority. That authority is not on the internet's list of the ones every browser already knows, so a browser meeting the console for the first time says the connection is not private. Nothing is wrong. The browser is telling you, correctly, that it has never been introduced.

This page is the introduction. It is one step per device, once.

Why not a real certificate

A publicly-trusted certificate is issued to a domain name, by an authority that checks you control that name — either by answering on port 80 from the public internet, or by writing a record into the name's DNS zone. A mixing console on a show LAN has neither. It has a hostname, an mDNS name, and whatever address the DHCP server handed it this morning. There is no zone to answer in.

The second reason matters more on a show day. Public certificates expire in about ninety days and are renewed automatically over the internet. A console in a truck with no uplink would eventually boot with an expired certificate, and it would do it at the worst possible moment, behind a browser error page nobody can read past. The console's own authority is valid for ten years and renews its certificate locally, without asking anyone.

If a console is ever given a real DNS name in a zone with an API token, that trade changes and is worth revisiting. Until then, this page is the cost, and it is paid once per device.

The console itself is already done

When openmixer-web-ui is installed it issues the certificate and installs the authority into that machine's own system trust store. A browser running on the console never sees a warning. Uninstalling the package takes the authority back out again; the certificate files stay, so reinstalling does not send you round every device a second time.

Everything below is for the other devices — the tablet at the desk, a phone on the wing, a laptop in the truck.

A device typing the address is not the only way in. The console's own Help → About shows a QR code for its address — scan it from a phone or tablet already sitting near a trusted screen instead of typing an IP address off a truck floor. It opens the console directly; a device meeting this console for the first time still lands here first, on this page's own address, which About prints beside the QR.

Get the certificate

Every console serves it, in plain HTTP, at a fixed address:

http://<console>:8880/trust/

That page carries the download and the same per-platform steps as this one, so you can reach it from the device you are setting up without copying a file off a laptop.

The plain port exists for exactly this and serves nothing else — a device that trusts nothing cannot use HTTPS to fetch the thing that would give it trust. Everything else on that port redirects to the HTTPS origin.

The file itself:

http://<console>:8880/trust/root.crt

Install it

Linux

Fedora, RHEL and relatives:

sudo cp openmixer-root.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

Debian, Ubuntu and relatives:

sudo cp openmixer-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

If the machine has openmixer installed, the console's own script does whichever of those two applies, knows how to undo it, and is safe to run twice:

sudo /usr/libexec/openmixer/anchor-local-ca.sh openmixer-root.crt
sudo /usr/libexec/openmixer/anchor-local-ca.sh --remove openmixer-root.crt

Chromium and Chrome

Nothing further on Linux, macOS or Windows — they read the operating system's store, so the step above is the whole job. On Android, see below.

Firefox

Firefox keeps its own store and ignores the system one. Installing the certificate for the operating system changes nothing in Firefox, and the symptom is identical to not having installed anything at all. Do one of these:

• Open about:config, accept the warning, and set security.enterprise_roots.enabled to true. Firefox then reads the system store and the step above starts working. Restart Firefox.
• Or import it directly: Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import…, choose the file, and tick Trust this CA to identify websites.

Windows

Double-click the file → Install Certificate → Local Machine → Place all certificates in the following store → Browse… → Trusted Root Certification Authorities. It must be that store; the one Windows offers by default will not work. Restart the browser.

macOS

Double-click the file to open Keychain Access and add it to the System keychain.

Then — and this is the step people miss — find it in the list, open it, expand Trust, and set When using this certificate to Always Trust. An imported-but-untrusted root fails exactly like no root at all.

iOS and iPadOS

Open the trust page in Safari and tap the download; allow the profile. Then install it: Settings → General → VPN & Device Management → openmixer → Install.

Then, separately: Settings → General → About → Certificate Trust Settings, and turn on full trust for openmixer console local CA. The profile alone does nothing, and again the symptom is indistinguishable from having skipped the whole page.

Android

Settings → Security & privacy → More security settings → Encryption & credentials → Install a certificate → CA certificate, accept the warning, and pick the downloaded file. The exact path varies by vendor; searching the settings for CA certificate finds it.

It lands in the user store. Chrome honours it; some apps do not. That is Android's rule, not the console's.

The names the certificate covers

A browser checks the name you typed against a list inside the certificate, and refuses anything not on it — even with the authority installed. The console puts the names it can see at the moment it issues:

• localhost, 127.0.0.1 and ::1
• its hostname, and its .local mDNS name
• its hostname under each domain its resolver searches (console.lan, if the DHCP server hands out a lan search domain)
• every non-loopback address it held when the certificate was issued

The .local name is the one to teach people. Addresses move with a DHCP lease; the mDNS name does not.

If the console's address has changed since the certificate was issued, reaching it by the new address warns again. Re-issuing fixes it and costs nobody a second trip round the devices — they trust the authority, and the authority does not change:

sudo rm /etc/openmixer/tls/console.crt /etc/openmixer/tls/console.key
sudo /usr/libexec/openmixer/issue-local-ca.sh /etc/openmixer/tls
sudo nginx -t && sudo systemctl reload nginx

The reload is deliberate and is the operator's call: it drops every open connection, so every surface re-dials at once. Do it between shows, not during one.

nginx -t or the reload fails outright, cannot load certificate … Permission denied, on a console issued before 2026-09-08: the older issuer minted the pair in a scratch directory under /tmp and mvd it into place, and mv never relabels — the files kept /tmp's SELinux label instead of picking up /etc/openmixer/tls's. Fixed issuers write the certificates in place under /etc/openmixer/tls and relabel what they wrote as their own last step, so a re-issue on an updated console does not hit this; on a console still running the older issuer, or on files left behind from before the update:

sudo restorecon -F /etc/openmixer/tls/*

If it still warns

Removing it

Reverse whichever step you followed. On Linux, anchor-local-ca.sh --remove does it. The console removes its own when the package is uninstalled.