"Allow access to the following application from this website" Prompt - Java

Question

I am running Java 1.7.0_67-b01. We have an applet which downloads into the browser. Normally the user receives two prompts the first time the user employs the applet. The first one reads "Do you want to run this application" It then give the name of the application, the publisher, and the location and then states "This application will run with unrestricted access..." At the end of the prompt, the user has the option of checking a box to "Do not show this again for apps from the publisher and location above.". Clicking on the checkbox and then clicking the RUN button will result in the certificate of the applet being installed in an area accessible from the Java control panel.

Then the user receives a second prompt: "Allow access to the following application from this web site?" Again the Application and the Publisher are identified. And the following statement appears: "This web site is requesting access and control of the java application shown above. Allow access only if you trust the web site and know the application is intended to run on this site." Again there is a check box: "Do not show this again for this app and web site."

Oracle calls the act of clicking the check box and pressing the "Allow button" or "Run" button depending on the prompt, a "trust decision". If you choose to trust an application running from a particular web site, you can undo your decision by going to the Java Control Panel and clicking on the "Restore Security Prompts" button.

A permanent change occurs in the environment but I don't understand where the change is made. It is obvious that some information related to the website identified in the prompt is stored because making a trust decision, causes the prompt to disappear. But where is it stored? I've looked within the browser (I'm using IE9) and the control panel for java. I did discover that the certificates themselves are stored in a file called trusted.certs. This is located on my Windows 7 machine under Users\\AppData\LocalLow\Sun\Java\Deployment\security. When I click on the Restore Security Prompts button, the file changes. And it also updates when I make a trusted decision in response to the first prompt. But, not so the latter. Interestingly, if I copy the trusted.certs file to a different machine whatever decisions I made to the first prompt carry to the second machine. This suggests that by deploying the trusted.certs file to my user population, I can spare them the problem of having to be confronted with the first security prompt.

However, where data is stored related to the second prompt remains a mystery to me at this time. If anyone knows something about this prompt and where the data related to the trusted decision associated with this prompt is kept, I would appreciate it.

Is there also a way to avoid having the user having to make trust decisions? If this is a protected intranet environment, there should be a way to bypass this cumbersome security provision in the JRE.

Solution 1

I never did find out where the JRE stores data related to the second prompt. But this is much less important than figuring out how to control prompting in situations where it is inconvenient for users to make trust decisions or just not possible. Oracle has a way around this in its most recent releases of the JRE through the use of something called a rule set. I enclose the links that describe these below:

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html

http://www.java.com/en/download/faq/release_changes.xml

Below is a sample ruleset that worked with our application:

<ruleset version="1.0+">
  <rule> <!-- allow anything signed with company's public cert --> 
    <id location="http://10.190.65.254/myapp">
    </id>
    <action permission="run"/>
  </rule>

 <rule>
   <id />
    <action permission="default"/>
  </rule>
</ruleset> 

We packaged the rule set in a signed jar and deposited it in a directory:

C:\Windows\Sun\Java\Deployment

After that, no more prompting.

Solution 2

Like the answer has indicated, to get rid of the first security prompt which says "Do you want to run this application" do the following.

I don't know how to get rid of the second prompt though which says "Allow access to the following application from this web site?" Does anyone know how to get rid of this one?

Anyway, for prompt 1 "Do you want to run this application": Create a DeploymentRuleSet.jar file (which needs to reside in C:\Windows\Sun\Java\Deployment) as below.

Create a file called ruleset.xml and have it contain the rules. An example file might be:

<ruleset version="1.0+">
  <rule>
    <id>
      <certificate algorithm="SHA-256" hash="A494E23EF3EF549DF2F5597AE8F9C1A329DE4E055A58B23DFAED4DDBF1ECA865" />
    </id>
    <action permission="run" />
  </rule>
</ruleset>

(this file matches the SHA256 of the cert so that anything signed with that cert will match the rule, but you can also use URL's or applet names or whatnot)

Now Download a copy of the CA code signing certificate you have used to sign your JAR files.

If you want to know what the certificate hash is so you know what to put into the ruleset.xml file, you can use this command to show it, you just have to remove the ":" marks from the output of the SHA256 Certificate fingerprint. Also we need to take note of the key alias (EG le-codesigningv3-9f7e8e35-747f-41b3-a53f-542d8ee447e0):

keytool -list -v -keystore codeSigning.pfx -storetype PKCS12

So enter the resulting hash into the ruleset.xml file. Keep note of the Alias name.

Create the jar file with the ruleset.xml file in it:

jar -cvf DeploymentRuleSet.jar ruleset.xml

Sign this jar file with the certificate - you need to know the keystore password. Change the alias (the last argument in the command) to whatever the alias is in the certificate, EG:

jarsigner -verbose -keystore codeSigning.pfx -storetype PKCS12 -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar le-codesigningv3-9f7e8e35-747f-41b3-a53f-542d8ee447e0

And that gives you the file you need.

Solution 3

So possibly an easier solution. I kept hitting roadblocks trying to get jars signed and following directions that left out crucial steps etc. I ended up Copying the folder

%userprofile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0

and the file

%userprofile%\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs

from a machine that has already accepted the prompts and wrote a simple script to robocopy these on login.

Also added something to disable the update java prompt. Here is the script if anyone would like. Also please copy the folders so the structure looks like this: Directory Tree

LogonScript

::Paste this into a batch file and set it as logon script for AD account in profile, or put it in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
::This was tested and works in Win7/Win10 with Java 8u201

mkdir "%userprofile%\appdata\LocalLow\Sun\Java\Deployment\cache\6.0"
mkdir "%userprofile%\appdata\LocalLow\Sun\Java\Deployment\security"
robocopy "\\%USERDNSDOMAIN%\NETLOGON\Software\Java Prompts\6.0" "%userprofile%\appdata\LocalLow\Sun\Java\Deployment\cache\6.0" /E
robocopy "\\%USERDNSDOMAIN%\NETLOGON\Software\Java Prompts\security" "%userprofile%\appdata\LocalLow\Sun\Java\Deployment\security" /E

::WIN 10 64 bit
reg add "HKLM\SOFTWARE\WOW6432Node\JavaSoft\Java Update\Policy\jucheck" /v NotifyInstall /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\WOW6432Node\JavaSoft\Java Update\Policy\jucheck" /v NotifyDownload /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\WOW6432Node\JavaSoft\Java Update\Policy\jucheck" /v EnableAutoUpdateCheck /t REG_DWORD /d 0 /f

::WIN 7 64 Bit
::reg add "HKLM\SOFTWARE\WOW6432Node\JavaSoft\Java Update\Policy" /v EnableJavaUpdate /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\WOW6432Node\JavaSoft\Java Update\Policy" /v NotifyDownload /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\WOW6432Node\JavaSoft\Java Update\Policy" /v EnableAutoUpdateCheck /t REG_DWORD /d 0 /f

::WIN 7 32 Bit
reg add "HKLM\SOFTWARE\JavaSoft\Java Update\Policy" /v EnableAutoUpdateCheck /t REG_DWORD /d 0 /f
::reg add "HKLM\SOFTWARE\JavaSoft\Java Update\Policy" /v EnableJavaUpdate /t REG_DWORD /d 0 /f