Certificate inquiry for changes in applet jar

Hi everybody,
I have an applet that uses a certificate to allow saving of file to local disk. I downloaded the certificate and imported in the keystore and cacerts using keytool.
However, there are cases we need to change the applet. I updated the jar file with the revised version of applet.
My question is: Do I need to change the certificate and perform again the importing to keystore and cacerts to point the the revised applet so that I could save a file to local disk?
My concern is that what if many users have already performed the certificate importing, do they need to do again the procedure of importing certificate.
Your comments are very appreciated.
Thanks!
vamendoza

You should only need to re-sign the applet jar with the same certificate.

Similar Messages

BigIP F5 : changing IP leads to cache invalidated and redownload of applet jars

Hello all,
In short, I'm trying to figure out how to have the java 7 plugin not considering the server IP to decide whether to use cached version of our applet's signed jars.
As suggested in the title, we use BigIP's F5 boxes to dispatch requests among actual servers, which are located in 2 different sites (disaster recovery purposes).
Each site has an F5 box ; and our DNS resolve the application's host name by alternating between 2 different IPs : one for site 1, the other for site 2.
Each time a user visits http://theapp.mycompany.com, the host is resolved as 9.9.9.1 or 9.9.9.2, more or less randomly.
This works very nicely as long as the applet is not concerned, or bandwith and latency is good enough to absorb 1.5Mb in a snap.
For remote subsidiaries (10.000km away from servers), downloading 1.5Mb takes 35s -- too much for the normal user to wait.
And the problem is : the plugin insists on looking up the server IP each time it starts up, and ignores cache entries that have been downloaded from a different IP.
Here is the use case :
- user connects to http://theapp.mycompany.com ; the browser get an IP, doesn't matter which ; user logs on, navigates in the app's html pages -- no problem
- user gets to the applet :
- the html page says
<applet id="myApplet">
    <param name="archive" value="a.jar,b.jar,c.jar,d.jar,e.jar"/>
    <param name="codebase_lookup" value="false"/>
    <param name="archive_1" value="a.jar, preload, version=7.5.7" />
    <param name="archive_2" value="b.jar, preload, version=7.5.7" />
    <param name="archive_3" value="c.jar, preload, version=7.5.7" />
    <param name="archive_4" value="d.jar, preload, version=7.5.7" />
    <param name="archive_5" value="e.jar, preload, version=7.5.7" />
    <param name="baseUrl" value="/"/>
    <param name="code" value="a/package/for/Applet.class"/>
    <param name="mayscript" value="mayscript"/>
    <param name="codebase" value="/applet/"/>
    <param name="name" value="MyApplet" />"
    <param name="locale" value="fr"/>
</applet>
     The archive_n parameters are here in an attempt to tell the plugin to not even ask for jars if its cache contains entries with same host/same name/same version.
     The version is assigned at build time at an application level ; it has nothing to do with the Implementation-Version attribute found in MANIFEST.MF files.
- Java and the plugin sarts up : let's assume this is the first time : cache is empty : all jars are downloaded ; as they are signed and the CA certificate chain was set in the browser config, and the java.policy is also configured to allow smooth exec, the applet runs smoothly -- after a long startup delay
- user leaves the applet, do some stuff in other applet-less pages for some minutes (the java/plugin processes are shut down after a minute or so)
- user reenters the page that contains the applet
- Java and the plugin start up again :
     - the cache has entries for each jar : host, name, version are all ok.
     - But : the jars are not seen as "prevalidated" ; heres' the applet log ( in French, translation provided after "//") :
