Deploying Java 7 JRE – Deep Dive! (Part 1)

by

NO JAVAWe have all had troubles with Java and quite frankly its been a challenge to keep up with all the changes. Between Java 7 Update 10 through to update 45 there have been changes in features and functions that affect how IT administrators deploy the software in an enterprise, let alone general software functionality (wont be covering that). I think the best outcome of all of this is Oracle’s commitment to supporting enterprise deployments of Java.

In Part 1 (this article) I will cover off the things that have changed over the past 10 minor versions and how they may affect you. Also I will cover off what steps are required for a Windows client to be setup and function correctly in an enterprise.

Part 2 here I will cover the method I have used to deploy Java to our Windows 7 clients, including the technical details for you to be able to do it yourself.

I must warn you all, the following article series will be long so I ask you to read carefully, as well all the reference articles if anything is unclear. As usual I’m always happy to follow up with queries if anyone is uncertain.

*Note we have not performed extensive testing for all scenarios of this approach and would love to hear if any of it could be improved. My script is a humble batch file, and as such is not the most sophisticated – improvements are welcome. Lastly there are many ways to achieve a final goal, this is but one way that I chose to use.

What has changed recently with Java 7?

Ever since Oracle has taken action to actively resolve the security problems within Java they have made some substantial changes to the core of the Java Runtime Engine especially how it deals with being outdated. In detail you can review the release notes here (http://www.oracle.com/technetwork/java/javase/7u-relnotes-515228.html).

I have extracted the below key points straight from the release notes that can affect your deployments. They have been split out per version below:

Java 7 Update 10

  • JRE Expiration Date
    The JRE relies on periodic checks with an Oracle Server to determine if it (the JRE)is still considered up-to-date with all the available security fixes (above the security baseline). In the past, if the JRE was unable to contact the Oracle Server, it continued to behave as though it is still the most recent version with regard to security, for an indefinite period.
    To avoid this problem, a secondary mechanism, that does not rely on external communication, has been added to the JDK 7u10. From this release onwards, all JREs will contain a hard-coded expiration date. The expiration date is calculated to end after the scheduled release of the next Critical Patch Update.
    This means that JREs that are unable to contact Oracle Servers for an extended period of time, will now start offering additional protection after a reasonable period, and will not continue to behave as if they were still up-to-date with security fixes.

Java 7 Update 15

  • Auto-update and update through Java Control Panel of JRE 6 will replace JRE 6 with JRE 7
    Since JRE 6 has reached its End of Public Updates Oracle is taking steps to protect consumer desktops. We will not leave a version of Java installed for which we no longer provide security updates .In order to do so, when updating from JRE 6, the update mechanism will not only install the latest version of JRE 7 but will also remove the highest version of JRE 6 on the system. This change will happen when the system is updated via the auto-update mechanism or by checking for updates directly from the Java Control Panel.
    Users who need to keep a version of JRE 6 in their systems can do so by manually installing the latest version of JRE 7 rather than relying on auto-update or updates through the Java Control Panel.
    If JRE 6 has already been removed from a system, but the user would like to restore it, earlier versions of Java can be accessed from the Java Archive.
    Note that Oracle strongly recommends leaving only up-to-date versions of the JRE on desktops. Retaining an older version of the JRE in your systems should only be done by expert users or enterprise administrators with a need for those earlier versions and an understanding of the associated risks.

Java 7 Update 21

  • JRE Expiration Date
    The expiration date for JRE 7u21 is 07/18/2013.
  • Blacklisted Jars and Certificates
    Oracle now manages a certificate and jar blacklist repository. This data is updated on client computers daily on the first execution of a Java applet or web start application.
  • Changes to Java Control Panel’s Security Settings
    In this release, low and custom settings are removed from the Java Control Panel(JCP)’s Security Slider.
    Depending on the security level set in the Java Control Panel and the user’s version of the JRE, self-signed or unsigned applications might not be allowed to run. The default setting of High permits all but local applets to run on a secure JRE. If the user is running an insecure JRE, only applications that are signed with a certificate issued by a recognized certificate authority are allowed to run.
    For more information, see the Security section of the Java Control Panel documentation.
  •  Changes to Security Dialogs
    As of JDK 7u21, JavaScript code that calls code within a privileged applet is treated as mixed code and warning dialogs are raised if t

    Java Update Needed
    Java Update Needed

    he signed JAR files are not tagged with the Trusted-Library attribute.
    For more information, see Mixing Privileged Code and Sandbox Code documentation.
    The JDK 7u21 release enables users to make more informed decisions before running Rich Internet Applications (RIAs) by prompting users for permissions before an RIA is run. These permission dialogs include information on the certificate used to sign the application, the location of the application, and the level of access that the application requests. For more information, see User Acceptance of RIAs.

  • Changes to Application Signing
    Security Warning - Unsigned Application
    Security Warning – Unsigned Application

    Starting from JDK 7u21, it is recommended that all applications be signed. In addition, it is also possible to restrict signed applications to the security sandbox.Therefore, the previous use of the term “unsigned” to mean an application that ran in the security sandbox and “signed” to mean an application that ran with extended permissions, is no longer meaningful.
    The terminology in the Java Tutorial and the Java SE Guides has been changed to use “sandbox application” for applications that are restricted to the security sandbox, and “privileged application” for applications that have extended permissions.Unsigned or self-signed applications may not be supported in future JDK update releases.
    For more information on signing applications, see Understanding Signing and Verification. Deploying with Applet Tag describes setting permissions for an applet within the applet tag.

Java 7 Update 25

  • JRE Expiration Date
    The expiration date for JRE 7u25 is November 15, 2013.
  • Certificate Revocation
    Before signed Java applets and Java Web Start applications are run, the signing certificate is checked to ensure that it has not been revoked. Advanced options in the Java Control Panel(JCP) can be set to manage the checking process. For more information on these options, see the Advanced section of the Java Control Panel documentation.
    Under normal circumstances revocation checking will have a slight impact on startup performance for applets and web start applications. Enterprises with managed networks and without access to the Internet (resulting in no access to the revocation services provided by Certificate Authorities) will see a significant delay in startup times.
    To avoid such delay, they may choose to disable on line revocation checking through the JCP. Note that disabling on line revocation checking should only be considered in managed environments as it decreases security protections.

Java 7 Update 40

  • JRE Expiration Date
    The expiration date for JRE 7u40 is 12/10/2013. After this date, Java will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
  • Deployment Rule Set
    Deployment rule set allows a desktop administrator to control the level of Java client compatibility and default prompts across an organization.
    For a summary of this feature, see Deployment Rule Set documentation.
  • Option to disable the “JRE out of date” warning
    Starting from 7u40, a new deployment property deployment.expiration.check.enabled is available. This property can be used to disable the “JRE out of date” warning.
    When the installed JRE (7u10 or later), falls below the security baseline or passes it’s built-in expiration date, an additional warning is shown to users to update their installed JRE to the latest version. For businesses that manage the update process centrally, users attempting to update their JRE individually, may cause problems.
    To suppress this specific warning message, add the following entry in the deployment properties file:
    deployment.expiration.check.enabled=false
    For more information, see Deployment Configuration File and Properties.
  • New Security Warnings for Unsigned and Self-Signed Applications
    New warnings are added in the dialogs for Unsigned and Self-Signed applications.
    From the dialogs for Unsigned and Self-Signed applets, “Remember this decision” option has been removed. In addition, the previously remembered decisions for self-signed and unsigned applets will be ignored.
    For more information, see Security Dialogs.
  • Bug Fixes
    Area: deploy/plugin
    Synopsis: Aborting the update after clicking “Update” on the “Java is insecure” warning message forwards all applets to java.com/download.
    When an older JRE is installed on the system, launching a web page with an applet prompts the user with “Java is insecure” message. If the user clicks on the “Update” button on the message but later aborts the update process, user is automatically redirected to http://java.com/download page.
    This is not the expected behavior. The issue is fixed in JDK 7u40 release.

Java 7 Update 45

  • JRE Expiration Date
    The expiration date for JRE 7u45 is 02/14/2014. After this date, Java will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
  • Restore Security Prompts
    A new button is available in the Java Control Panel (JCP) to clear previously remembered trust decisions. A trust decision occurs when the user has selected the Do not show this again option in a security prompt. To show prompts that were previously hidden, click Restore Security Prompts. When asked to confirm the selection, click Restore All. The next time an application is started, the security prompt for that application is shown.
    See Restore Security Prompts under the Security section of the Java Control Panel.

So what do all these changes mean?

From what I can see in the industry, it appears as though the owners of Java, Oracle, are making an effort to combat security issues by actively updating their software to better secure the client from vulnerabilities. They may not have provided adequate enterprise tools in parallel to the updates however I feel they have corrected critical issues\pain points within a reasonable time-frame.

For an administrator it means there have been lots of good changes but did cause a bumpy ride for some. If you you were one of those eager security conscious admins who wanted to apply the latest Java versions, you may have got yourself into a pickle with version 25 due to additional security prompts that you might not have been aware would occur, and that were difficult to disable. These security prompts would become evident after a particular date, if it was not updated to the next version.

NOTE: THIS ARTICLE IS NOT TO ASSIST YOU IN RUNNING JAVA 7 UPDATE 25 AND REMOVING SECURITY PROMPTS! Yes it is technically possible using various methods but is not supported by Oracle. Pressuring vendors to support J7U45 (or the latest Java updates sooner) may be easier than applying these workarounds. In our situation we were happy to use J7U45.

Key focus areas that i see impacting administrators are:

  • JRE Expiration Date
    Expiration warning prompts that prompt to update when machine has reached it hard coded date. This means that with version 45, you will need to plan to update to the next release before 14th Feb 2014. This setting forced administrators to find workarounds for Java 7 U10-25. U40 and above provisioned the below setting:
    deployment.expiration.check.enabled=false
  • Unsigned applets
    Currently there are two workarounds with U45. One is to set your security to Medium – quite easy to do but not good security practice. The second is to create an XML whitelist that you digitally sign (using a valid 3rd party certificate) that gives permissions to run it like it was digitally signed.
    The solution is to request the developers to simply digitally sign their software so you dont have any problems.
  • Bugfix in U40 to overcome an Update Loop
    If you are not an Admin, but are prompted to upgrade Java, you may click on Update button. This causes the system to run a loop and no Java from working. Increased helpdesk calls from this problem occurred.

Conclusion

To keep up to date, and not have your users prompted with most warning (note there are some that simply cant be avoided) you can try the solution we are using.

Deployment Process for Java 7 Update 45
The solution will be in the below order. Note the items in GREEN are optional and not required.

  1. Verify that the following services are not running (if user is logged in.)
    java.exe, javaw.exe, javaws.exe, javacpl.exe, iexplore.exe, firefox.exe, chrome.exe
  2. Run cleanup task to remove previous versions of Java:
    1. Run msiexec.exe uninstaller for all previous versions
    2. Remove java directory from default locations in Program Files folder and Windows folder
    3. Clean registry settings from previous java installs
  3. Perform installation of Java installation. Note both options below work, and its based on deployment preference.
    • Option1: Install the offline EXE version with command line parameters to disable automatic updates
    • Option2: Extract MSI from the EXE. By doing this the extraction process excludes to automatic updating process automatically
  4. Deploy and overwrite system wide configuration files to the client. Note: if you are good with MSI’s you can easily create an MST file to copy the files as part of the MSI install thus a working viable solution for those deploying Java using Group Policy Software Deployment. Settings include:
    • Disable Out of date warning
    • set security level for all users
    • lock security level so users cannot change them
    • JAR file to whitelist unsigned internal web applications
  5. Run cleanup tasks

Hopefully this article has helped explain what Java has done over the last 11 months, and how you can now deploy the latest version of Java with confidence. If you enjoyed this, have a read of my next article that explains in detail how i execute the above steps in a real world scenario, including the scripts and processes that I have successfully used.

References:

Below are references that I passed along when writing this article series. To better understand this topic i suggest you start by researching the below links.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

QR Code Business Card