Jurisdiction policy files not in standard directory

Hi!
I'm using cryptix in a class that encrypts emails with PGP.
Everything works fine on my machine, as I have patched the jurisdiction policy files in $JAVA_HOME\jre\lib\security.
Unfortunately I haven't got write-access to $JAVA_HOME on the customers machine.
The jurisdiction policy files are located in a directory where the application runs.
Now I need a possibility to run my application and passing a parameter that causes JVM to load the jurisdiction policy files from my directory instead of loading the ones installed in the $JAVA_HOME\jre\lib\security directory.
Any hint is welcome!
thanks in advance!
Oli

Hi!
I'm using cryptix in a class that encrypts emails with
PGP.
Everything works fine on my machine, as I have patched
the jurisdiction policy files in
$JAVA_HOME\jre\lib\security.
Unfortunately I haven't got write-access to $JAVA_HOME
on the customers machine.
The jurisdiction policy files are located in a
directory where the application runs.
Now I need a possibility to run my application and
passing a parameter that causes JVM to load the
jurisdiction policy files from my directory instead of
loading the ones installed in the
$JAVA_HOME\jre\lib\security directory.
Any hint is welcome!
thanks in advance!
OliHmm, nobody ever encountered that problem?
A 'is not possible' or 'does not work' would be adequate statement.
So, I could convince my boss that it is just not possible... ;)
thanks.
Oli