network: Vérification de version pour a.jar. La version spécifiée est 7.5.7     //Checking version for a.jar. Specified version is 7.5.7
security: La vérification de révocation de la liste noire est activée     // Check of blacklist revocation is activated
security: blacklist: created: NEED_LOAD, lastModified: 1378474147992
security: blacklist: hasBeenModifiedSince 1380806409906 (we have 1378474147992)
security: La vérification de liste de bibliothèques sécurisées est activée     // Check of trusted libraries is activated
..... same for the other jars ....
network: Created version ID: 7.5.7
network: Created version ID: 7.5.7
network: Entrée de cache trouvée [URL : http://theapp.mycompany.com/applet/a.jar, version : 7.5.7] prevalidated=false/0 //Cache entry found
cache: Adding MemoryCache entry: http://sandbox-mosaic.jcdecaux.com/applet/plannerApplet_7.5.7.jar
network: Created version ID: 7.5.7
     - The plugin then tries to lookup the host IP to check whether it matches that seen when creating the entry
     - 2 possibilities here :
               - the IP returned is the same : the plugin is happy, uses the cached jar, no question/download to/from the server, and the applet starts up quick and runs ok
               - the IP returned is not the same ; the plugin says :
network: Vérification de version pour a.jar. La version spécifiée est 7.5.7     //Checking version for a.jar. Specified version is 7.5.
security: blacklist: created: NEED_LOAD, lastModified: 1378474147992
security: blacklist: hasBeenModifiedSince 1380806409906 (we have 1378474147992)
security: La vérification de liste de bibliothèques sécurisées est activée     // Check of trusted libraries is activated
cache: CacheEntry IP mismatch: 9.9.9.1 != 9.9.9.2
          and then it downloads again the jar.
          Of course, all the jars are treated the same way.
          Note that the applet eventually runs normally ; the only problem is that the cache essentially doesn't work, causing terribly annoying 35s delays at applet startup.
Interestingly enough, examining the jdk 6 code shows that the "prevalidated=false" fragment (in bold/pink above) means that the method CacheEntry.isKnownToBeSigned() returns false.
I tried with a self-signed certificate which I added first in IE as "Trusted publisher" ; I also tried with a certificate signed by a CA that is known by IE -- no help.
So I really wonder : what does it take to have the plugin consider that each jar "isKnownToBeSigned" ?
Any thoughts ?
Note : we of course are considering packing jars, cleaning dead code, etc. to decrease applet size. But it doesn't help with the fact that the plugin considers the IP, which it shouldn't do in our case. And even with pack200 we're left with +350Kb of unnecessary downloads, not counting with future code to be developped ...
Thanks for any feedback
David
Browser is IE7.
Complete dump of system properties :
__applet_launched = 280874909499
__jvm_launched = 280874910680
acl.read = +
acl.read.default =
acl.write = +
acl.write.default =
awt.toolkit = sun.awt.windows.WToolkit
browser = sun.plugin
browser.vendor = Oracle
browser.version = 1.1
file.encoding = Cp1252
file.encoding.pkg = sun.io
file.separator = \
file.separator.applet = true
http.agent = Mozilla/4.0 (Windows Vista 6.0)
http.auth.serializeRequests = true
https.protocols = TLSv1,SSLv3
java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
java.awt.printerjob = sun.awt.windows.WPrinterJob
java.class.path = C:\tools\Java\jre7\classes
java.class.version = 51.0
java.class.version.applet = true
java.endorsed.dirs = C:\tools\Java\jre7\lib\endorsed
java.ext.dirs = C:\tools\Java\jre7\lib\ext;C:\Windows\Sun\Java\lib\ext
java.home = C:\tools\Java\jre7
java.io.tmpdir = C:\Users\taille\AppData\Local\Temp\
java.library.path = C:\tools\Java\jre7\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Program Files\Internet Explorer;;C:\oracle\ORA102\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\JavaSoft\JRE\1.3.1_06\bin;C:\ORACLE\Ora92\jre\1.3.1\bin;C:\ORACLE\Ora92\jre\1.1.8\bin;C:\tools\Groovy-1.7.5\bin;C:\tools\Graphviz2.28\bin;C:\tools\Git\cmd;C:\tools\tortoiseSVN\bin;C:\Program Files\Windows Imaging\;C:\oracle\ORA102\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\JavaSoft\JRE\1.3.1_06\bin;C:\ORACLE\Ora92\jre\1.3.1\bin;C:\ORACLE\Ora92\jre\1.1.8\bin;C:\tools\Groovy-1.7.5\bin;C:\tools\Graphviz2.28\bin;C:\tools\Git\cmd;C:\tools\tortoiseSVN\bin;C:\Program Files\Windows Imaging\;.
java.protocol.handler.pkgs = sun.plugin.net.protocol|com.sun.deploy.net.protocol
java.rmi.server.RMIClassLoaderSpi = sun.plugin2.applet.JNLP2RMIClassLoaderSpi
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.7.0_21-b11
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 1.7
java.vendor = Oracle Corporation
java.vendor.applet = true
java.vendor.url = http://java.oracle.com/
java.vendor.url.applet = true
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
java.version = 1.7.0_21
java.version.applet = true
java.vm.info = mixed mode, sharing
java.vm.name = Java HotSpot(TM) Client VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 1.7
java.vm.vendor = Oracle Corporation
java.vm.version = 23.21-b01
javaplugin.nodotversion = 10212
javaplugin.version = 10.21.2.11
javaplugin.vm.options = -Ddeployment.trace.level=all -Duser.language=en
javawebstart.version = javaws-10.21.2.11
line.separator = \r\n
line.separator.applet = true
mrj.version.applet = true
os.arch = x86
os.arch.applet = true
os.name = Windows Vista
os.name.applet = true
os.version = 6.0
os.version.applet = true
package.restrict.access.com.sun.deploy = true
package.restrict.access.netscape = false
package.restrict.access.org.mozilla.jss = true
package.restrict.access.sun = true
package.restrict.definition.com.sun.deploy = true
package.restrict.definition.java = true
package.restrict.definition.netscape = true
package.restrict.definition.org.mozilla.jss = true
package.restrict.definition.sun = true
path.separator = ;
path.separator.applet = true
sun.arch.data.model = 32
sun.awt.enableExtraMouseButtons = true
sun.awt.warmup = true
sun.boot.class.path = C:\tools\Java\jre7\lib\resources.jar;C:\tools\Java\jre7\lib\rt.jar;C:\tools\Java\jre7\lib\sunrsasign.jar;C:\tools\Java\jre7\lib\jsse.jar;C:\tools\Java\jre7\lib\jce.jar;C:\tools\Java\jre7\lib\charsets.jar;C:\tools\Java\jre7\lib\jfr.jar;C:\tools\Java\jre7\classes;C:\tools\Java\jre7\lib\deploy.jar;C:\tools\Java\jre7\lib\javaws.jar;C:\tools\Java\jre7\lib\plugin.jar
sun.boot.library.path = C:\tools\Java\jre7\bin
sun.cpu.endian = little
sun.cpu.isalist = pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
sun.desktop = windows
sun.io.unicode.encoding = UnicodeLittle
sun.java.command = sun.plugin2.main.client.PluginMain write_pipe_name=jpi2_pid7004_pipe37,read_pipe_name=jpi2_pid7004_pipe36
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = Cp1252
sun.management.compiler = HotSpot Client Compiler
sun.net.client.defaultConnectTimeout = 120000
sun.net.http.errorstream.enableBuffering = true
sun.os.patch.level = Service Pack 2
trustProxy = true
user.country = FR
user.dir = C:\dtaille\TMA\perfs_br\newcert
user.home = C:\Users\taille
user.language = fr
user.name = taille
user.script =
user.timezone = Europe/Paris
user.variant =
Vider les propriétés de déploiement...
active.deployment.proxy.bypass.local = false
active.deployment.proxy.same = false
active.deployment.proxy.type = 3
deployment.baseline.url = https://javadl-esd-secure.oracle.com/update/baseline.version
deployment.blacklist.url = https://javadl-esd-secure.oracle.com/update/blacklist
deployment.blacklisted.certs.url = https://javadl-esd-secure.oracle.com/update/blacklisted.certs
deployment.browser.path = C:\Program Files\Mozilla Firefox\firefox.exe
deployment.browser.vm.iexplorer = true
deployment.browser.vm.mozilla = true
deployment.cache.enabled = true
deployment.cache.jarcompression = 0
deployment.cache.max.size = 726
deployment.capture.mime.types = false
deployment.console.startup.mode = SHOW
deployment.control.panel.log = false
deployment.expiration.decision.10.21.2 = later
deployment.expiration.decision.suppression.10.21.2 = true
deployment.expiration.decision.timestamp.10.21.2 = 9/6/2013 15:29:3
deployment.insecure.jres = PROMPT
deployment.javafx.mode.enabled = true
deployment.javapi.cache.update = false
deployment.javapi.lifecycle.exception = false
deployment.javapi.log.filename =
deployment.javapi.runtime.type = 0
deployment.javapi.stop.timeout = 200
deployment.javapi.trace.filename =
deployment.javaws.appicon.index = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\appIcon\appIcon.xml
deployment.javaws.associations = ASK_USER
deployment.javaws.cache.update = false
deployment.javaws.concurrentDownloads = 4
deployment.javaws.install = IF_HINT
deployment.javaws.installURL = http://java.sun.com/products/autodl/j2se
deployment.javaws.logFileName =
deployment.javaws.muffin.max = 256
deployment.javaws.shortcut = ASK_IF_HINTED
deployment.javaws.splash.index = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\splash\splash.xml
deployment.javaws.traceFileName =
deployment.javaws.uninstall.shortcut = false
deployment.javaws.update.timeout = 1500
deployment.javaws.viewer.bounds = 1723,197,881,546
deployment.jpi.mode.new = true
deployment.log = false
deployment.macosx.check.update = true
deployment.max.output.file.size = 10
deployment.max.output.files = 5
deployment.mime.types.use.default = true
deployment.modified.timestamp = 1380804178316
deployment.proxy.bypass.local = false
deployment.proxy.override.hosts =
deployment.proxy.same = false
deployment.proxy.type = 3
deployment.security.SSLv2Hello = false
deployment.security.SSLv3 = true
deployment.security.TLSv1 = true
deployment.security.TLSv1.1 = false
deployment.security.TLSv1.2 = false
deployment.security.askgrantdialog.notinca = true
deployment.security.askgrantdialog.show = true
deployment.security.authenticator = true
deployment.security.blacklist.check = true
deployment.security.browser.keystore.use = true
deployment.security.clientauth.keystore.auto = true
deployment.security.disable = false
deployment.security.https.warning.show = false
deployment.security.jsse.hostmismatch.warning = true
deployment.security.level = HIGH
deployment.security.local.applets = PROMPT
deployment.security.mixcode = DISABLE
deployment.security.notinca.warning = true
deployment.security.password.cache = true
deployment.security.run.untrusted = PROMPT
deployment.security.sandbox.awtwarningwindow = true
deployment.security.sandbox.casigned = PROMPT
deployment.security.sandbox.jnlp.enhanced = true
deployment.security.sandbox.selfsigned = PROMPT
deployment.security.trusted.policy =
deployment.security.validation.crl = false
deployment.security.validation.ocsp = false
deployment.security.validation.ocsp.publisher = false
deployment.system.cachedir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\SystemCache
deployment.system.security.blacklist = C:\tools\Java\jre7\lib\security\blacklist
deployment.system.security.cacerts = C:\tools\Java\jre7\lib\security\cacerts
deployment.system.security.jssecacerts = C:\tools\Java\jre7\lib\security\jssecacerts
deployment.system.security.oldcacerts = C:\tools\Java\jre7\lib\security\cacerts
deployment.system.security.oldjssecacerts = C:\tools\Java\jre7\lib\security\jssecacerts
deployment.system.security.trusted.certs = C:\tools\Java\jre7\lib\security\trusted.certs
deployment.system.security.trusted.clientauthcerts = C:\tools\Java\jre7\lib\security\trusted.clientcerts
deployment.system.security.trusted.jssecerts = C:\tools\Java\jre7\lib\security\trusted.jssecerts
deployment.system.security.trusted.libraries = C:\tools\Java\jre7\lib\security\trusted.libraries
deployment.system.tray.icon = true
deployment.trace = true
deployment.update.mime.types = true
deployment.user.cachedir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache
deployment.user.extdir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\ext
deployment.user.logdir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\log
deployment.user.security.blacklist = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklist
deployment.user.security.blacklist.dynamic = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklist.dynamic
deployment.user.security.blacklisted.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklisted.certs
deployment.user.security.policy = file:/C:/Users/taille/AppData/LocalLow/Sun/Java/Deployment/security/java.policy
deployment.user.security.sandbox.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\sandbox.certs
deployment.user.security.saved.credentials = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\auth.dat
deployment.user.security.trusted.cacerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.cacerts
deployment.user.security.trusted.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs
deployment.user.security.trusted.clientauthcerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.clientcerts
deployment.user.security.trusted.jssecacerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.jssecacerts
deployment.user.security.trusted.jssecerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.jssecerts
deployment.user.security.trusted.libraries = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.libraries
deployment.user.tmp = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\tmp
deployment.version = 7.21
deployment.webjava.enabled = true
java.quick.starter = false

This behavior was introduced by a security "fix" intended to prevent a DNS re-binding attack which permits unsigned applets to escape the applet sandbox. The "fix" was, imo, very poorly thought out. You think you have a problem with 1.5 megabits of applet jars, but I have 8 megabytes, hundreds of thousands of users, with lousy networks. So now I'm stuck with a colocation vendor. Imagine my chagrin when they changed *their* ISP and thus their IP addresses.
As far as I can see, signed applets are already permitted (if the user allows) to communicate outside the sandbox, so this "fix" should not have been applied to signed jars, only to unsigned ones. There are a couple of other techniques that Oracle might have used to prevent this attack, but they chose the simplest one, effectively preventing anyone from using the most common, inexpensive strategies for improving the availability of their web-based Java applications.

PSE locked for changes during certificate deletion

Hi all,
SSO certificate is expired on our system. I have created the certificate using VA but when i went to tcode strustsso2 and tried to delete the old certificate. I am not able to delete it as its throwing error as PSE locked for changes. Kindly suggest on it.
Regards,
Karthik.R

Hi,
Please make sure there is no other person who is running STRUSTSSO2.
Maybe you can restart your system and try again.
Best regards,
Shuai

Question about Java Applet Jar file signing.

These questions pertain to Java 6 Standard Edition 1.6.0_22-b04 and later.
I have gone through the Oracle Java Tutorial for generate public and private key information
to sign a jar file, and how to sign the jar itself, all at
[http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html|http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html]
, and seek some clarification on the following related questions:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?
-using the policytool policy file generator, what do I need to add under "Principals"
(if anything) when dealing with a Java applet? Are Codebase and SignedBy simply author information?
-If I choose to use a java.security.Permission subclass object set up in equivalent fashion within the Applet,
which class within the Applet jar do I instantiate that object in? Does it need to be mentioned
in the applet's jar Manifest.MF file?
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?
-With this being the case, can the applet now escape
the sandbox, be it with or without the stipulated
policy permissions?

848439 wrote:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?Just sign the applet, the policy file is not necessary.
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?No.
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).No. For a signed Jar, all the information is contained inside the Jar.
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?No. It is the JVM that determines when to pop the confirmation dialog.
-With this being the case, can the applet now escape
the sandbox, ..Assuming the end-user OK's the trust prompt, yes.
..be it with or without the stipulated
policy permissions?Huh?

