This content has been marked as final. Show 2 replies
I believe the thinking here is that the cetificate was valid when the JAR was signed so it is an accurate indication of who signed it at that time, and provably so via the digital signatures. It's not clear exactly why the check should fail as you are expecting.1 person found this helpful
Thanks for replying.
Yes the certificate was valid when the jar was signed. Please note that, there was no timestamp put in the signature.
So now after the certificate has been revoked, if Java runtime tries to load that jar, isn't it the responsibility of Java runtime to make use of the CRL/OCSP information
of the public key certificate (present in the jar put by the jarsigner when signing) and validate it for revocation ? (Also, in this scenario, what happens if OCSP is enabled in java.security ?) -OR--- Is it the responsibility of the code that makes use of the jar, to verify whether the certificate used for jar signing has been revoked or not ?
PS:- I have enabled the security settings in java control panel for certificate revocation checking.
Please let me know if I am wrong or if I am missing something.
Also i noticed something with jarsigner. In a signed jar, If i delete a few files and then verify its signature using jarsigner, "jar verified" is returned as result. Isn't the jar tampered when I delete a few files from it ? and hence the Hash of its data changes ? and hence verification should fail ?
One more question, in case of signed applets, if the certificate is revoked, as soon as the browser tries loading the applet, it throws an error saying certificate that was used for signing has been revoked. (provided browser settings and java control panel settings are all properly set). Is this check initiated by the browser OR Java runtime ?
Thanks a lot