2

I'm getting the dreaded LiveConnect warnings on an in-house self-signed applet. I'm using Java 1.7.0_45. According to what I've read, I should be able to get rid of these by adding Caller-Allowable-Codebase * to my manifest, and removing the Trusted-Library attribute. My ant target for building the applet looks like this:

<jar destfile="MyApplet.jar">
  <manifest>
    <attribute name="Main-Class" value="com.mycompany.MyApplet"/>
    <attribute name="Permissions" value="all-permissions"/>
    <attribute name="Codebase" value="*"/>
    <attribute name="Caller-Allowable-Codebase" value="*"/>
  </manifest>
  [...]
</jar>
<signjar jar="MyApplet.jar" [...] />

Unfortunately, this has no effect; I still get the warning. I have verified that I am running 1.7.0_45, and that the browser isn't using an old cached copy of the applet. The client is Firefox 25.0 running on OS X 10.7.5, for what it's worth... Any ideas would be greatly appreciated!

Thomas Okken
  • 163
  • 10

3 Answers3

2

I have observed the same behaviour. My tests indicate that the Caller-Allowable-Codebase manifest attribute only takes effect if the JAR is signed by a trusted certificate. (I signed a JAR with an untrusted cert, and the warning appeared. I signed the same JAR with a trusted cert, and the warning didn't appear).

If you can't use a certificate from an already trusted CA, you might try to configure the local Java installations to trust your certificate, or use deployment rulesets to suppress the warning.

meriton
  • 68,356
  • 14
  • 108
  • 175
2

Found it -- the trick is to import the certificate into the right keystore. I exported the certificate from the keychain I use to build the applet:

keytool -exportcert -file appletkey.cer -alias appletkey -keystore mykeystore

...and then import it into the global cacerts keystore:

keytool -importcert -file appletkey.cer -alias appletkey -keystore $JRE_HOME/lib/security/cacerts -storepass changeit

The tricky part is to figure out which instance of cacerts to import it to; depending on configuration, you may have a whole bunch of JVMs installed, and each one has their own cacerts. On the Mac, the right one turned out to be

/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts

and in Windows it is

C:\Program Files (x86)\Java\jre7\lib\security\cacerts

(substiture "Program Files" for "Program Files (x86)" in case you're using a 64-bit JVM.)

I'm assuming in Linux it's $JRE_HOME/lib/security/cacerts as well, where your value of $JRE_HOME will depend on how you installed it.

N.B. I did try importing the cert into a user-specific keystore as well, but I couldn't get that to work. Importing it into the global keystore is a bit brute force but for my use case it is good enough. The initial Java applet warning and the LiveConnect warning are both gone. Also note that this is using the applet manifest exactly as shown above; as other respondents suggested, there was nothing wrong with the manifest, I just had to get the JVM to trust the certificate.

Thomas Okken
  • 163
  • 10
0

Update: Applet is officially signed by browser trusted CA, not self signed, that was a mistake of me, sorry. Original answer:

I use these attributes in my self signed applet and have only the basic click to run question, that can be marked "don't ask again":

click to run warning

I don't get the live connect warning that shows every time:

live connect warning

The first one is obligatory. Which security warning exactly do you mean?

*Images are reused of other questions and not related to me...

jan
  • 2,741
  • 4
  • 35
  • 56
  • As your post asks for clarification of the question, it should be a "comment" rather than an "answer". Also, OP talks about "LiveConnect warnings", and only the second warning you show is specific to LiveConnect. – meriton Nov 13 '13 at 15:41
  • @meriton: No it was the 'wrong' answer "works for me", but I now realized that this is really a trusted CA signed applet, not self signed. – jan Nov 20 '13 at 13:49
  • I tried exporting the key used to sign the applet (keytool -keystore mykeystore -exportcert -file my.cer -alias myalias) and then importing it into the user's trusted keystore (keytool -keystore trusted.certs -storepass '' -importcert my.cer). I did this for C:\Users\tokken\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs under Windows 7 and /Users/tokken/Library/Application Support/Oracle/Java/Deployment/security/trusted.certs under OS X 10.7. I still get the warnings, perhaps not surprising because it turns out that the certs were already there! – Thomas Okken Nov 25 '13 at 21:12
  • I think the certs were already in trusted.certs because that's what used to happen when you were still able to say "trust this applet from now on" -- it would import the cert. So now it not only doesn't offer to import the cert anymore, but even if you force it, it gets ignored. – Thomas Okken Nov 25 '13 at 21:14