I'm trying to troubleshoot an issue with signed jars not working under appletviewer. My main goal is to run it outside of the browser, so I tried using appletviewer - if you have other suggestions, let me know.
Here's the context:
Java:
$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
Here's the problem:
The jar is signed:
$ jarsigner -verify -certs -verbose -keystore /etc/ssl/certs/java/cacerts myjar.jar
...
smk <file size> <file date> <file name>
X.509, CN=xxx, OU=xxx, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
X.509, CN=yyy, OU=yyy, OU=yyy, O=yyy, C=yyy
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
[KeyUsage extension does not support code signing]
X.509, OU=zzz, O=zzz, C=zzz (alias1)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
...
jar verified.
and, though the intermediate signing certificate (yyy above) is not present, the root one (zzz - or alias1) is:
$ keytool -list -v -keystore /etc/ssl/certs/java/cacerts -storepass changeit|grep alias1
alias1, Mmm d, yyyy, trustedCertEntry,
Running this:
$ appletviewer myhtml.html
gives:
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission preferences)
Question set 1:
Not being sure of above, I tried adding the certificate to another local file, called cacerts2. I can confirm that:
jarsigner output is now like this:
$ jarsigner -verify -certs -verbose -keystore cacerts2 myjar.jar
...
smk <file size> <file date> <file name>
X.509, CN=xxx, OU=xxx, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
X.509, CN=yyy, OU=yyy, OU=yyy, O=yyy, C=yyy (alias2)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
[KeyUsage extension does not support code signing]
X.509, OU=zzz, O=zzz, C=zzz (alias1)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
...
jar verified.
Note that now I have the intermediate alias (yyy - or alias2) present in the output and verified both against alias1 and alias2. Running the appletviewer like this:
$ appletviewer -J-Djavax.net.ssl.trustStore=cacerts2 -J-Djavax.net.ssl.trustStorePassword=changeit myhtml.html
still results in the same exception.
Question set 2:
The third thing I tried is making a policy file like this (this is in mypolicy.policy):
keystore "cacerts2";
// Tried with this and without the next line:
//keystorePasswordURL "cacerts.pass";
// where file cacerts.pass has only "changeit" / "changeit\n" in it (tried both)
// Tried the following three:
grant signedBy "alias1" {
//grant signedBy "alias2" {
//grant {
permission java.lang.RuntimePermission "preferences";
};
and running like this:
$ appletviewer -J-Djava.security.policy=mypolicy.policy myhtml.html
and like this:
$ appletviewer -J-Djavax.net.ssl.trustStore=cacerts2 -J-Djavax.net.ssl.trustStorePassword=changeit -J-Djava.security.policy=mypolicy.policy myhtml.html
Results:
Question set 3:
My main goal is to run it outside of the browser,..
Use Java Web Start, which could launch applets free-floating since around the 1.2 days. (Or convert the code to a frame.)
If the main point of this is testing, you might try Appleteer. AFAIR I never got around to implementing a sand-box for it (so even unsigned applet code would behave as if it were trusted).
AppletViewer used to launch applets without a security sand-box, even if they were not signed. Now it is the opposite and has a sand-box, and there is no way to get it to accept signed code as trusted!
IDEs seem to apply a policy file to the viewer, to get it to act however the user configures the IDE.