What are EXACT STEPS for giving an applet unrestricted access?

Hello all,
My company has developed a library for Java applications, and it's packaged in a jar file. We recently needed to create an applet to put on our website to demo the library's functionality. However, because it wasn't designed to be used in an applet, we get all kinds of security violations when running it in a web browser (reading system properties, reading Preferences API, reading local files, etc.)
What we want is a really simple way for our potential customers to run this applet and give it permission to do whatever. We're a trustworthy company so they will be willing to accept an applet signed by us. However, they will not be willing (or even know how) to modify security policy files on their local machine.
Can an applet signed by us get these permissions without the end user having to modify their policy file? I tried signing the applet using the techniques from
http://www-personal.umich.edu/~lsiden/tutorials/signed-applet/signed-applet.html
but the link may be out-of-date and it didn't work. Frankly I think Sun has failed miserably with regards to applet security - they made it incredibly difficult to do correctly and they provide no documentation on how to do it. Basically every topic in this forum is asking the same question - how do you easily give an applet permission to do what it needs to do?
So here's the question: once and for all, can anyone provide a list of the exact steps necessary to give an applet permissions?

Hello.
"1. Create your code for the applet as usual.
It is not necessary to set any permissions or use security managers in
the code.
2. Install JDK 1.3
Path for use of the following commands: [jdk 1.3 path]\bin\
(commands are keytool, jar, jarsigner)
Password for the keystore is *any* password. Only Sun knows why...
perhaps ;-)
3. Generate key: keytool -genkey -keyalg rsa -alias tstkey
Enter keystore password: *******
What is your first and last name?
[Unknown]: Your Name
What is the name of your organizational unit?
[Unknown]: YourUnit
What is the name of your organization?
[Unknown]: YourOrg
What is the name of your City or Locality?
[Unknown]: YourCity
What is the name of your State or Province?
[Unknown]: YS
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Your Name, OU=YourUnit, O=YourOrg, L=YourCity, ST=YS, C=US
correct?
[no]: yes
(wait...)
Enter key password for tstkey
(RETURN if same as keystore password):
(press [enter])
4. Export key: keytool -export -alias tstkey -file tstcert.crt
Enter keystore password: *******
Certificate stored in file tstcert.crt
5. Create JAR: jar cvf tst.jar tst.class
Add all classes used in your project by typing the classnames in the
same line.
added manifest
adding: tst.class(in = 849) (out= 536)(deflated 36%)
6. Verify JAR: jar tvf tst.jar
Thu Jul 27 12:58:28 GMT+02:00 2000 META-INF/
68 Thu Jul 27 12:58:28 GMT+02:00 2000 META-INF/MANIFEST.MF
849 Thu Jul 27 12:49:04 GMT+02:00 2000 tst.class
7. Sign JAR: jarsigner tst.jar tstkey
Enter Passphrase for keystore: *******
8. Verifiy Signing: jarsigner -verify -verbose -certs tst.jar
130 Thu Jul 27 13:04:12 GMT+02:00 2000 META-INF/MANIFEST.MF
183 Thu Jul 27 13:04:12 GMT+02:00 2000 META-INF/TSTKEY.SF
920 Thu Jul 27 13:04:12 GMT+02:00 2000 META-INF/TSTKEY.RSA
Thu Jul 27 12:58:28 GMT+02:00 2000 META-INF/
smk 849 Thu Jul 27 12:49:04 GMT+02:00 2000 tst.class
X.509, CN=Your Name, OU=YourUnit, O=YourOrg, L=YourCity, ST=YS, C=US
(tstkey)
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
9. Create HTML-File for use of the Applet by the Sun Plugin 1.3
(recommended to use HTML Converter Version 1.3)
10. Place a link to the .crt file (created in step 4) in the HTML-File.
This .crt file has to be opened by the browser and has to be set to
trusted,
as the root CA for testing is not known to the browser. For use with
"real" certificates, this step should not be necessary."
Only one my comment. You should sign all jars that your applet requires.

