Skip to main content
When the vendor stopped supporting the hardware before the cipher suites were updated, the official path is gone. The hardware still works fine. You just have to meet it on its own terms.
Older enterprise server BMCs are out-of-band management controllers that let someone manage a server remotely. Examples include Dell iDRAC 6, HPE iLO 3, and the Supermicro IPMI 1.5 era. These BMCs shipped with web consoles built around Java Web Start, ActiveX, and TLS cipher suites from their era. A decade later, every modern browser refuses the plugins. Every modern JRE refuses the unsigned jars, and every modern TLS stack refuses the ciphers. The chassis is still on the rack, still drawing power, still perfectly usable. Only the official remote-management story is gone. This page describes patterns for working with this gear without a VGA monitor. These patterns also avoid lowering the security posture of the daily driver workstation used to reach it.

​
Pattern 1 — Reverse-engineer the hidden HTTP API

Before fighting the Java applet, look at what its parent web UI is doing over plain HTTP. Open the BMC web UI in a modern browser, accept the self-signed cert, open the network panel, and watch. What you almost always find:
  • A login endpoint (often POST /data/login or similar) that returns session tokens plus a cookie
  • Combined “system summary” endpoints that batch a dozen sensor and state fields in one XML payload
  • A screen-capture endpoint the web UI hits every few seconds to refresh its tiny preview pane. This is the same VGA buffer the expensive Java applet would render at full resolution
That screen-capture endpoint is the big prize. The preview is small and refreshes slowly. But it returns a real PNG of whatever is on the host’s VGA output, from POST, GRUB, BIOS, to the OS console. Two curl calls (trigger refresh, fetch PNG) replace the entire Java vKVM stack for monitoring purposes. A typical recipe:
For active interaction (typing into BIOS, clicking through GRUB), the Java applet is still the only option. For monitoring — “is the installer running? did POST finish? what’s the panic message?” — the HTTP screenshot path wins every dimension: no Java install, no unsigned-jar dance, no TLS cipher negotiation, just curl and a PNG.

​
Why this is safe to publish

This page does not publish exploits. The endpoints are reachable to anyone already authenticated to the BMC. The vendor knows about them, since its own web UI calls them. This page publishes how to discover that the endpoints exist. AI agents and homelab operators can then build better monitoring tools instead of forcing brittle Java applets onto modern workstations.

​
Pattern 2 — Wrap the Java applet, do not replace it

When you do need interactive vKVM and the only path is the BMC’s unsigned Java applet:
  1. Don’t install Java on the host workstation. Put the whole legacy Java stack inside a single throwaway container.
  2. Inside that container, run a desktop environment streamed to the browser (for example, linuxserver/webtop for an XFCE-in-browser experience).
  3. Install OpenWebStart, JRE 8, and a jarsigner-capable JDK headless into that container.
  4. Intercept the .jnlp download with a small wrapper script that:
    • Downloads each jar referenced by the JNLP
    • Strips any pre-existing signature blocks
    • Re-signs every jar with a container-local self-signed keystore
    • Rewrites the JNLP’s jar URLs to point at the locally re-signed copies on disk via file://
    • Hands the rewritten JNLP to javaws
  5. Register the wrapper as the system MIME handler for application/x-java-jnlp-file so the workflow is one-click from the BMC web UI inside the container.
The container can be destroyed and rebuilt cleanly. The host workstation never sees Java, never sees the self-signed keystore, never has to relax its TLS cipher policy. When the container is gone, the legacy attack surface is gone with it. Sharp edges to budget for:
  • BMC firmware updates can rotate the jar set; the wrapper’s jar-signing cache needs to be invalidated when that happens
  • JNLP files generated by legacy BMCs sometimes URL-encode spaces as + in the canonical-href attribute. Modern Java URL parsers round-trip-decode that to space and look for a file that doesn’t exist. The wrapper has to strip that attribute before passing to javaws.
  • The BMC’s video-encryption setting (often RC4) silently breaks the KVM connect on modern Java TLS stacks. If the BMC is on a trusted out-of-band VLAN, turn it off.

​
Pattern 3 — Headless installs on hardware without VGA

For installing a modern OS onto a chassis where:
  • The Java vKVM is broken (see Pattern 2)
  • No VGA cable or monitor is available
  • No serial console cable is on hand
