JDK-8026002 : Certificate based DRS rule does not work when main jar is in nested resource block or extension
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u40,7u45
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2013-10-07
  • Updated: 2014-08-18
  • Resolved: 2013-10-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u51 b04Fixed 8Fixed
Related Reports
Relates :  
JDK-8051890 - Java Web Start raises "Unable to create a shortcut for " dialog
Relates :  
JDK-8026015 - RFE: be able to set insecure properties in a jnlp file with a location based DRS run rule
Description
J2SE Version (please include all output from java -version flag):
   7U45 and 7U40

java version "1.7.0_40"
   Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
    HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

Does this problem occur on J2SE 6ux or 7ux?  Yes / No (pick one)
   N/A
  

Operating System Configuration Information (be specific):
   Window 7 x64

Hardware Configuration Information (be specific):
   Various


Bug Description:

Not be able to get a certificate rule to work in a DeploymentRuleSet.  Had tried many variations, and none have worked.  Was emulating the example shown here: 
    https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets 

The docs say that only SHA256 is supported now, and that the colons should be stripped.  All the examples have the hash in all upper case.

Using a location rule works fine, but not the certificate ones.  Originally tried to let the <action> be to run the application, but having it block made the testing a bit easier.

The Java security dialog only gives the hash with SHA1, needed to go to the actual jar file to get the SHA256.  The keytool command provides:

Certificate fingerprints:
         MD5:  F1:6C:A8:50:8C:1D:FA:80:0D:56:F3:12:F7:FA:CA:B6
         SHA1: D4:9D:87:31:A9:E8:5E:19:9E:B0:31:BF:A8:87:C2:9D:2E:C8:71:77
         SHA256: 4E:81:86:EF:A9:01:D0:5F:8C:9B:B5:3A:70:C4:71:F6:58:E1:2A:D7:63:3C:86:4E:E3:77:A2:88:AA:23:AC:31
         Signature algorithm name: SHA1withRSA
         Version: 3

The SHA1 hash matches the one shown in the security dialog, so it should be using the correct value.

Steps to Reproduce (be specific):

Use the DeploymentRuleSet on https://www.ocie.net/OcieDemo/JViewer/webstart.html and watch it not block the application
Comments
Closed due have no enough time to verify old bugs.
07-03-2014
regression_test_src: http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/8/deployment2/diff/5263a9fcc2c1/new_framework/tests/plugin/LSPJPI/src/LSPActionRunTest.java
06-11-2013
SQE is OK to fix that in 7u51 assuming the fix comes before RDP2
16-10-2013
request to include in 7u51, see Andy's comments
14-10-2013
Crucible review: https://sthinfra10.se.oracle.com/cru/CR-JDK7UCPU-119
10-10-2013
manual test cases at: http://oklahoma.us.oracle.com/www/tests/1.7.0_51/8026002/bug.html webrev of fix: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.7.0_51/8026002/deploy/ fix is basically to fix getMainJar to consider nested resources and extensions
10-10-2013
This has been added as a known issue for 7u45 and 7u40.
10-10-2013
Main problem here is that ResourcesDesc.getMainJar, does not search either nested resource blocks or component extensions for a main jar, and will return null if there is no jars in the top level of the main jnlp file. Result is that when Certificate based run rule should be in effect, it is not in effect for the initial verification of the main jar and the requested jre, and so you can see some dialogs, then as each jar is loaded, rule will be in effect. The same applies when such an application has a certificate based block rule. It may start to run and show dialogs (because rule is not in effect) then when any jars are loaded it will block. The fix is fairly strait-forward, and should be included in 7u51: 7u45-release-note proposed text: Known problem: Certificate based Deployment Rule Set rule does not work properly for jnlp applications when the main jnlp file has no jar files, or all jar files are in nested resource blocks nested in <java> or <j2se> elements.
09-10-2013
For the first problem, according to the submitter - > It actually seems to accept both. The rule blocked for me with both syntax. However, ���SHA256��� (without the minus sign) does not seem to be accepted. > The certificate prompt still comes up both when ���block���ing and ���run���ning with either algorithm.
08-10-2013
RFE 8026015 - be able to set insecure properties in a jnlp file with a location based DRS run rule has been filed.
07-10-2013
There are several problems here, along with possibly some miss-understandings. The first simple problem is that the attempt to use SHA1 in the certificate rule is failing due to need to match with SHA-1. changing ruleset.xml to certificate algorithm="SHA-1" has=... fixes this problem. a possible missunderstanding is the use of DRS to circumvent the new requirement that all properties listed in a jnlp file shall only be honored if they are secure properties, or the jnlp file is signed. The app uses several insecure properties in the jnlp file starting with "dsi.", and the security fix in 7u45 is blocking them from being set. As aside, we might consider enhancement to set insecure properties that come from a jnlp file for which there is a location based DRS run rule, however the certificate of the signed jars cannot help this if the jnlp file itself is unsigned. The real problem here is that the innitail calls to LaunchDesc.getMainDeploymentRuleSet(), all cause an NPE in ruleset parsing, because the main jar is null. This is caused by all jars being in resource blocks that are nested in j2se elements. There is no main jar (or any jars) in top level of resources element: <resources> <j2se version="1.6+" min-heap-size="10M" max-heap-size="128M" > <resources> <jar href="https://www.ocie.net/OcieDemo/JViewer/lib/dsi/clientC.jar" main="true" download = "eager"/> ... This is a known problem - and is severely effecting this app.
07-10-2013
Looks like "secure" system properties are still being stripped from the JNLP file. There are several that start with the prefix "dsi." that are being stripped from the JNLP file. Hoping to use the DeploymentRuleSet on machines here to connect to older clients that had not yet upgraded. If it continues to strip these properties this setting is pretty much useless. With the deployment rule set to block, did get the security dialog ���Do you want to run the application?��� then select ���Run���. Then, apparently, the rule set runs and get the dialog that the application is blocked by rule ���Certificate 1��� Seems like if the application is going to be blocked, it wouldn���t need to ask first if want to run it?? If the rule action is to run, it works���but still need to accept the certificate. It will not accept it without user interaction. (Perhaps if checked the never show this to me again box, it would. However, thought this would be unnecessary.) https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets but the gist is to specify the default action of which should run (with no interaction from the user) More disturbingly, thought it would run without the new security settings, but apparently, the ���secure��� system properties are makes the feature useless. Hope to use this on machines in the office to connect to customers that had not yet upgraded to a 7U45 compliant version.
07-10-2013