Grant permission for a signed applet

I have my jar file signed. Now, I hate to have the user to modify their .java.policy file, beside, I did not have my certificate verified by Verisign. Is there any other way to do it? I have read some posts which the user of the signed applet will see a pop up dialog while loading the signed applet, if they click on "grant all access", then the applet will have all the permission. Can anyone tell me how to do that?
Thanks
Andy

nicoleman1 put together a "tutorial" on signing your applet (jar). The instructions will work for all browsers that support the Java Plugin.
Here is a link to the thread:
http://forum.java.sun.com/thread.jsp?forum=63&thread=174214
Pete

Slow download of large applet jars - please help!

We have a large applet (7 meg plus several meg more
in 3rd party libraries) which take too long to download
under slow connections (e.g. wireless VPNs). We cannot
depend on browser/java-plugin cache to speed things up
because users clear caches often. Our market will not consider
an "installed application" as an alternative. There is now a political
effort where I work to throw out lots of excellent Java technology
because of this.
Here is what I need:
* Break our code into several smaller jars and initially
download just one small applet jar that logs a user into
our service.
* Treat all the rest of the jars as portions of a "plug-in", which
is downloaded after that, as needed, and installed on the client
machine outside of browser/plugin cache.
* The main small applet code would "install the plugin" as needed
and call into these installed jar files to do all the rest of it's work
* The jars that are part of this "plug-in" would have their own smart
update mechanism so only the portions changed in a new release
need to be downloaded - implemented apart from the Java plugin
cache.
Yes, the plugin concept is largely user perception, but in our market
it is unavoidable. If the first small piece loads and runs quicker, then
the installation of a "plugin" after that may be more tolerable. And the
downloaded components won't get lost by clearing caches.
If anyone has ideas on how to do this, please help. Otherwise a lot
of really good Java technology will go down the drain for largely
political reasons. I need a good technical solution for this.
Thanks,
/Mark

