HTTPS and Secure Boot
Blue View Imaging installs can force all web traffic — including the boot process itself — over HTTPS. Separately, client machines can have UEFI Secure Boot enforced, which restricts firmware to running only boot software it has a reason to trust. Each feature is straightforward on its own. Run into both on the same fleet, and they interact in a way worth understanding before you turn either one on.
What forcing HTTPS does to the PXE loader
The PXE loader — the small binary client firmware fetches over TFTP and runs first, before anything else from Blue View Imaging — normally comes from a prebuilt release. That prebuilt binary is generic: it works identically on every install, which is exactly why the installer can just download it rather than build it.
An HTTPS install can't use that generic binary as-is. Once boot.php and the rest of the web application are served over TLS, the PXE loader itself has to trust the certificate authority behind that TLS connection in order to fetch anything from it — and a generic, one-size-fits-all binary has no way to know in advance which server's certificate it will be talking to. Blue View Imaging installs generate their own certificate authority at setup, self-signed and specific to that server, and no client firmware trusts a self-signed CA it has never seen. So when HTTPS is forced, the installer does not download the loader — it rebuilds it locally from source, embedding that server's own CA into the binary so it can validate the HTTPS connection when it fetches boot.php.
Why the prebuilt Secure Boot chain can't come along
Separately from the plain loader, the installer also publishes a Secure Boot–specific version of it: a chain of binaries signed by Microsoft (for the first-stage shim) and by the iPXE project itself, republished byte-for-byte from upstream. That signature is what lets Secure Boot firmware — which already trusts Microsoft's keys out of the box on essentially all PC hardware — run the loader without any per-machine setup.
A locally rebuilt binary cannot carry that signature. Signing covers the exact bytes of a file; changing the file — which is what building a new binary with a different embedded CA does — invalidates any signature that was made over the old bytes. There's no way to take an already-signed release binary and also bake this server's CA into it, and no way to rebuild the binary and keep the old signature valid. Blue View Imaging's installer recognizes this directly: on an HTTPS install, it skips staging the Secure Boot binaries at all, because a binary an admin can see sitting in the directory but which fails at the client with a TLS error is worse than not having it.
The result is that a locally rebuilt HTTPS loader carries no Secure Boot signature whatsoever — not a signature from an unfamiliar authority, but none at all. Secure Boot firmware refuses to run it before the question of which certificate authority to trust is ever reached.
A separate, unrelated signing feature: FOS kernel signing
Blue View Imaging has its own Secure Boot signing feature, and it is easy to conflate with the loader problem above — it solves a different, later stage of the same boot chain. By default, every install generates its own Secure Boot signing certificate and re-signs the FOS kernels (the Linux images the loader fetches and boots into once it's running) every time they're downloaded or updated, so an upgrade never silently leaves a fleet with unsigned kernels.
Getting client firmware to trust that certificate requires enrolling it once, per machine, into what UEFI calls the Machine Owner Key (MOK) database — the same mechanism used to trust any custom Secure Boot key outside the vendor-supplied set. The installer publishes an enrollment kit for this at service/secureboot/ under the web root — for example https://<your-imaging-server>/fog/service/secureboot/ — containing the certificate to enroll, an enrollment script, and a desktop launcher. FOG Configuration's Secure Boot page shows the certificate's fingerprint and links to these files.
This kernel-signing feature does not help with the loader problem described above. It operates one stage later in the chain, after the loader has already run — and forcing HTTPS breaks the chain at the loader stage, before kernel signing is ever reached, regardless of whether kernel signing is configured.
What this means for a fleet with Secure Boot enforced
If some or all of your client machines enforce Secure Boot, forcing HTTPS on the server puts you in one of three positions:
Don't force HTTPS, at least not in a way that changes how the loader is built. This keeps the fully supported path available: the prebuilt Secure Boot chain runs on unmodified trust already present in the firmware, and per-machine MOK enrollment (described above) covers the kernel-signing side. This is the path of least resistance if Secure Boot matters to you.
Disable Secure Boot on the affected machines. The locally rebuilt HTTPS loader then runs without restriction, at the cost of Secure Boot's protection against unsigned or tampered boot software on those machines.
Keep both, and accept there is no supported path. Nothing in the installer produces a locally rebuilt, HTTPS-trusting loader that also carries a Secure Boot signature. An admin who insists on both would need to sign that rebuilt binary out-of-band with their own tooling and get the corresponding certificate enrolled into every client's MOK database before deployment — work the product does not automate for you.
Whichever of the first two you choose, remember that MOK enrollment itself is a physical, per-machine act: it requires booting the target machine from removable media, running the enrollment script, and confirming a fingerprint match at the keyboard. There is no remote or bulk enrollment path — a script cannot enroll a key on a machine it isn't sitting in front of, because that would defeat the point of requiring physical presence. Plan for that time cost across a fleet before committing to a Secure Boot rollout, rather than discovering it machine by machine.