Similar Messages

  • Java.lang.SecurityException: Jurisdiction policy files are not signed by t

    Hi
    *I am installing ECC6 onAIX 6.1 with oarcle 10g.*
    *I am getting error in create secure store*
    *Policy and security files are ok,*
    aused by: java.lang.ExceptionInInitializerError
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:218)
            at javax.crypto.Cipher.a(Unknown Source)
            at javax.crypto.Cipher.getInstance(Unknown Source)
            at iaik.security.provider.IAIK.a(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at com.sap.security.core.server.secstorefs.Crypt.<clinit>(Crypt.java:82)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            at com.sap.security.core.server.secstorefs.SecStoreFS.setSID(SecStoreFS.java:158)
            at com.sap.security.core.server.secstorefs.SecStoreFS.handleCreate(SecStoreFS.java:804)
            at com.sap.security.core.server.secstorefs.SecStoreFS.main(SecStoreFS.java:1274)
            ... 6 more
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
            at javax.crypto.b.<clinit>(Unknown Source)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            ... 17 more
    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.access$600(Unknown Source)
            at javax.crypto.b$0.run(Unknown Source)
            at java.security.AccessController.doPrivileged(AccessController.java:246)
            ... 20 more
    ERROR      2009-07-07 14:10:47.063
               CJSlibModule::writeError_impl()
    CJS-30050  Cannot create the secure store. SOLUTION: See output of log file SecureStoreCreate.log:
    SAP Secure Store in the File System - Copyright (c) 2003 SAP AG
    java.lang.reflect.InvocationTargetException
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:61)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
            at java.lang.reflect.Method.invoke(Method.java:391)
            at com.sap.engine.offline.OfflineToolStart.main(OfflineToolStart.java:81)
    Caused by: java.lang.ExceptionInInitializerError
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:218)
            at javax.crypto.Cipher.a(Unknown Source)
            at javax.crypto.Cipher.getInstance(Unknown Source)
            at iaik.security.provider.IAIK.a(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at com.sap.security.core.server.secstorefs.Crypt.<clinit>(Crypt.java:82)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            at com.sap.security.core.server.secstorefs.SecStoreFS.setSID(SecStoreFS.java:158)
            at com.sap.security.core.server.secstorefs.SecStoreFS.handleCreate(SecStoreFS.java:804)
            at com.sap.security.core.server.secstorefs.SecStoreFS.main(SecStoreFS.java:1274)
            ... 6 more
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
            at javax.crypto.b.<clinit>(Unknown Source)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            ... 17 more
    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.access$600(Unknown Source)
            at javax.crypto.b$0.run(Unknown Source)
            at java.security.AccessController.doPrivileged(AccessController.java:246)
            ... 20 more.
    ERROR      2009-07-07 14:10:47.547 [sixxcstepexecute.cpp:960]
    FCO-00011  The step createSecureStore with step key |NW_Onehost|ind|ind|ind|ind|0|0|NW_Onehost_System|ind|ind|ind|ind|2|0|NW_CreateDBandLoad|ind|ind|ind|ind|10|0|NW_SecureStore|ind|ind|ind|ind|8|0|createSecureStore was executed with status ERROR ( Last error reported by the step :Cannot create the secure store. SOLUTION: See output of log file SecureStoreCreate.log:
    SAP Secure Store in the File System - Copyright (c) 2003 SAP AG
    java.lang.reflect.InvocationTargetException
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:61)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
            at java.lang.reflect.Method.invoke(Method.java:391)
            at com.sap.engine.offline.OfflineToolStart.main(OfflineToolStart.java:81)
    Caused by: java.lang.ExceptionInInitializerError
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:218)
            at javax.crypto.Cipher.a(Unknown Source)
            at javax.crypto.Cipher.getInstance(Unknown Source)
            at iaik.security.provider.IAIK.a(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at com.sap.security.core.server.secstorefs.Crypt.<clinit>(Crypt.java:82)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            at com.sap.security.core.server.secstorefs.SecStoreFS.setSID(SecStoreFS.java:158)
            at com.sap.security.core.server.secstorefs.SecStoreFS.handleCreate(SecStoreFS.java:804)
            at com.sap.security.core.server.secstorefs.SecStoreFS.main(SecStoreFS.java:1274)
            ... 6 more
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
            at javax.crypto.b.<clinit>(Unknown Source)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            ... 17 more
    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.access$600(Unknown Source)
            at javax.crypto.b$0.run(Unknown Source)
            at java.security.AccessController.doPrivileged(AccessController.java:246)
            ... 20 more.).
    what could be the problem ?
    Please give me the soluation
    regards
    Vijay

    Dear Juan
    You are correct.
    I downloaded correct file from IBM site , and Create Secure store step completed but innext step IMPORT JAVA DUMP
    it gave error
    n error occurred while processing service SAP ERP 6.0 Support Release 3 > SAP Systems > Oracle > Central System > Central System( Last error reported by the step : Execution of JLoad tool '/usr/java14_64/bin/java -classpath /swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/launcher.jar -showversion -Xmx512m -Xj9 com.sap.engine.offline.OfflineToolStart com.sap.inst.jload.Jload /swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/lib/iaik_jce.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/jload.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/antlr.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/exception.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/jddi.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/logging.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/offlineconfiguration.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/opensqlsta.jar:/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/install/sharedlib/tc_sec_secstorefs.jar:/oracle/client/10x_64/instantclient/ojdbc14.jar -sec AGQ,jdbc/pool/AGQ,/usr/sap/AGQ/SYS/global/security/data/SecStore.properties,/usr/sap/AGQ/SYS/global/security/data/SecStore.key -dataDir /swdump/NW7.0_SR3_JAVA_COMP_51033513/DATA_UNITS/JAVA_EXPORT_JDMP -job /swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/IMPORT.XML -log jload.log' aborts with return code 1. SOLUTION: Check 'jload.log' and '/swdump/tmpinst/sapinst_instdir/ERP/SYSTEM/ORA/CENTRAL/AS/jload.java.log' for more information.
    regards
    vijjay

  • Jurisdiction policy files are not signed by trusted signers!

    Hi All,
    I am getting the following Security exception while running a Java stand-alone program on Linux.
    The stand-alone program internally calls the JCE (Java Cryptography Extension) library for Encryption of data. The JCE Unlimited Strength Jurisdiction policy files are downloaded from Sun.
    Does anybody have the solution for this error?
    Is there Security policy modification to be made for the same?
    Exception in thread "main" java.lang.ExceptionInInitializerError
    at javax.crypto.Cipher.a(Unknown Source)
    at javax.crypto.Cipher.getInstance(Unknown Source)
    at lncrypt.LnCryptBase.encryptImpl(LnCryptBase.java:122)
    at lncrypt.LnAes.encrypt(LnAes.java:78)
    at CloakingUtils.encrypt(CloakingUtils.java:69)
    at AlertsMigrationSweepUtil.updateAlerts(AlertsMigrationSweepUtil.java:203)
    at AlertsMigrationSweepUtil.main(AlertsMigrationSweepUtil.java:65)
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
    at javax.crypto.e.<clinit>(Unknown Source)
    ... 7 more
    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
    at javax.crypto.e.a(Unknown Source)
    at javax.crypto.e.a(Unknown Source)
    at javax.crypto.e.g(Unknown Source)
    at javax.crypto.f.run(Unknown Source)
    at java.security.AccessController.doPrivileged1(Native Method)
    at java.security.AccessController.doPrivileged(AccessController.java:351)
    ... 8 more
    Regards,
    Vilas Kulkarni

    Make sure that which javaindicates the Java executable you expect.

  • Override JCE default (limited strength) jurisdiction policy files

    Hi!
    I am writing an applet, which has to decrypt encrpyted file with some simetric algorithm, e.g. PBEWithMD5AndTripleDes. Due llimitations of key lengths in default (limited strength) jurisdiction policy files for JCE I cannot use for example TripleDES with 168 bit key or. Blowfish with 400 bit key.
    I know I can obtain Unlimited version of these files from java.sun.com and replace this files in JDK/JRE installation directory. That's ok for us at server side, but disaster at client (applet) side, because we must modify installation of JRE on every computer where user want to use applet and update it every time when JRE is being updated.
    So me question is: is there any way to distribute unlimited jurisdiction files with an applet (I know how to include *.jar files) and make it work? For example via endorsed mechanism, setting some security property, reloading JCE?
    Thanks for help!

    You can't override them. Since the restriction apply only to the JCE, your best bet is to use the lightweight API from Bouncy Castle which does not use the JCE.

  • Replace the JCE Unlimited Strength Jurisdiction Policy files - SAP JVM 5

    Hi Experts,
    I had a NetWeaver 7.1 system with SAP JVM 5. I tried to run a cryptography software on the system, but the current JCE Unlimited Strength Jurisdiction Policy files of the JVM limited encryption algorithms and key lengths.
    I downloaded the jce_policy-1_5_0.zip file from the Sun website, unzipped it, replaced the old policy files (sapjvm_5/jre/lib/security/local_policy.jar and sapjvm_5/jre/lib/security/US_export_policy.jar) with the new ones, then restarted the server. But, after the server was restarted, the new policy files were deleted and the old ones were restored.
    Could you tell me what should I do to apply the new policy files?
    Thanks in advance.
    Victor

    Issue Resolved..with help of OSS note :739043
    EP 6.0 SP15.... I had same issue for Portal prodution:
    I had  copied new files (local_policy.jar and US_export_policy.jar) in directory /opt/java1.4/jre/lib/security
    Jun 16  2003 local_policy.jar
    -rw-rr   1 root       sys           4355 Jun 16  2003 US_export_policy.jar
    -rw-rr   1 root       sys           2910 Aug  2  2007 local_policy.1.jar
    -rw-rr   1 root       sys           2429 Aug  2  2007 US_export_policy.1.jar
    -rrr--   1 bin        bin           2910 Dec 12 10:14 local_policy.2.jar
    -rrr--   1 bin        bin           2429 Dec 12 10:14 US_export_policy.2.jar
    -rrr--   1 bin        bin           2223 Dec 12 10:25 java.policy
    -rrr--   1 bin        bin           6871 Dec 12 10:25 java.security
    -rrr--   1 bin        bin          41278 Dec 12 10:25 cacerts
    Thanks,
    Hari

  • How do I apply JCE Jurisdiction Policy Files in oracle jvm

         I have some java procedure using AES, while the default key size limit is 128.
         For local java, I can easily replace Jurisdiction Policy Files in JDK OR JRE,  But I do not know how to do such thing in oracle database(11g2) jvm

    $ORACLE_HOME/jdk/jre/lib/security

  • Software distribution and Unlimited Strength Jurisdiction Policy Files

    I suppose, I'm NOT allowed to ship the Unlimited Strength Jurisdiction Policy Files (USJPF) with my application,
    even if living in Germany and not selling abroad, right?
    So I see 2 possibilities:
    - Use weaker encryption by default and encourage the users to download the USJPF by themself.
    - Implement a stronger encryption on the base of the weaker one by encrypting several times, let say in the way 3DES works.
    I'm quite sure, I'm not the only one facing such a problem, how do you solve it?

    The export of cryptography is usually contingent on the laws of the country that you live in. As a US citizen, I know that I cannot ship unlimited strength cryptography to specific countries without a permit. You should check what German law allows you to do (I was under the impression that Germany did not have such controls, but that impression could be dated) and read the license accompanying the USJPF in Germany, to see what restrictions are placed on it.
    Another option is to use a provider fhat is developed outside the US. I know that BouncyCastle is developed in Australia, so the US restrictions would not apply to them. Have you checked their licensing agreement to see what you're allowed to do with their provider files?

  • JCE: jurisdiction policy files

    Hello, I am new to this forum and my English is not very well. I have the following problem. I wish to use unlimited cryptography within an applet. I know, if I want to use unlimited crypto I have to install the unlimited jurisdiction policy files. Because mostly the JRE is installed under c:\programm files, where a normal user would not have the right to write, it is not very convenient to ask an admin for every workstation to install the unlimited jurisdiction policy files. Is there anyway to use unlimited crypto without touching the clients JRE?!?!
    Is it possible to install the unlimited jurisdiction policy files in another location on client at runtime???
    Maybe I can use an alternate JCE (BC or GNU)? But how? I think I can not install a new javax.crypto* from an applet? Maybe it�s possible to user another packet name?
    Or is it possible to use the cipher functionality of a provider outside the JCE?
    Have somebody had the same problem before? Any answer is very welcome!
    Regards from Berlin!

    If it could be done, it would be a serious security bug. Normal users cannot remove or change that file at all under Windows, only power users or admins can do that. An applet can have access to a file, but only if it gets permission to do so (e.g. by being signed by a trusted source, or by being accepted by the user). But to do something with this particular file, an admin should be starting up the browser really.

  • Jurisdiction Policy Files

    I am implementing a simple cipherstream for commmunication between server and client for a building automation protocol called BACnet. My code compiles but when I attempt to run it I get the following error:
    Exception in thread "main" java.lang.ExceptionInInitializtoinError
    at javax.crypto.SecretKeyFactory.getInstance(DashoA6275)
    at sen.CommMod.main(CommMod.java:30)
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
    at javax.crypto.SunJCE_b.<<clinit>(DashoA6275)
    ...2 more
    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
    at javax.crypto.SunJCE_b.a(DashoA6275)
    at javax.crypto.SunJCE_b.f(DashoA6275)
    at javax.crypto.SunJCE_b.e(DashoA6275)
    at javax.crypto.SunJCE_b.run(DashoA6275)
    at java.security.AccessController.doPriveleged(Native Metthod)
    ... 3 more
    sen is the name of the package and CommMod is the name of my class file. I have edited the java.security file to include SunJCE as a security provider and Sun is listed as the first provider as per the known bugs for the JCE.
    Is there anyway to get my policy files signed by a trusted signer or can I get policy files that will work that are already signed?

    Why is there no reply to this problem from Sun?
    I am also getting the same problem with JDK1.4.2_04 and JCE 1.2.2
    Are the jars that are provided with the JCE 1.2.2 not correctlly signed?

  • Java: Where are JCE Unlimited Strength Jurisdiction Policy Files for Java for Mac OS X 10.7?

    I need to install the JCE Unlimited Strength Jurisdiction Policy Files for Java 1.6 under Mac OS X 10.7.  I know where to get then from the Sun/Oracle Java download site, but want to make sure that these will work on the Mac.  Or, are there Mac specific versions somewhere?

    There's a  jce.jar file in /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/, so it appears that they're already in place, but that's just a WAG.

  • Group Policy Files Not Being Deployed to UNC Paths

    When attempting to deploy files via Group Policy Preferences, there is a well-known issue wherein you may receive an error to the effect of: 0x80070003
    The system cannot find the path specified. This is due to the local system being the security context used to deploy the file. If the local system does not have rights to the location, as is true with mapped drives, access is denied and the path cannot
    be found. The workaround for this is to enable the common option "Run under the logged in user's security context"
    However, I have done this and still receive the same error. I have verified the logged-in user can reach both the source and destination. Specifically, the source is a file server and the destination is the user's HOMEPATH,
    which resides on another fileserver in this case. More to the point, it's their redirected Documents folder, and it otherwise works fine; I cannot imagine this being a permissions or connectivity issue, especially because I receive the error even if I execute
    a gpupdate
    /force /target:user while logged in.
    I've also installed the hotfix from Microsoft pertaining to this issue: "Error
    code 0x80070003 when a Group Policy preference is applied to Windows 7 clients", but this did not change anything. (I only installed it onto the desktop; that seems to be where it belongs for my case.)
    I'm at a loss as to why this happens. The domain controllers agree the common option is set, and a gpupdate does otherwise succeed. Also, if I change the target to a location on a local drive of the computer, it works fine. I do not see the common option reflected
    in the output of gpresult,
    but I'm not sure if I should.

    Hi Ron,
    Before going further, how did we input the source file path and the destination file path? Did we input the paths as follows (t1.txt as an example):
    Action: Create
    Source file path: \\servername\sharename\username\documents\t1.txt
    Destination file path:\\servername\sharename\t1.txt
    Best regards,
    Frank Shen

  • (JCE) Unlimited Strength Jurisdiction Policy Files

    I have got my program up and running, but now i keep the following error:
    "java.security.InvalidKeyException: Illegal key size or default parameters"
         at javax.crypto.Cipher.a(DashoA13*..)
         at javax.crypto.Cipher.a(DashoA13*..)
         at javax.crypto.Cipher.a(DashoA13*..)
         at javax.crypto.Cipher.init(DashoA13*..)I have read up on it but i need to install the JCE policies. Bluej is the compiler that i am using. How to do i install the policies into this compiler. Stupid question Isuppose but any help will be appreciated.
    Thanks in adavance

    Parry1982 wrote:
    I have the local_policy.jar & US_export_policy.jar install in the following directory;
    C:\ProgramFiles\Java\jdk1.6.0_16\jreThat is not where the installation instructions tells you to put them. You did read the installation instructions didn't you?

  • HELP: How do i include a policy file when embedding a JApplet

    This is the problem i'm facing.I've been able to successfully grant my japplet permission to access resources on the c: drive. When i run it using appletviewer there's no problem, it's able to access the database on the c: drive but when i embedd it in my html page it fails to access the database (i.e it is unable to include the policy file). Does anyone know how to get around this problem?

    You can not directly include a policy within an applet. This would be a security risk.
    In general you have 2 choices if you wish to grant an applet more rights than it has per default:
    1. You can sign it.
    2. You change your local policy file.
    ad 1:
    You can generate a keypair using keytool and sign the applet with jarsigner. (you need to create a jar file first)
    when your applet is then loaded in the browser, a popup asks the user, if he wanna trust the signer. If the user clicks no, the applet is executed with standard applet rights. If the user clicks yes, the applet is executed with full permission (like an applet from file:/*)
    ad 2:
    use policytool to create/change a policy file in your home directory. You can describe the applet either with a path (=codebase) or with some meta-information like signer.
    create a policy that fits your need, and save the file.
    next time you execute your applet in the browser, the policy will grant the applet additional permissions.
    There is a third option. You can mix 1 and 2.
    You can sign your applet, and create a policy for all applets signed by you.
    Then there will be no popup, and the applet has automatically the rights you defined in the policy file.
    But I would suggest to consider the possibility to write a stand-alone application, instead of granting an applet access to the local hard disk.

  • Does anyone know how to set policy file, so applet can connect other host?

    I have an signed applet, it may connect to other host.
    The applet should display a HTML pages, which may contains image tag points to a picture stored anywhere. I use a JTextPane to display this HTML page, but when it is loaded. a error occurs.
    java.lang.SecurityException
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkConnect(Unknown Source)
    at sun.awt.image.URLImageSource.checkSecurity(Unknown Source)
    at sun.awt.image.ImageRepresentation.imageComplete(Unknown Source)
    at sun.awt.image.InputStreamImageSource.errorConsumer(Unknown Source)
    at sun.awt.image.InputStreamImageSource.setDecoder(Unknown Source)
    at sun.awt.image.InputStreamImageSource.doFetch(Unknown Source)
    at sun.awt.image.ImageFetcher.fetchloop(Unknown Source)
    at sun.awt.image.ImageFetcher.run(Unknown Source)
    I have those kind of error (connection refused) before I signed my applet and write policy file to granr socketpermission to the codebase of my class files. But this error still occurs. I suppose it is because the sun.awt.image.* is Java standard class, so my policy file has no effect on them. But how can I make it works?

    you need to install the jre, and place the win32.dll at JavaSoft\JRE\1.3.1_06\bin, that properties file place at JavaSoft\JRE\1.3.1_06\lib, comm.jar at JavaSoft\JRE\1.3.1_06\lib\ext\
    and in ur code try to use it to open ur com port
    public String test() {
    String drivername = "com.sun.comm.Win32Driver";
    try
    CommDriver driver = (CommDriver) Class.forName(drivername).newInstance(); driver.initialize();
    catch (Throwable th)
    {* Discard it */}
    drivername = "javax.comm.*";
    try
    CommDriver driver = (CommDriver) Class.forName(drivername).newInstance(); driver.initialize();
    catch (Throwable th)
    {* Discard it */}
    portList = CommPortIdentifier.getPortIdentifiers();
    while (portList.hasMoreElements()) {
    portId = (CommPortIdentifier) portList.nextElement();
    if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) {
    if (portId.getName().equals("COM2")) {
    //if (portId.getName().equals("/dev/term/a")) {
    try {
    serialPort = (SerialPort)
    portId.open("SimpleWriteApp", 2000);
    } catch (PortInUseException e) {}
    try {
    outputStream = serialPort.getOutputStream();
    } catch (IOException e) {}
    try {
    serialPort.setSerialPortParams(9600,
    SerialPort.DATABITS_8,
    SerialPort.STOPBITS_1,
    SerialPort.PARITY_NONE);
    } catch (UnsupportedCommOperationException e) {}
    int i=0;
    while(true)
    try {
    messageString="hi";
    System.out.println(i++);
    outputStream.write(messageString.getBytes());
    } catch (IOException e)
    System.out.println(e);
    messageString=String.valueOf(e);
    return messageString;
    and yet u need to signed the applet
    1. Compile the applet
    2. Create a JAR file
    3. Generate Keys
    4. Sign the JAR file
    5. Export the Public Key Certificate
    6. Import the Certificate as a Trusted Certificate
    7. Create the policy file
    8. Run the applet
    Susan
    Susan bundles the applet executable in a JAR file, signs the JAR file, and exports the public key certificate.
    1. Compile the Applet
    In her working directory, Susan uses the javac command to compile the SignedAppletDemo.java class. The output from the javac command is the SignedAppletDemo.class.
    javac SignedAppletDemo.java
    2. Make a JAR File
    Susan then makes the compiled SignedAppletDemo.class file into a JAR file. The -cvf option to the jar command creates a new archive (c), using verbose mode (v), and specifies the archive file name (f). The archive file name is SignedApplet.jar.
    jar cvf SignedApplet.jar SignedAppletDemo.class
    3. Generate Keys
    Susan creates a keystore database named susanstore that has an entry for a newly generated public and private key pair with the public key in a certificate. A JAR file is signed with the private key of the creator of the JAR file and the signature is verified by the recipient of the JAR file with the public key in the pair. The certificate is a statement from the owner of the private key that the public key in the pair has a particular value so the person using the public key can be assured the public key is authentic. Public and private keys must already exist in the keystore database before jarsigner can be used to sign or verify the signature on a JAR file.
    In her working directory, Susan creates a keystore database and generates the keys:
    keytool -genkey -alias signFiles -keystore susanstore -keypass kpi135 -dname "cn=jones" -storepass ab987c
    This keytool -genkey command invocation generates a key pair that is identified by the alias signFiles. Subsequent keytool command invocations use this alias and the key password (-keypass kpi135) to access the private key in the generated pair.
    The generated key pair is stored in a keystore database called susanstore (-keystore susanstore) in the current directory, and accessed with the susanstore password (-storepass ab987c).
    The -dname "cn=jones" option specifies an X.500 Distinguished Name with a commonName (cn) value. X.500 Distinguished Names identify entities for X.509 certificates.
    You can view all keytool options and parameters by typing:
    keytool -help
    4. Sign the JAR File
    JAR Signer is a command line tool for signing and verifying the signature on JAR files. In her working directory, Susan uses jarsigner to make a signed copy of the SignedApplet.jar file.
    jarsigner -keystore susanstore -storepass ab987c -keypass kpi135 -signedjar SSignedApplet.jar SignedApplet.jar signFiles
    The -storepass ab987c and -keystore susanstore options specify the keystore database and password where the private key for signing the JAR file is stored. The -keypass kpi135 option is the password to the private key, SSignedApplet.jar is the name of the signed JAR file, and signFiles is the alias to the private key. jarsigner extracts the certificate from the keystore whose entry is signFiles and attaches it to the generated signature of the signed JAR file.
    5. Export the Public Key Certificate
    The public key certificate is sent with the JAR file to the whoever is going to use the applet. That person uses the certificate to authenticate the signature on the JAR file. To send a certificate, you have to first export it.
    The -storepass ab987c and -keystore susanstore options specify the keystore database and password where the private key for signing the JAR file is stored. The -keypass kpi135 option is the password to the private key, SSignedApplet.jar is the name of the signed JAR file, and signFiles is the alias to the private key. jarsigner extracts the certificate from the keystore whose entry is signFiles and attaches it to the generated signature of the signed JAR file.
    5: Export the Public Key Certificate
    The public key certificate is sent with the JAR file to the whoever is going to use the applet. That person uses the certificate to authenticate the signature on the JAR file. To send a certificate, you have to first export it.
    In her working directory, Susan uses keytool to copy the certificate from susanstore to a file named SusanJones.cer as follows:
    keytool -export -keystore susanstore -storepass ab987c -alias signFiles -file SusanJones.cer
    Ray
    Ray receives the JAR file from Susan, imports the certificate, creates a policy file granting the applet access, and runs the applet.
    6. Import Certificate as a Trusted Certificate
    Ray has received SSignedApplet.jar and SusanJones.cer from Susan. He puts them in his home directory. Ray must now create a keystore database (raystore) and import the certificate into it. Ray uses keytool in his home directory /home/ray to import the certificate:
    keytool -import -alias susan -file SusanJones.cer -keystore raystore -storepass abcdefgh
    7. Create the Policy File
    The policy file grants the SSignedApplet.jar file signed by the alias susan permission to create newfile (and no other file) in the user's home directory.
    Ray creates the policy file in his home directory using either policytool or an ASCII editor.
    keystore "/home/ray/raystore";
    // A sample policy file that lets a JavaTM program
    // create newfile in user's home directory
    // Satya N Dodda
    grant SignedBy "susan"
    permission java.security.AllPermission;
    8. Run the Applet in Applet Viewer
    Applet Viewer connects to the HTML documents and resources specified in the call to appletviewer, and displays the applet in its own window. To run the example, Ray copies the signed JAR file and HTML file to /home/aURL/public_html and invokes Applet viewer from his home directory as follows:
    Html code :
    </body>
    </html>
    <OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
    width="600" height="400" align="middle"
    codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,1,2">
    <PARAM NAME="code" VALUE="SignedAppletDemo.class">
    <PARAM NAME="archive" VALUE="SSignedApplet.jar">
    <PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
    </OBJECT>
    </body>
    </html>
    appletviewer -J-Djava.security.policy=Write.jp
    http://aURL.com/SignedApplet.html
    Note: Type everything on one line and put a space after Write.jp
    The -J-Djava.security.policy=Write.jp option tells Applet Viewer to run the applet referenced in the SignedApplet.html file with the Write.jp policy file.
    Note: The Policy file can be stored on a server and specified in the appletviewer invocation as a URL.
    9. Run the Applet in Browser
    Download JRE 1.3 from Javasoft
    good luck! [email protected]
    i already give u many tips, i use 2 weeks to try this to success, hopw that u understand that, a result of success is not important, the process of how to get things done is most usefull!

  • NW 7.0 Installation getting jurisdiction policy error

    I am getting the error below when installing my 7.0 Portal on an AIX server.
    Do I simply update the local policy and US export files? The install did not prompt for these files, only the local java path:
    i.e. java14_64 path
    aused by: java.lang.ExceptionInInitializerError
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:218)
            at javax.crypto.Cipher.a(Unknown Source)
            at javax.crypto.Cipher.getInstance(Unknown Source)
            at iaik.security.provider.IAIK.a(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at iaik.security.provider.IAIK.addAsJDK14Provider(Unknown Source)
            at com.sap.security.core.server.secstorefs.Crypt.<clinit>(Crypt.java:82)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            at com.sap.security.core.server.secstorefs.SecStoreFS.setSID(SecStoreFS.java:158)
            at com.sap.security.core.server.secstorefs.SecStoreFS.handleCreate(SecStoreFS.java:804)
            at com.sap.security.core.server.secstorefs.SecStoreFS.main(SecStoreFS.java:1274)
            ... 6 more
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
            at javax.crypto.b.<clinit>(Unknown Source)
            at java.lang.J9VMInternals.initializeImpl(Native Method)
            at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
            ... 17 more
    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.a(Unknown Source)
            at javax.crypto.b.access$600(Unknown Source)
            at javax.crypto.b$0.run(Unknown Source)
            at java.security.AccessController.doPrivileged(AccessController.java:246)
            ... 20 more.).
    Thanks
    Weyland Yutani

    Hello Weyland,
    Usually this error occurs because the JDK policy files are not correct.
    Therefore, please check SAP Note 739043 for further details about this.
    regards,
    Paul

Maybe you are looking for