Another point: we need the first small jar file to download
and start running without the other jar files. The other jar files
need to then be downloaded on-demand and/or in the background
with good user feedback (e.g. progress bar) - giving the perception
to the user of "components of a plug-in" being installed. So we'd
need to invent some deferred-fetching stuff.
What users really don't like is waiting a long time for EVERYTHING
to download and nothing has actually started to run. It doesn't seem
like the Java plug-in alone will get us to that point.
/Mark

Restricting Permissions in signed applet jar

I have an applet, created a signed jar and when I run it in my browser a dialog box asking me to grant all permissions... which is nice...
However, is it possible to limit the permissions of that jar WITHOUT doing anything to the policy files on the client machine? Is it possible for an applet to specify which permissions it would like?
Any ideas!!

as far as I know you can only restrict the permissions
when you create the policy file, but if there where in
the next revision a kind of option during the signing
process it would be great.Hummh... I don't know if I understand this well. You are saying that it's from the responsability of the Applet provider/developer to restrict the permissions that the Applet will have or not on the computer client?!
I don't think that makes sense! The client itself should be the only authority to say what permissions he would like to give to the Applet or not.
For instance, I made an Applet and I signed. When I opened it on a browser, it asks only if I trust on the certificate. If yes, the Applet will run. If not, it won't run at all.
Question:
-In my tests, why is that my Java plugin didn't shown what is the special grants that the Applet needs? There is only give or not give? I would like to know what kind of special permissions the Applet gives to decide if I would let it run or not? By default the client has no .java.policy file...
Thanks,
Pedro Salazar.
P.S.-I'm running (testing) on jdk1.4.2+Mozilla+Linux.

