-
Bug
-
Resolution: Fixed
-
P2
-
6
-
b56
-
generic
-
generic
-
Verified
Dependency on the cache is ruining the validity of certificates and leads to change in security popup behavior
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)
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)
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