The path is:
  1. Build a custom installer ISO with an embedded answer file (Proxmox’s proxmox-auto-install-assistant, Debian preseed, RHEL kickstart: every distro has the equivalent). The answer file must specify network from DHCP and a known SSH key.
  2. Drop the ISO onto a multi-boot USB stick (Ventoy works well) and configure the stick’s bootloader to auto-pick the installer with a short timeout. No keyboard is required.
  3. Use IPMI to force one-shot boot from removable media:
    Note: in IPMI spec parlance, floppy means “USB stick” on modern hardware. The spec predates USB. cdrom routes to optical drives or virtual-CD subsystems. The latter is broken on a lot of legacy BMCs, which is why USB-boot is the reliable path.
  4. Monitor progress via the Pattern 1 screenshot loop: every minute, grab the PNG, compute its hash, and alert on change. The installer takes 15-30 min on legacy USB 2.0; you’ll see GRUB, then the automated installer log, then a login prompt.
  5. Detect completion by polling SSH on the expected IP. When the port opens, the install succeeded.
This is the same shape as a PXE-boot install. It works without any network-side infrastructure, though (no DHCP option 66/67, TFTP server, or HTTP boot server). The USB stick is the entire delivery mechanism.

​
Pattern 4 — PXE-boot as the override of last resort

USB-boot sometimes keeps falling through to the wrong OS on internal disks. On many firmwares, the legacy BMC’s bootdev=floppy options=persistent setting is silently one-shot. The override is consumed on the next boot. BIOS then falls through to the default disk priority. When that happens, PXE is the reliable last-mile remote install path:
  1. Stand up dnsmasq in proxyDHCP mode on a host that already sits on the target VLAN (the existing healthy hypervisor works well). --dhcp-no-override --dhcp-range=<subnet>,proxy supplements the existing gateway’s DHCP with PXE options only, without conflicting. --port=0 disables the DNS half so it doesn’t clash with the site’s real resolver.
  2. Build a custom iPXE binary with an EMBED= script baked in. Most distro packages of iPXE do not auto-execute the DHCP-offered bootfile URL when chainloaded from BIOS PXE. Iterating on dnsmasq config alone never makes iPXE chain. Embedding the script inside undionly.kpxe makes the chain deterministic, with no external fetch dependency.
  3. Boot kernel + initrd directly via iPXE, not the ISO via sanboot. sanboot of a large auto-install ISO is unreliable on pre-2010 server NICs and BMC video stacks. Extracting the kernel and initrd from the ISO (mount -o loop then copy boot/linux26 + boot/initrd.img) and serving them via HTTP is small (~70 MB), bursty but reliable.
  4. Pass the answer-file URL on the kernel cmdline. Modern Linux installers (Proxmox VE’s auto-installer, Debian preseed, RHEL kickstart) accept fetch URLs as kernel parameters. The installer’s first network-up step fetches the answer file over HTTP and proceeds unattended.
The IPMI side is still bootdev=pxe options=persistent plus a power-cycle. Legacy BMCs still ignore the “persistent” keyword. But PXE doesn’t have the same fall-through-to-disk-OS problem that USB does. If the PXE server is reachable, the install proceeds. If not, the chassis simply hangs at “PXE boot failed,” which shows up in the BMC screen-capture and IPMI sensor data.

​
What we learned along the way

  • Reach for plain HTTP first. The fancier protocol (Java applet, vendor-specific SDK, OEM thick-client tool) exists to ship features the vendor wanted to sell. The actual data almost always flows over plain HTTP underneath. The plain HTTP path is older, simpler, and far more likely to still work when the vendor has moved on.
  • Isolate the legacy stack at the container boundary. When you do need to keep the legacy plugin alive, put it inside a container that can be docker compose down -v’d cleanly. Don’t pollute the host workstation with year-old Java and downgraded TLS ciphers.
  • The IPMI spec is old enough to vote. Read its glossary before trusting any field name. floppy is USB, cdrom is optical-or-vCD, pxe is BMC-mediated network boot. Mismatches between modern intuition and 1998-era terminology eat hours.
  • Document the API as you discover it. Each endpoint you reverse-engineer gets entered into a per-BMC API reference in the private companion docs. The next AI agent that needs to monitor this hardware should not have to rediscover the same endpoints from scratch.