User Exit/ Badi for Changing Quant parameters during TO Creation

Hi Gurus,
Could you please guide me to advice the User Exit/Badi which can be used for changing Quant Data during TO Creation.
User Requirement: Using "Recepient Field" in MIGO as a Key Value for FIFO in WM during goods issue. Receipient is copied into TR and TO (Standard SAP Functionality). For the purpose of Stock Removal based on Receipient Value, we need to copy this value into Quant Data field named Certificate Number ("LQUA-ZEUGN").
I will highly appreciate reply from Gurus.
Regards,
Gupta M

Hi manish,
Use the Exit MWMTO001 for this purpose and modify the table accordingly. This will solve your problem.
Thanks,
Shibashis

Cannot perform Bean lookup on signed Applet jar

Hi All,
I'm after developing an applet which runs from a number of jars on an Orion app server. Each one of these jars are signed and I can access the Applet okay. The problem is that I make remote reference to EJB's throughout the application. I cannot perform a Bean lookup on a signed jar. The only way it can be done is when the Client is granted all permissions. The client should pop up an option to grant permissions.

If u are signing all the jar file along with the applet it should work
It does work fine with me. my code given below
note that i carry the following jar files along with my applet jar.
orion.jar,ejb.jar,,jta.jar,jnet.jar,jsse.jar,jcert.jar,parser.jar
and have them in my archive attribute of my html code for the applet
also all these jars are signed
hope this helps
regards
raees
public void init()
     try
          Hashtable env = new Hashtable();
          env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
          env.put(Context.PROVIDER_URL, "ormi://solomon:23791/helloApp");
          env.put("java.naming.security.principal", "admin");
          env.put("java.naming.security.credentials", "secret");
          Context ic = new InitialContext (env);
          HelloHome hello_home = (HelloHome)ic.lookup("HelloBean");
     Hello hello = hello_home.create ();
          System.out.println (hello.helloWorld ());
     }catch(Exception e)
          e.printStackTrace();

Loading images inside applet JAR

