/build/static/layout/Breadcrumb_cap_w.png

Exporting/Importing Java Trusted Certificates / Suppressing Java prompt issue

I'm encountering an issue with Trusted Certificates for Java. Now, I haven't messed around with this too much in the past so I may be missing something easy. Here is the issue:

There is a site we are wanting our users to start using (unfortunately I can't link because it's on our intranet) and one of the pages uses a java applet to play/record audio. So when a user goes here for the first time they get a prompt that says: 

Do you want to run this application? 
name: mmAPPLET
Publisher: Cisco Systems
Location: (*website url*)
(checkbox) Do Not show this again for apps from the publisher and location above
Run / Cancel

and then if they check the "do not show again" radio button than it doesn't show this message again. So basically I'm trying to figure out how to push out a solution to all our machines so this prompt won't show up. It seems that once that "do not show" is checked, it puts a Cisco Systems Trusted Certificate in the Certificate section of the Java Control Panel. Now, in theory I should be able to export this, import it onto another computer (or the same computer if I were to delete it first) and it should prevent the java applet pop up, right?

Firstly, when I click on Export it doesn't provide a filetype. After some reading it seems like I should use .p12, so I've been giving that extension to the exported certificates (although I also tried .csr with the same results). That seems to work, and when I Import it back in using the Import button the certificate shows up in the Trusted Certificate list. However, if that computer goes to the aforementioned site it still gets the java pop up. I've also tried importing the certificate using cmd prompt and the keytool.exe. Again, it appears to import the certificate correctly, yet the pop up still shows on the site. Is there some other place you need to make a change to to suppress that pop up? Am I going about this the wrong way? We are using Java 8u91 (machines have both the x64 and x86 vers) Thanks.

0 Comments   [ + ] Show comments

Answers (4)

Posted by: anonymous_9363 7 years ago
Red Belt
1

If you're using 'deployment.properties' - and why wouldn't you be, unless you enjoy constantly reacting to Helpdesk calls about "out-of-date" JREs? - you can add this line to it:

deployment.system.security.trusted.certs=C\:\\Windows\\Sun\\Java\\Deployment\\trusted.certs

and then put your 'trusted.certs' file - which you can create on your own machine - in the location specified. No more faffing about with disseminating this junk to individual user's profiles!

The 'deployment.properties' file is documented here.

Lastly, please remove your duplicate posts. Thanks!


Comments:
  • Cool, thanks!. Sorry about the dups...not sure how that happened - winterelegy 7 years ago
  • We aren't using the deployment.config / deployment.properties so thanks for bringing that to my attention! I've been messing around working on setting those up for the last couple hours since that would be useful to have. However, ultimately that doesn't solve this problem though. The issue is that this particular certificate (maybe it goes beyond this to all certificates, I'm not sure - I don't have another to test with right now) , when re-imported through whatever means to whatever keystore is NOT getting rid of "do you want to run this applet" pop-up. Is there something that needs to be done in addition to importing the trusted certificate?? - winterelegy 7 years ago
Posted by: sparky86 7 years ago
Fourth Degree Brown Belt
0
java stores its certs in a file called trusted.certs under the users appdata folder under security, when we deliver java app's via app-v we include this to ensure the cert is in the java pacakge, other options include active setup published shortcuts or GPP or a 3rd party option such as appsense EM to drop the file in.

Comments:
  • Right, when you use keytool.exe the command is:

    keytool.exe -importcert -file "Certificate Location" -keystore "%userprofile%\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs" -storepass "" –noprompt

    so it should be adding it to trusted.certs. Even when this is done, and you go to that website the "do you want to run this" pop up still happens - winterelegy 7 years ago
Posted by: anonymous_9363 7 years ago
Red Belt
0

That almost certainly means that JRE hasn't read the config file. Double-check its content and location.

I just read another article that suggests that it can be placed in '[JRE root folder]\lib\security' but, wherever it is, you can save time by using the Java Control Panel applet to check the JRE configuration.

Posted by: anonymous_9363 7 years ago
Red Belt
0

Uh oh...I just spotted the 'Java 8' tag in your post and then remembered this https://www.java.com/en/download/help/jcp_security.xml 
http://www.itninja.com/question/need-to-suppress-do-you-want-to-run-this-application-security-warning-java-7u51 (which still applies to 8)

EDIT:
The exception sites list is documented here. As you'll see, its location is also configured in 'deployment.properties'.


Comments:
  • Thanks again! So far it looks like I've got it working. I had to set up the deployment.config and deployment.properties as you suggested, and I used a command with keytool.exe to import the certificate into the trusted.certs file which is referenced in the deployment.properties file. This puts the certificate in question in "System" certificates. Currently I have the website in the exception list as well, although I haven't done enough testing to say if that is actually necessary or not. - winterelegy 7 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

View more:

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