JRE 1.4.x Plugin - Signed Applets and Weird Behaviour (Policy)

Question

Hello.
I have recently experienced some strange behaviour related to signed applets and policy files in JRE 1.4.2-b28 ( a friend got the same behaviour in a flavour of 1.4.1-xx as well ). Both tests were on Windows 2000 Professional platforms.
Initially my unsigned applet, which attempts socket connections to a server different from the download location, fails with security exceptions ( as expected ). Then I did the following to sign the applet jar and configure my environment
Steps: 1) Import "trusted CA" certificate into ${java.home}/lib/security/cacerts. (JRE home outside the JDK)
2) Signed the jar using jarsigner and a certificate generated from the "trusted CA" (Entrust CA and certificate).
3) Imported the signing certificate into the Java plugin using import in the plugin control panel.
4) Created a new keystore (keytool,jks) and imported the signing certificate into the keystore with alias "developer". The keystore is stored in the user home as .keystore.
5) Created a .java.policy for the user and attaching the keystore in 4) to it. ( also stored in user home ).
6) Used the policy tool to grant socketpermissions to the specific codebase ( testing with file:/C:/test/* initially ) signed by "developer"
After this, when I ran the test page under IE 5.5SP2 and Netscape 7.1 it worked without any security exception. Ditto for using the appletviewer and the policy file I created for the user.
The weird part occurred when I removed the policy entry from the user policy file. After doing this, Netscape and IE still allow the applet to execute - somehow remembering that it was granted permissions at some point. The appletviewer does not allow it to execute, generating security exceptions.
It appears the old policy is being cached somewhere, but I cannot find where. If I replace the applet jar with an unsigned version it does fail in IE and Netscape. I tried cleaning the plugin cache and removing the "deployment.certs" files related to the users but still get the same behaviour.
Does anyone know where the old policy information is being stored ? Does anyone know how to revoke the permissions so that I am restored to my original base environment ( no permissions for "designer" signed applets ) ? Would attempting to utilize the AccessController.doPriveleged( xxxx ) operations in JDK 1.4 avoid all of this confusion with policy files, keystores and certificate storage ? After all the messing about I would like a zero-footprint alternative ( or minimzed footprint anyway ).
Any ideas would be most welcome.
Regards,
James.

Answer 1

Hello Again.
I am either enlightened or confused at this point. I found that as long as all of my related Jars are signed ( even by self-signed certificates ) I am granted SocketPermissions for calls outside of the originating server. Unsigned code is refused, but even when the Jars were signed using a self-signed certificate the Socket calls were allowed.
Am I experiencing the appropriate behaviour in this case ( which would mean not having to utilize policy files to distribute an applet that uses calls to arbitrary servers - e.g. JavaMail ) or am I suffering from something damaged in my environment ?
It has been a long time since I played with signed applets and I am having difficulty determining what operations require policy file entries/AccessController.doPrivileged() calls and which are granted when a user elects to trust a signed applet without policy.
Any assistance in clearing up my confusion would be appreciated.
Regards,
James.