Hi
This is my issue: I have an applet which contains images inside the applet JAR. I want to display these images in my applet, but apparently due to browser access restrictions, I'm not allowed.
My first code was like this:
//security restrictions on browsers do not allow getResource
ImageIO.read(MyClass.class.getResource("imgs/img.png"));
//getResourceAsStream should be allowed by browsers
ImageIO.read(MyClass.class.getResourceAsStream("imgs/img.png"));Both lines work when I execute the applet locally (command line / programming IDE), but when I deploy it to my web server, the resource "imgs/img.png" becomes a relative URL to my web application context (like /webcontext/MyClass/imgs/img.png). It works locally because the call to getResource returns a URL object with "file:" protocol, but I need it to look for my images bundled inside the JAR, not web hosted images.
I need to avoid making the applet look for these images as a web resource... how can I do it?
Thanks!

dev@java wrote:
warnerja wrote:
I'm not convinced the code you posted wouldn't work, but since this is an applet, you have access to the Applet class. Check out the Applet.getImage method in conjunction with Applet.getCodeBase.
[http://java.sun.com/javase/6/docs/api/java/applet/Applet.html]
getCodeBase returns my web context, like http://myhost.com/mycontext/ , so it is pretty much the same as above.
Thanks for your replyThat is the way to load resources though. Hence back to my earlier statement about not being convinced it would not work, with this addition: It should work, assuming you actually do have the resources properly located with the web app, whether they be in a jar, or loose files relative to where the web app is. My guess at this point is that they are not.

HTML for multi-archive applet

Could someone point me to some sample HTML for running an applet? Examples litter the web but I can't find anything that meets the following criteria:
1. Valid XHTML 1.1 (uses 'object' tag).
2. References multiple JAR files.
3. Applet class not in default package.
4. Executes successfully on latest versions of both Internet Explorer and Firefox.

>
I've made the app available via JNLP as well but was hoping to provide a version that would not require any user confirmations ..>Any JWS app. that requires 'user confirmations' would also require the end user to 'confirm' the digitally signed applet code.
>
..and will remain embedded in a web page. >From 1.6.0_10+, an applet configured by JNLP can remain 'embedded in a web page'.
>
..I don't understand why such a seemingly straightforward task entails a "heap of trouble" anyway. I got it working in Firefox with the following:
I'm probably just missing some minor tweak for IE?>Out of just two browsers, probably on a single OS, you are already experiencing 'technical difficulties' with 50% of the target browsers. Multiply that to 4 major browsers across 3 OS' and you end up with 12 browser/JRE combos. Add to that odd little eccentricities in particular browser builds (e.g. at one time an entire page and applet would be reloaded in FF if the user scrolled 'up' - that is just one of my favourite quirks, not so much a rare one).
That is (the tip of the iceberg) of why I mentioned it was a "heap of trouble" embedding an applet in a web page.
Having said that, I am not able to advise on any tweak for IE. I am running Ubuntu, and on the occasions I deploy applets, I do it in HTML 4.01 Transitional (HTML 3.2 with styles added), and use the applet element.

I look for guider in signing jars

Hi everybody
for what signing jars is good,for applet jars or desktop applications jars???
and how can I use it? please i need the answerer explanations not url to tutorials
Thanks to every reader to this topic

i need the answerer explanations not url to tutorialsA stupid remark. The tutorials are explanations, and they have already been reviewed, debugged, etc. Why on earth would you prefer someone's random opinion to a properly produced piece of documentation?
At best this is just lazy thinking.

"Invalid Provisioning Profile. The provisioning profile included in the bundle {BUNDLENAME} [{BUNDLENAME}.app] is invalid. [Missing code-signing certificate.]" for brand new, vanilla Mac App

In OS X Maverick's XCode, I created a brand new Mac > "Cocoa Application", with Core Data and Spotlight Importerl; about as vanilla a Cocoa application I could muster.
Under Preferences > Accounts, I signed in to my Mac Developer Account.
In Targets > Identity, I set Signing to "Mac App Store", and was able to select my Mac Developer Account for "Team".
I then went to Product > Clean, and then Product > Build for... > Running, and then Produt > Archive.
In the Organizer, I select the resulting .app and click "Validate", and hit the Mac App Store radio, and hit "Next", and it's able to log into my Mac Developer Account.
I select my Provisioning Profile in the dropdown, and click "Validate".
It comes back with several errors:
1 - "Invalid Provisioning Profile. The provisioning profile included in the bundle {BUNDLENAME} [{BUNDLENAME}.app] is invalid. [Missing code-signing certificate.] For more information, visit the Mac OS Developer Portal."
2 - "The bundle identifier cannot be changed from the current value, '{DIFFERENT-BUNDLE-FROM-OTHER-PROJECT}'. If you want to change your bundle identifier, you will need to create a new application in iTunes Connect.
3 - Invalid Code Signing Entitlements. The entitlements in your app bundle signature do not match the ones that are contained in the provision profile. The bundle contains a key that is not included in the provisioning profile: 'com.apple.applications-identifier' in '{BUNDLENAME}.app/Contents/MacOS/{BUNDLENAME}'
I was able to do the same process before, for a vanilla app, before Mavericks. I'm not sure if this is a Mavericks error, or a fact that now I have multiple app projects. Particularly odd is that DIFFERENT-BUNDLE-FROM-OTHER-PROJECT in error (2) is not the same bundle name as the current project's bundle.
Would love any help you can provide! Thank you!

Seen this thread?
New codesign behavior, --deep option
"Code signing has some interesting changes in Mavericks (that apparently haven't made it into the release notes yet...). Note that this is a change to the operating system, not to the devtools."

Can any one change this Applet into a class that extends Jpanel.....

Hi,
I need this applet as a class that extends JPanel, I will be very very thankful to you if any one kindly change this Applet code into a class that extends JApplet.
I will be very thankful to you if some one can reserve few minutes & do this favor early.
Thanks a lot for any help.
     My Pong Code
import java.applet.*;
import java.awt.*;
import java.io.*;
import java.awt.event.*;
public class Class1 extends Applet implements Runnable
{     private final int APPLET_WIDTH = 900;
     private final int APPLET_HEIGHT = 600;
     private int px = 15;
     private final int py = 560;
     private final int ph = 10;
     private final int pw = 75;
     private int old_px = px;
     private int bx = 450;
     private int by = 15;
     private final int bh = 20;
     private final int bw = 20;
     private int move_x = 2;
     private int move_y = 2;
     private boolean done = false;
     Thread t;
     private final int delay = 25;
     public void init()
     {     setBackground(Color.black);
          setSize(APPLET_WIDTH, APPLET_HEIGHT);
          requestFocus();
          addKeyListener(new DirectionKeyListener());
         (t = new Thread(this)).start();
     public void run()      {
    try      {     while((t == Thread.currentThread()) && (done == false))           {
               if ((bx < 15) || (bx > APPLET_WIDTH-30))                     move_x = -move_x;                                if ((by < 15) ||                   ((by > APPLET_HEIGHT-60)&&                     ((px<=bx)&&(bx<=px+pw))))
                    move_y = -move_y;
               if (by > APPLET_HEIGHT)
                    done = true;
                               bx = bx + move_x;
               by = by + move_y;                                                repaint();
               t.sleep(delay);
     catch(Exception e)      {}
     }//end run
     /*public void move_paddle(int amount)
          old_px = px;
          //if (amount > 0)
            //if (px <= APPLET_WIDTH-15)
               px = px + amount;
          //else if (amount < 0)
           // if (px >= 15)
               px = px + amount;
     public void paint(Graphics page)
          //     page.setColor(Color.black);
          //     page.drawRect(old_px, py, pw, ph);
               page.setColor(Color.blue);
               page.drawRect(px, py, pw, ph);
               page.setColor(Color.white);
               page.drawOval(bx, by, bw, bh);
               if ((done == true) && (by > APPLET_HEIGHT))
                    page.drawString("LOSER!!!", APPLET_WIDTH/2, APPLET_HEIGHT/2);
               else if (done == true)
                    page.drawString("Game Over, Man!", APPLET_WIDTH/2-10, APPLET_HEIGHT/2);
     private class DirectionKeyListener implements KeyListener
          public void keyPressed (KeyEvent event)
               switch (event.getKeyCode())
               case KeyEvent.VK_LEFT:
                    old_px = px;
                    if (px >=15)
                         px -=10;
                    break;
               case KeyEvent.VK_RIGHT:
                    old_px = px;
                    if (px+pw <= APPLET_WIDTH-15)
                         px += 10;
                    break;
               case KeyEvent.VK_Q:
                    done = true;
               default:
               } //end switch
               repaint();
          }//end keyPressed
          public void keyTyped (KeyEvent event)
          public void keyReleased (KeyEvent event)
     } //end class
}

thank you sir for your advice.
Its not like that I without any attempt, just past code here & asked for its conversion. I spent about 5 hours on it, can say spoil whole day but to no avail. You then just guide me, give some hint so that I do it. I will most probably wanted to do it by myself but asked for help when was just disappointed.
I try to put all init() in default constructor of identical copy of this applet that extends JPanel. Problem.....ball tend to fell but pad not moving. Also out out was not getting ant color input. That was like my best effort.....other tried that I found by search like just do nothing only extend panel OR frame in spite of applet, start applet from within main of another class.... these are few I remember what I tried.
I will be very very thankful to you if you can help/guide me how can I do it. Behavior of the Applet is like a normal PONG game with on pad controlled by arrow keys, & one ball colliding with walls of boundary & falling down.
Thanks a lot again for your attention & time.

Certificate inquiry for changes in applet jar

Similar Messages

Maybe you are looking for