We have an in-house-only app that can be run from both Unix workstations and Windows PCs. Some background of our environment:
- The Unix system is "live" (read/write) whereas the Windows system is a read-only system of day-old data.
- The Unix users have the option to run from the command line (using a shell script provided), or via Java Web Start.
- The Windows users can only run via Java Web Start.
- The Unix system has no internet access, but the Windows system does.
- The security setting in the jnlp is set to "all-permissions", which is currently needed.
- The app is compiled on the Unix system with Java 5, and the jars are self-signed from there. The app is then deployed to the Unix system, and then "sneaker-netted" over to the Windows system.
Problem: With the security updates to Java 7, some users on the PCs are having trouble launching the app, since it's self-signed.
Q1: Sifting through the mountain of documentation, it appears that self-signing will soon be a thing of the past, and that the app won't run at all. Is this an absolute? I can't find a definitive answer that applies to in-house JWS apps that aren't deployed outside of a local, restriced domain.
Q2: Making changes to our code so that it can run as a sandboxed app would not be trivial. Would doing so solve this, or will we still be stuck with the security issues?
Q3: Would distributing/installing/registering/whatever-ing our self-made certificate to the clients solve this?
Any help or suggestions <cough> Andrew Thompson I'm talking to you </cough>
is appreciated.
EDIT: We do have the option of signing our jars with a trusted Root CA, but the signing would not be done by us (long story) and would make our deployment rise from a couple of hours to many days, which is why we're wondering if an alternate route is available for in-house apps.