asked on

Java Applet Security Issues

Starting with Java SE 7 Update 21 in April 2013 all Java Applets and Web Start Applications are encouraged to be signed with a trusted certificate. And starting with 7u25, all files must be added to JARs prior to signing. - Link

With that being said, it has seriously hindered our java applet being used to print labels to zebra printers. First there was the issues with so many security warning pop-ups with each label being printed. I think there were 3 warnings to print each label.

Now with a signed JAR file, we still get the security warning and it says the the publisher is unknown. JAR FILE LINK . This file was signed by theJZebra Dev Team as an update to fix the JavaSE7 update. We also tried signing the file with our own certificate but get the same results.

When the file is located on our server we get the 'Show/Hide Options' down at the bottom which will allow us to check 'Do not show this again for apps from the publisher and location above'. However, when this same JAR is being accessed from the customers server they do not see this. Is this due to some user access rights on their server?

Any help would be much appreciated.

CEHJ

Now with a signed JAR file, we still get the security warning and it says the the publisher is unknown.

That will be the case if the cert is self-signed. In order to prevent that effect JZebra would have to have their cert signed by a CA such as Verisign, Thawte etc. or more precisely, a CA whose cert is stored in the runtime

EazyWorks

ASKER

CEHJ, thanks for the response. Although we used Comodo to purchase our code signing cert. This should do the trick but it has the same results.

Can I be walked through on how to extract the JAR Contents and reassemble the JAR, then sign only with our Cert?

Thanks.

CEHJ

This should do the trick but it has the same results.

That jar has two jar dependencies. Did you sign both of those as well?

EazyWorks

ASKER

Im sorry... I do not know what you mean by the JAR has two JAR Dependencies.

what I want to do is remove any code signing previously done to the JAR and add our own, incase they used self cert as indicated earlier.

CEHJ

Class-Path: lib/plugin.jar lib/PDFRenderer-0.9.1.jar
Open in new window

Those are the dependencies. They will need signing as well

EazyWorks

ASKER

How did you get that CEHJ? If I use Jaranalyzer on it I get the following. Sorry, Im not too familiar with working with JAR files.

<?xml version="1.0"?>
<JarAnalyzer>-<Jars>-<Jar name="jzebra.jar">-<Summary>-<Statistics>
					<ClassCount>35</ClassCount>
					<AbstractClassCount>1</AbstractClassCount>
					<PackageCount>3</PackageCount>
				</Statistics>-<Metrics>
					<Abstractness>0.03</Abstractness>
					<Efferent>0</Efferent>
					<Afferent>0</Afferent>
					<Instability>-1.0</Instability>
					<Distance>-1.0</Distance>
				</Metrics>-<Packages>
					<Package>jzebra</Package>
					<Package>jzebra.exception</Package>
					<Package>jzebra.json</Package>
				</Packages>
				<OutgoingDependencies/>
				<IncomingDependencies/>
				<Cycles/>-<UnresolvedDependencies>
					<Package>netscape.javascript</Package>
				</UnresolvedDependencies>
			</Summary>
		</Jar>
	</Jars>
</JarAnalyzer>

Open in new window

CEHJ

How did you get that CEHJ?

Just by unpacking the jar and looking at the manifest

EazyWorks

ASKER

So could that be the issue? I see that line in the manifest, yet it does not actually exist in the JAR file.

CEHJ

yet it does not actually exist in the JAR file.

I don't know what you mean by that? What do you mean by 'in'? If you're referring to 'inner' jar files - forget that. That would only be a consideration with special 'fat jars', requiring special classloaders. They will not be a consideration here

CEHJ

It would actually be better at this stage to point me to the url of the applet in question so i can see what the real deployment amounts to

EazyWorks

ASKER

its in the OP

EazyWorks

ASKER

JAR FILE LINK

CEHJ

No - that's not the url of an applet. It's a link to a jar file

EazyWorks

ASKER

I think I know the problem regarding the dependencies. I will sign the other file to see if that is it. I will let you know tomorrow. Thanks f

CEHJ

Actually the dependencies thing could be a red herring. The jar in question has those but the applet itself doesn't for some reason, unless the applet jar is a fat jar with the pdf renderer classes in it (i'm guessing not)

EazyWorks

ASKER

@CEHJ as you discovered as well, the other JAR is not in the main file. A colleague of mine discovered the PDFRenderer is actually in another folder in our project. I still have not had a chance to try signing it as I was in a conference all day.

But I have a good feeling its this one PDFRenderer JAR that is being displayed as from an unknown publisher. I will keep you posted.

EazyWorks

ASKER

Man... after signing both files, i still get the security warning message box.

CEHJ

In what way? Are you expecting never to see that box again after first run? I'm not sure that's possible, even with a proper cert

EazyWorks

ASKER

CEHJ.

My security warning dialog box is different than my customers. And yes, I expect to accept the security warning once and then not have the users have to worry about it again.

also, the publisher still says unknown.

Mine has the 'hide options':

Customer dialog does not display the 'hide options'

ASKER CERTIFIED SOLUTION

CEHJ

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

EazyWorks

ASKER

The issue was that the CA Cert was not properly inserted into the keystore. So when I was signing the JAR Files there was still no CA Cert.

Thanks for your help CEHJ!

EazyWorks

ASKER

I had the CA Cert, it just wasnt properly used when creating the Keystore. Thanks!

CEHJ

OK :)