Tested Build : Nightly build(build 1.6.0-b99 dated 08/05/2005)
Build Location : /net/sqesvr-nfs.sfbay/global/nfs/deployment5/pit_builds
OS/Machines : kgb(solaris10), windows-64(winxp), JITENDER(winxp)

Problem description:
If user denies the expired certificate with no timestamping object, and in the same browser session user tries to load the different applet signed with same certificate but valid timestamping object, then there should be a security pop-up. But that' s not happening currently. Applet loads without any security pop-up.
 
Prerequistes -
------------------
 1) Import the Self-signed ca certificate (/net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/Justin.csr) and TSA certificate (/net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/opentsa.csr) into your Signer CA keystore at user level (using Java control panel).
  OR
simply copy the /net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/trusted.cacerts into <user_deployment_home>/security

2) Make sure the date-time for your computer is in range of 4/4/2005 to 6/3/2005

Steps to reproduce:
-----------------------
1) Load the following applet ( applet coming from jar signed with no timestamping object)
http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/timestamping/applets/TestAppletExpired.html
On the security pop-up, click on the cancel
2) In the same browser session, load the following applet (applet coming from jar signed with with same certificate as above but with valid timestamping object)
http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/timestamping/applets/TestAppletValid.html
There should be a security pop-up , if security pop-up is not there then the bug is reproduced
Dependency on the cache is ruining the validity of certificates and leds to change in security popup

 Prerequistes -
------------------
 1) Import the Self-signed ca certificate (/net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/Justin.csr) and TSA certificate (/net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/opentsa.csr) into your Signer CA keystore at user level (using Java control panel).
  OR
simply copy the /net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/trusted.cacerts into <user_deployment_home>/security

2) Make sure the datetime for your computer is in range of 4/4/2005 to 6/3/2005

Steps to reproduce:
------------------------------
- Load the following applet
  http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/timestamping/applets/TestAppletValid.html
You can notice that it is a valid certificate
(click on Run or cancel)
Close the browser

- If User click on Run :
     Expected behavior : Since it's a valid certificate , while loading the same applet again in different browser session, there should not be any pop-up as certificate is going to have an entry inside the trusted.certs store.
  Actual behavior : While loading the same applet again in different browser session, security pop-up is coming but this time it says that certificate is invalid. Close the browser and delete the cache. Now try loading the same applet again, everything works fine with no security pop-up this time since certificate is already trusted which is correct behavior.

* If User click on Cancel:
     Expected behavior : Security popup should be there while loading the applet again with information that certificate is valid and trusted
  Actual behavior : While loading the same applet again in different browser session, security pop-up is coming but this time it says that certificate is invalid.
Close the browser and delete the cache. Now try loading the same applet again, everything works fine with security pop-up showing the correct information about the validity of certificate

If you can notice the Actual behavior mentioned above, then the bug is reproduced
Tested Build : Nightly build(build 1.6.0-b99 dated 08/05/2005)
Build Location : /net/sqesvr-nfs.sfbay/global/nfs/deployment5/pit_builds
OS/Machines : kgb(solaris10), windows-64(winxp), JITENDER(winxp)

Problem description:
If user denies the expired certificate with no timestamping object, and in the same browser session user tries to load the different applet signed with same certificate but valid timestamping object, then there should be a security pop-up. But that' s not happening currently. Applet loads without any security pop-up.
 
Prerequistes -
------------------
 1) Import the Self-signed ca certificate (/net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/Justin.csr) and TSA certificate (/net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/opentsa.csr) into your Signer CA keystore at user level (using Java control panel).
  OR
simply copy the /net/sqe1/quality1/deployment2/jitu/plug-bug/timestamping/trusted.cacerts into <user_deployment_home>/security

2) Make sure the date-time for your computer is in range of 4/4/2005 to 6/3/2005

Steps to reproduce:
-----------------------
1) Load the following applet ( applet coming from jar signed with no timestamping object)
http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/timestamping/applets/TestAppletExpired.html
On the security pop-up, click on the cancel
2) In the same browser session, load the following applet (applet coming from jar signed with with same certificate as above but with valid timestamping object)
http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/timestamping/applets/TestAppletValid.html
There should be a security pop-up , if security pop-up is not there then the bug is reproduced