JNLP Launcher

Open Avocent / Dell KVM .jnlp viewers on a modern Windows machine, without Java Web Start.

English · Português (Brasil)

---

The problem

You click Launch KVM Session on a Dell DSR/DSView switch, an iDRAC virtual console, or a Supermicro BMC. Windows downloads a .jnlp, javaws starts, and then:

JNLPException[category: Security Error : Exception: null : LaunchDesc:
<jnlp spec="1.0+" codebase="http://10.0.0.10:80/viewers">
...
    at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
    at com.sun.javaws.Launcher.prepareResources(Unknown Source)

Nothing is wrong with your network, your credentials, or the appliance.

Those viewer JARs were signed with SHA1withRSA, and current Java 8 builds ship SHA1 inside jdk.jar.disabledAlgorithms in lib/security/java.security. Java can no longer accept the signature, so it treats the JARs as unsigned — and since the JNLP requests <all-permissions/>, Web Start refuses to launch. You can confirm it yourself:

> jarsigner -verify -verbose:summary avctVideoV.jar
- Signed by "CN=Avocent Huntsville, LLC, ..."
    Digest algorithm: SHA1 (disabled)
    Signature algorithm: SHA1withRSA (disabled), 2048-bit key

The appliance firmware is frozen and will never be re-signed. Java will never re-enable SHA1.

The approach

Skip Web Start. Read the JNLP, download the JARs, unpack the native libraries, and call the application's main-class through java.exe directly:

java -Djava.library.path=natives -cp viewer.jar;native1.jar com.vendor.kvm.Main <args>

Plain java -cp never verifies JAR signatures — that check only exists in Web Start and the browser plugin. So the failure mode is structurally impossible, not worked around.

Why not the usual advice

Common suggestion	Why this is better
Edit java.security to re-enable SHA1	Weakens signature checking for every Java app on the machine, needs admin, and Java updates silently revert it
Set Java security level to Medium / add an Exception Site	Removed in modern Java 8; does not affect jdk.jar.disabledAlgorithms anyway
Keep an ancient JRE around just for KVM	Still needed here? No — this runs on the Java 8 you already have
Install OpenWebStart	Fine tool, but it is another runtime to deploy and maintain for one legacy applet

Nothing here modifies java.security, HKLM, the Java Control Panel, or your existing Java installs. javaws stays installed and functional.

Scope: what this does and does not fix

It fixes the JNLP/Web Start layer. Anything that fails before the viewer's own code runs — signature rejected, all-permissions refused, Web Start missing from Java 11+, security-level dialogs, cache corruption. The mechanism is generic: any JNLP with an application-desc and a main-class is launched the same way, whichever vendor wrote it.

By structure that should cover Avocent/Dell DSR and DSView switches, iDRAC 6/7/8 Java consoles (com.avocent.idrac.kvm.Main), AMI MegaRAC / Supermicro JViewer, and HP iLO 4 Java IRC. Only the Dell 4322DS is actually verified — see Tested with.

It does not fix, because none of these live in the JNLP layer:

• Appliances with no JNLP at all. iDRAC 9+, iLO 5+ and most modern BMCs use an HTML5 console. There is nothing here to launch — use the browser.
• Expired session tokens. The password= in a .jnlp dies within minutes. Download a fresh one.
• Credentials, licensing, firewall, session limits. iLO Advanced not licensed, port 5900 blocked, appliance already at max concurrent sessions — all unchanged.
• Viewers that call the JNLP API. If the applet uses ServiceManager.lookup("javax.jnlp.BasicService") it will throw UnavailableServiceException, because no Web Start container is present. None of the KVM viewers tested do this, but it is the one failure this design cannot avoid.
• JNLPs using <extension> or applet-desc. These are handed back to javaws, so you are where you started.
• Java 9+ only machines. These viewers need APIs removed after Java 8. Install a JRE 8.
• Firmware too old for your Java's TLS. -LegacyTls re-enables TLS 1.0/1.1 and usually settles it; below that, nothing in userland helps.

In short: if the error mentions checkSignedResources, JNLPException, or javaws not existing, this is your fix. If the viewer window opens and then something fails, the problem is the appliance or the network, and this project will not change it.

Requirements

• Windows
• Java 8 or Java 7, JRE or JDK — whichever you already have. Temurin 8 works and is free. Java 8 is preferred automatically; a 64-bit runtime is preferred over 32-bit.
• Network access to the appliance

Java 9+ will not work: these viewers depend on APIs removed after Java 8.

Install

git clone https://github.com/opastorello/kvm-jnlp-launcher.git
cd kvm-jnlp-launcher
.\Install.ps1

That copies src\ to %LOCALAPPDATA%\JNLP-Launcher and points .jnlp files at it.

If PowerShell blocks the script:

powershell -ExecutionPolicy Bypass -File .\Install.ps1

Then just download a .jnlp and double-click it. No console window, no Web Start, about two seconds to the viewer (JARs are cached after the first run).

What Install.ps1 changes

Exactly one registry value, under HKCU — your user only, no admin required:

HKCU\Software\Classes\JNLPFile\shell\open\command
  before : "...\javaws.exe" "%1"
  after  : "...\wscript.exe" "...\JNLP-Launcher\Launch-JNLP.vbs" "%1"

It also adds an Open with Java Web Start entry to the right-click menu as an escape hatch, and records the previous handler so uninstall can restore it exactly.

Uninstall

.\Uninstall.ps1              # restore the old association, keep cached JARs
.\Uninstall.ps1 -RemoveFiles # also delete %LOCALAPPDATA%\JNLP-Launcher

Usage

Double-clicking a .jnlp is the normal path. Direct invocation is available too:

$L = "$env:LOCALAPPDATA\JNLP-Launcher\Launch-JNLP.ps1"

& $L viewer.jnlp                # run it
& $L                            # run the newest .jnlp in Downloads
& $L viewer.jnlp -Console       # show the viewer's stdout/stderr
& $L viewer.jnlp -DryRun        # fetch and print the command line, don't launch
& $L viewer.jnlp -LegacyTls     # allow TLS 1.0/1.1 for this process only
& $L -ListJava                  # list detected Java runtimes and their bitness
& $L viewer.jnlp -JavaHome 'C:\Program Files\Java\jre1.8.0_491'

Every run appends to %LOCALAPPDATA%\JNLP-Launcher\logs\launch.log, with passwords masked.

How it works

1. Parse the JNLP: codebase, resources, property, argument, main-class.
2. Pick the JVM first — Java 8 before 7, 64-bit before 32-bit. The JVM's bitness (read from the PE header of java.exe, not from the OS) decides which nativelib block applies; a 32-bit JRE cannot load Win64 DLLs.
3. Select resources matching Windows and that architecture. href may be relative to codebase or absolute — both are handled.
4. Download and cache into lib\<host>\. Keyed by host on purpose: different appliances publish same-named JARs with different contents, so a flat cache corrupts one vendor's viewer with another's.
5. Accept self-signed certificates during download — BMCs never have a valid chain. Falls back to Windows' curl.exe when .NET refuses the appliance's TLS version.
6. Unpack .dll files from the nativelib JARs and point java.library.path at them.
7. Quote arguments per CommandLineToArgvW. This matters: JNLP arguments contain literal double quotes, e.g. path=a:10.0.0.10,r:XXXXXX,c:0,e:1,s:"SRV-01",l:120. Naive quoting splits that argument and the viewer fails to connect.
8. Launch javaw.exe detached, so the viewer outlives the script.

If a JNLP uses something outside this scope — applet-desc, <extension>, no main-class — the launcher hands it to javaws instead of failing.

Troubleshooting

A "Certificate" / "Security Warning" dialog appears. That is the appliance's self-signed certificate, not Java Web Start. Accept it and tick always trust. If it reappears every session, Java cannot persist preferences — create the key once, from an elevated PowerShell:

New-Item -Path 'HKLM:\SOFTWARE\JavaSoft\Prefs' -Force

Authentication fails. The password= inside a .jnlp is a single-use session token that expires within minutes. Generate a fresh .jnlp from the appliance's web UI. The log warns when the file is more than five minutes old.

TLS handshake fails on old firmware. Java 8 disables TLS 1.0/1.1 by default. Use -LegacyTls, which writes a java.security override applied only to that process — the JRE's own configuration is untouched.

"No Java 8 or Java 7 runtime found." Run -ListJava to see what was detected, install Temurin 8, or pass -JavaHome.

Nothing happens on double-click. Run the same file with -Console to see the error; association launches are windowless and only pop up a dialog on failure.

Not a launcher problem, but you will hit it

Ctrl+Alt+Del reboots the server instead of unlocking it. The KVM only forwards keystrokes; the target OS decides what they mean. On Linux with systemd, ctrl-alt-del.target is an alias of reboot.target, so the sequence really is a reboot command. Windows unlocks normally — if a Windows target reboots, it was not at the logon screen but at POST/BIOS, where Ctrl+Alt+Del is a warm reset by definition.

Disable it on each Linux host:

sudo systemctl mask ctrl-alt-del.target
sudo systemctl daemon-reload
systemctl status ctrl-alt-del.target    # should read "masked"

Check the kernel level too. If this reads 1, the kernel resets immediately without consulting init, and masking the target changes nothing:

cat /proc/sys/kernel/ctrl-alt-del       # 0 = init decides | 1 = immediate reset
sudo sysctl -w kernel.ctrl-alt-del=0
echo 'kernel.ctrl-alt-del = 0' | sudo tee /etc/sysctl.d/99-no-cad.conf

On pre-systemd init, comment out ca::ctrlaltdel:/sbin/shutdown -r now in /etc/inittab. Even with the target masked, systemd still force-reboots on seven Ctrl+Alt+Del within two seconds, so do not hammer the key.

Ctrl+Alt+Del does nothing at all. Pressing it on your own keyboard never reaches the target: Windows intercepts it locally as the Secure Attention Sequence. Send it from the viewer's Macros menu instead.

Tested with

Appliance	Viewer	Result
Dell 4322DS console switch (Avocent)	avctVideoV.jar 5.04.04 build 454, com.avocent.msd.kvm.Main	Works on Java 8u491 and 7u80

Reports for other appliances are welcome — please open an issue with the JNLP structure (with credentials, tokens, hostnames and IPs removed).

Security notes

• .jnlp files contain a username and a live session token in clear text. They are in .gitignore here; do not attach one to an issue without scrubbing it.
• The launcher deliberately skips TLS certificate validation when downloading JARs from the appliance, because BMC certificates are self-signed by nature. On a management network this matches what every vendor's own client does. It does not affect anything else on your machine.
• Running unsigned code from an appliance is exactly what Web Start did here too — the signature was already being ignored, just loudly.

License

MIT — see LICENSE.