OC4J - cryptography - Sun JCE: is it compliant?

Hello,
I need to determine if I can use Java Cryptography Extension 1.2.1 with OC4J >>standalone<<< in the following environment:
- MS Windows 2000 Professional
- JDK 1.3.1
- Oracle 9iAS 1.0.2.2.1 and its OC4J module
By reading other posted messages, it seems that this J2SE optional package can't run properly.
I've installed the following packages in my %JAVA_HOME%/jre/lib/ext dir:
- jce1_2_1.jar
- sunjce_provider.jar
- local_policy.jar
- US_export_policy.jar
but when I try to encrypt through >>>JavaServerPages<<< in OC4J standalone, I get the following error message:
java.lang.ExceptionInInitializerError: java.lang.SecurityException: Cannot set up certs for trusted CAs
     at javax.crypto.b.<clinit>([DashoPro-V1.2-120198])
     at javax.crypto.Cipher.getInstance([DashoPro-V1.2-120198]))
     at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.JSPServlet.service(JSPServlet.java:31)
     at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:508
I also double checked the java.security file with the following line:
security.provider.1=com.sun.crypto.provider.SunJCE
1) Is it a proper environment for implementing Sun encryption features (JDK, OC4J versions)?
2) Can I run OC4J standalone or do I have to combine it with Oracle 9iAS http server (SSL needed?) ?
3) Do I have to check some forgotten tricky parameters?
4) Is there any alternative/recommended configuration/upgrade?
Any prompt reply will be greatly appreciated!
Thanks in advance,
Donato Di Croce

My point is, you don't know what mode/padding either end is using. You do know (or at least should strongly suspect) that the defaults don't match.
Another hint: "Given block is not mutiple of 8". That implies to me that whichever side is returning that error, isn't padding AT ALL. The whole point to padding is to fill the last block FOR YOU, so you don't have to pre-block your plaintext to match the blocksize of the algorithm.
When you happen to transmit exactly the right-sized output, no padding gets used on either side, and it All Just Works. The other 7/8's of the time, padding is used on one side but not the other, and things DON'T work. That, at least, would be my guess.
I gave up using the defaults for algorithms for this very reason - you never know what the developer of your crypto-lib decided was the "most reasonable" set of options. Always specify algorithm/node/padding, and you won't have to guess anymore...
Grant

Similar Messages

Sun JCE Vs. IBM JCE

How do I make use of Sun JCE in Websphere environment, where it enforces the use of IBM JCE. I had coded the crypting section using Sun JCE when the application was deployed in Tomcat. Now I am planning to move the same to Websphere.

This is being fixed by supplying the Sun JCE jar as a resource in the lib of the web application. The problem was, IBM websphere does use its own internal JDK that support IBM JCE and I don't know how to configure this to point to an external Jdk1.4 installation for default cryptography support. So, when the decryption/encryption task comes up, it ends up with an exception. Now, we are supplying the Sun JCE as part of the lib which is used to read the secret key file and rest is taken care of by IBM JCE. We are using DESkey. Thanks for the valuable input Grant. Still, I am not sure whether we can configure WSAD to point to an external jdk installation.

Unable to locate unrestricted policy files for the Sun JCE for download

My platform:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Oracle JRockit(R) (build R28.1.4-7-144370-1.6.0_26-20110617-2130-windows-x86_64, compiled mode)
I am unable to locate the Unlimited Strength Jurisdiction JCE files.
According to BouncyCastle for Java 1.6:
..."you must download the unrestricted policy files for the Sun JCE if you want the provider to work properly. The policy files can be found at the same place as the JDK download. Further information on this can be found in the Sun documentation on the JCE."

The version at the very bottom of http://www.oracle.com/technetwork/java/javase/downloads/index.html should work.

How to start OC4J in Sun Solaris???

How to start OC4J in Sun Solaris???

It's very simple, you go to the OBIEE documentation page:
http://download.oracle.com/docs/cd/E10415_01/doc/nav/portal_booklist.htm
And you download the Infrastructure Installation and Configuration Guide. You then read it and get to the section where if talks about Starting and Stopping the OC4J Process.

Sun jce pkcs7 data encryption

Hi,
I want to be able to generate a pkcs7 with encrypted data. The data is encrypted using 3DES and the symmetric keys used are encrypted with RSA in the PKCS7.
I tried to do it with Sun jce but I can only encrypt the file with either RSA or symmetric keys.
I'm using sun jdk 1.5 as the former ones didn't seem to have RSA encryption included in them.
I know that you can do it with other providers but I'd like to do it with the sun JCE.
Anyone has an idea ?
thanks
regards

My point is, you don't know what mode/padding either end is using. You do know (or at least should strongly suspect) that the defaults don't match.
Another hint: "Given block is not mutiple of 8". That implies to me that whichever side is returning that error, isn't padding AT ALL. The whole point to padding is to fill the last block FOR YOU, so you don't have to pre-block your plaintext to match the blocksize of the algorithm.
When you happen to transmit exactly the right-sized output, no padding gets used on either side, and it All Just Works. The other 7/8's of the time, padding is used on one side but not the other, and things DON'T work. That, at least, would be my guess.
I gave up using the defaults for algorithms for this very reason - you never know what the developer of your crypto-lib decided was the "most reasonable" set of options. Always specify algorithm/node/padding, and you won't have to guess anymore...
Grant

Are JSSE or JCE FIPS 140 compliant ?

I have looked throught as much documentation as I can handle trying to find out if these packages are FIPS 140 compliant. I cannot find anything. I have looked at the web page http://csrc.nist.gov/cryptval/140-1/140val-all.htm and do not see anything from Sun as being approved. This is unfortunate and suprising to me that Sun has not put their own code through the approval process. Therefore I am unable to use the JSSE and JCE, and must use RSA BSAFE, which costs a fortune.
Can anyone shed some light on this topic.
...Thank you.
Mark

I looked into this issue extensively last fall as we have a requirement
to use a NIST certified encryption algorithm. At that time, the
descriptions of Cert#s 247 & 248 in the table at
http://csrc.nist.gov/cryptval/140-1/140val-all.htm looked very
different. In fact, a reference to
http://www.mozilla.org/projects/security/pki/nss/ appeared in the
description as a means of obtaining a copy of NSS. I downloaded a
version of NSS and attempted to use it (along with the JSS package
also available at the mozilla site). After experimenting with NSS and
JSS for some time, I just could not get it to work (can't recall now
exactly what the issues were at that time).
We abandoned the NSS approach with the expectation of obtaining a
temporary exemption of this requirement; however, this requirement has
now come full circle and is back on my plate. If we have to purchase
a third-party tool, so be it; however, it would sure be nice to hear
from the source exactly what, if anything, is occurring with regards
to NIST certification. Thanks.
-Mark
I have looked throught as much documentation as I can
handle trying to find out if these packages are FIPS
140 compliant. I cannot find anything. I have looked
at the web page
http://csrc.nist.gov/cryptval/140-1/140val-all.htm and
do not see anything from Sun as being approved. This
is unfortunate and suprising to me that Sun has not
put their own code through the approval process.
Therefore I am unable to use the JSSE and JCE, and
must use RSA BSAFE, which costs a fortune.
Can anyone shed some light on this topic.
...Thank you.
Mark

Having Trouble with Java Cryptography Extension (JCE)

Hi, this is my first attempt at using the JCE. I'm using JCE 1.2.1
and basically all I'm trying to do at this point is encrypt a
FileInputStream object using the DES standard, with the JCE
classes. Here is my code Fragment.
protected FileOutputStream encriptFile(FileInputStream baseFile,
File encFileName) throws IOException
try
// Create the output file for the encrypted document
FileOutputStream encriptedFile = new FileOutputStream
(encFileName);
// Must register the provider that implements the algorithm
Provider sunJce = new com.sun.crypto.provider.SunJCE();
Security.addProvider(sunJce);
char[] pbeKeyData = password.toCharArray();
PBEKeySpec pbeKeySpec = new PBEKeySpec(pbeKeyData);
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance
("DES");
SecretKey pbeKey = keyFactory.generateSecret(pbeKeySpec);
Cipher pbe = Cipher.getInstance("DES"); // Same as above.
pbe.init(Cipher.ENCRYPT_MODE, pbeKey);
CipherOutputStream cout = new CipherOutputStream
(encriptedFile, pbe);
// Use a byte array to write the file output in blocks of 64
bytes.
byte[] buffer = new byte[64];
while (true)
int bytesRead = -1;
bytesRead = baseFile.read(buffer);
if (bytesRead == -1) break;
cout.write(buffer, 0, bytesRead);
cout.flush();
cout.close();
baseFile.close(); // Close the input file.
catch (java.security.NoSuchAlgorithmException nsA)
System.err.println(nsA);
nsA.printStackTrace();
catch (java.lang.ExceptionInInitializerError eIIE)
System.err.println(eIIE);
eIIE.printStackTrace();
catch (Exception e)
System.err.println(e);
e.printStackTrace();
My problem arises with the line "SecretKeyFactory keyFactory =
SecretKeyFactory.getInstance("DES");" This line throws an
ExceptionInInitializerError and the catch block tells me this
java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError: java.lang.SecurityException:
Cannot set up certs for trusted CAs
(The rst of the stackCall here)...
From what I've read in the documentation, I need to have a provider
set up that handles the SecretKeyFactory and encryption algorithms,
but the documentation also says that the SunJCE provider that I set
up near the start of my method should have been able to handle this.
Is there anyone out there with expeience doing this kind of thing
that can help.
Thanks,
Dan

Please check out the following:
1. Be sure that the jar file will be viewable from classpath and that the provider you want to use will be in java.security file.
2. In the java.security file you should have something like this:
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.crypto.provider.SunJCE
3. If you wish, you can test your program with another JCE implementation, like cryptix.
You can download the api and documentation of cryptix at http://www.cryptix.org/products/index.html
I wish this can be useful to you!!!
Thank you for some duke dollars.

Verisign Payflow PRo and Sun JCE

We have been trying to integrate verisign's payflow pro java APIs for credit card processing. THe integration works fine when run directly from a unit test, but fails when it is run inside the weblogic server.
As an FYI -
The sunJCE provider is specifically unloaded by WebLogic Server if it is found to be registered statically. If you require the sunJCE provider, load it dynamically.
Add --
java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
java.security.Security.addProvider(new com.sun.crypto.provider.SunJCE() );
to your class to fix the problem

OK, I restarted my client with the original verisign.ini file dropped back in and Voila, it works.
I really wanted to change my password to a more secure/stronger password so I'm still back to square one.
Any suggestions where the password needs to be changed besides the verisign.ini file Gordon?
In addition, I don't know why the verisign.ini file adds a 'JP' to the end of the password which appears scrambled by the way.

Distributing software with unlimited strength JCE policy files

I'm about to release some software that uses AES 256-bit encryption. I had to download the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6" to do this level of encryption. I'd like to distribute my software with a bundled version of the JRE that includes these policy files. The software will be available to download from the Internet for those who pay for the service. Placing it on the Internet is technically an export because it's available to anyone in the world.
I've talked to the Bureau of Industry and Security and they said I need to file for a classification number (ECCN). Is this necessary if I'm using Sun's software? The JCE has already been through the export approval process so it would make sense if just including it in my software required nothing. I haven't been able to find any information about what to do legally if using the unlimited strength policy files. What laws do I need to know about or comply with to do this? Also, are there any legal ramifications of including the JRE with my software? I'm using a custom jre launcher that lets me bundle whatever jre I want with my software, so I assume it's a common practice, but I'm not sure.
Any help would be appreciated.

I posted this question on other sites as well, but never heard any good answers.
I've had to do some research and I've heard a few different things, but this is what I've learned:
Software being exported (putting on the Internet is an export) that contains symmetric encryption above 64-bit requires filling out a BIS-748P form. I had to first of all request a PIN and CIN (company id number) from the BIS so that I can access their SNAP-R system which is where you fill out and submit all the paper work (including the BIS-748P) online. I haven't filled that out yet, but once you do they will review your software and classify it with an ECCN number and depending on what if falls under they will require you to obtain a license or license exception. For what I'm doing (and what most probably need this for), a license is not needed. It's simply classified as a type of encryption software and they know who you are and what you're doing with it.
Until this is filed, the software is under a certain statute as to what you can do with it and there's a lot of legalities behind this entire process that I don't fully understand, but I think filling this paperwork out and talking to those who receive it is a good place to start.
I'm not a lawyer by any means and I could be missing some details, but this is what I understand about the process. If you learn anything else (or find some of this to be untrue), let me know.

JCE Jurisdiction does not allow Portal to start

Hi,
I've a EP 6.0 SP9 on WAS 6.40. Someone has moved JDK files and I've to re-install full JDK. Now when I try to restart the Portal the message serve and enqueue server come up but the dispatcher,server,sdm part fails. I check for the logs and in bootstrap log I found the following error.
Java#com.sap.sql.connect_1221#com.sap.sql.log.OpenSQLResourceBundle#Error while accessing secure store: .#1#Encryption or decryption is not possible because the full version of the SAP Java Crypto Toolkit was not found (iaik_jce.jar is required, iaik_jce_export.jar is not sufficient) or the JCE Jurisdiction Policy Files don't allow the use of the "PbeWithSHAAnd3_KeyTripleDES_CBC" algorithm.#
I found the iaik files in place.
Please let me know how to resolve this.
Regards,
Siva

Hi Siva,
looks to me like your UME Configuration is set to store the user mapping data with strong encryption and you have forgot to install the unlimited strength jurisdiction policy files.
If you want to check if this is the case you can disable password encryption for the mapped data by setting the value of the UME property ume.usermapping.unsecure to FALSE and retry starting the server. You change the setting using the Config Tool: http://help.sap.com/saphelp_nw04/helpdata/en/0b/50ad3e1d1edc61e10000000a114084/frameset.htm
To check if the correct policy files are installed you go to $JAVA_HOME/lib/security and take a look at the local_policy.jar and us_export_policy.jar files in there. Compare them with the files from
http://java.sun.com/j2se/1.4.2/download.html -> "Java(TM) Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 1.4.2" -> Download
If the files differ, replace your existing ones with the downloaded ones.
Hope this helps,
Robert

How do i place JCE in Java?

Hello to all :)
I have to make a symmetric algorithm in Java and i need to have these three stuff in it
1) Sun Java Cryptography Extension (JCE)
2) JCE Unlimited Strength Jurisdiction Policy
3) Bouncycastle Provider
cause i need the packages
javax.crypto.*
java.security.*
what shall i download from the internet in order to have them and how do i place them in my region?
Thanks, in advance!

Thanks for replying!
Well i haven't downloaded anything from the internet.
I have a region(login session -unix) in my university where the Java is already in, but the JCE is not included in it cause when i tried to make a simple problem using import javax.crypto.* and java.security.* i had some warnings saying that these are not used referring to these two imports, so maybe JCE is not in.
So, where shall i download this JCE and how shall i place it in my region and in which folder?
I'm sorry for my questions but i'm new at Java and i don't know how to fix the system for running my exercises :)

How to refer the unlimited key length JCE jar files.

Hi All,
The JDK 1.4.2_10 contains the local_policy.jar and US_export_policy.jar that do not permit an unlimited Key length( 64 bit).
- So I downloaded the unlimited ( Java(TM) Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 1.4.2
) https://jsecom15d.sun.com/ECom/EComActionServlet;jsessionid=0F59ACFF95A61F6C0E78B5CE8E0FA93B.
-Now I want JDK to refer these files without changing anything in existing JDK ( Means I don't want to replcae the existing local_policy.jar , US_export_policy.jar ).
- Is there any option or property which can tell the JDK to refer the other
files instead of this location :- C:\bea\WLS8.1SP04\jdk142_05\jre\lib\security.
Means I want to override these 2 existing files local_policy.jar , US_export_policy.jar without replcaing them.
Any pointers will be highly appreciated.

A year later, this is still an issue. No replies ( btw, this is my new login name for the forums ).
Thank You.

Attn: Sun. Can we distribute the JRE with a program we write?

I'm trying to find out whether it's legal to distribute the JRE with a program I write. If you look at the license agreement when you download the JRE, first it has the regular license agreement, which says that you can't. But then it has the "supplemental" license agreement (and it says that this "modifies" the regular license agreement). In section 2 of the supplemental license agreement, it quite clearly states that you can as long as you don't modify it and you include some little messages in your documentation.
So I'm hoping to get an answer from someone who actually works for Sun. It seems pretty clear to me that we ARE allowed to distribute the JRE with a program, but people keep sending me emails when I tell them about it - saying things like "You can't program in Java because you can't distribute it."
What I want to do is have an installation program that installs my game and then installs Java (with Sun's JRE installer - this is included ONLY so that it can run my game, as stated in the supplemental license agreement). I should also mention that I do actually intend to SELL this program, so if that's a problem, please say so. Anyways, could someone from Sun tell me whether this is allowed or not? I don't want to break the law.
- Steve Fletcher

The JRE includes a readme file that explicitly states that distribution is permissible, given certain conditions. In particular, look at the 1st paragraph below:
Reproduced here:
README
Java(TM) 2 Runtime Environment, Standard Edition
Version 1.4.1
The Java(TM) 2 Runtime Environment is intended for software developers
and vendors to redistribute with their applications.
The Java 2 Runtime Environment contains the Java virtual machine,
runtime class libraries, and Java application launcher that are
necessary to run programs written in the Java programming language.
It is not a development environment and does not contain development
tools such as compilers or debuggers. For development tools, see the
Java 2 SDK, Standard Edition.
=======================================================================
Deploying Applications with the Java 2 Runtime Environment
=======================================================================
When you deploy an application written in the Java programming
language, your software bundle will probably consist of the following
parts:
Your own class, resource, and data files.
A runtime environment.
An installation procedure or program.
You already have the first part, of course. The remainder of this
document covers the other two parts. See also the Notes for Developers
page on the Java Software website:
http://java.sun.com/j2se/1.4.1/runtime.html
Runtime Environment
To run your application, a user needs the Java 2 Runtime Environment,
which is freely available from Sun for application developers to
redistribute.
The final step in the deployment process occurs when the software is
installed on individual user system. Installation consists of copying
software onto the user's system, then configuring the user's system
to support that software. You should ensure that your installation
procedure does not overwrite existing JRE installations, as they may
be required by other applications.
=======================================================================
Redistribution of the Java 2 Runtime Environment
=======================================================================
The term "vendors" used here refers to licensees, developers, and
independent software vendors (ISVs) who license and distribute the
Java 2 Runtime Environment with their programs.
Vendors must follow the terms of the Java 2 Runtime Environment Binary
Code License agreement.
Required vs. Optional Files
The files that make up the Java 2 Runtime Environment are divided into
two categories: required and optional. Optional files may be excluded
from redistributions of the Java 2 Runtime Environment at the
licensee's discretion.
The following section contains a list of the files and directories that
may optionally be omitted from redistributions with the Java 2 Runtime
Environment. All files not in these lists of optional files must be
included in redistributions of the runtime environment.
Optional Files and Directories
The following files may be optionally excluded from redistributions:
lib/charsets.jar
Character conversion classes
jre/lib/ext/
sunjce_provider.jar - the SunJCE provider for Java
Cryptography APIs
localedata.jar - contains many of the resources
needed for non US English locales
ldapsec.jar - contains security features supported
by the LDAP service provider
dnsns.jar - for the InetAddress wrapper of JNDI DNS provider
bin/rmid
Java RMI Activation System Daemon
bin/rmiregistry
Java Remote Object Registry
bin/tnameserv
Java IDL Name Server
bin/keytool
Key and Certificate Management Tool
bin/kinit and jre/bin/kinit
Used to obtain and cache Kerberos ticket-granting tickets
bin/klist and jre/bin/klist
Kerberos display entries in credentials cache and keytab
bin/ktab and jre/bin/ktab
Kerberos key table manager
bin/policytool
Policy File Creation and Management Tool
bin/orbd
Object Request Broker Daemon
bin/servertool
Java IDL Server Tool
In addition, the Java Web Start product may be excluded from
redistributions. Depending on the platform, the Java Web Start
product is contained in a file named as follows. The actual
product version number would replace the <version number> notation.
javaws-<version number>-solaris-sparc-i.zip
javaws-<version number>-solaris-i586-i.zip
javaws-<version number>-linux-i586-i.zip
javaws-<version number>-windows-i586-i.exe
Redistribution of Java 2 SDK Files
The limited set of files from the SDK listed below may be included in
vendor redistributions of the Java 2 Runtime Environment. All paths
are relative to the top-level directory of the SDK.
- jre/lib/cmm/PYCC.pf
Color profile. This file is required only if one wishes to
convert between the PYCC color space and another color space.
- All .ttf font files in the jre/lib/fonts directory. Note that the
LucidaSansRegular.ttf font is already contained in the Java 2
Runtime Environment, so there is no need to bring that file over
from the SDK.
- jre/lib/audio/soundbank.gm
This MIDI soundbank is present in the Java 2 SDK, but it has
been removed from the Java 2 Runtime Environment in order to
reduce the size of the Runtime Environment's download bundle.
However, a soundbank file is necessary for MIDI playback, and
therefore the SDK's soundbank.gm file may be included in
redistributions of the Runtime Environment at the vendor's
discretion. Several versions of enhanced MIDI soundbanks are
available from the Java Sound web site:
http://java.sun.com/products/java-media/sound/
These alternative soundbanks may be included in redistributions
of the Java 2 Runtime Environment.
- The javac bytecode compiler, consisting of the following files:
bin/javac [Solaris(TM) Operating Environment
and Linux]
bin/sparcv9/javac [Solaris Operating Environment
(SPARC(TM) Platform Edition)]
bin/javac.exe [Microsoft Windows]
lib/tools.jar [All platforms]
- jre\bin\server\
On Microsoft Windows platforms, the Java 2 SDK includes both
the Java HotSpot Server VM and Java HotSpot Client VM. However,
the Java 2 Runtime Environment for Microsoft Windows platforms
includes only the Java HotSpot Client VM. Those wishing to use
the Java HotSpot Server VM with the Java 2 Runtime Environment
may copy the SDK's jre\bin\server folder to a bin\server
directory in the Java Runtime Environment. Software vendors may
redistribute the Java HotSpot Server VM with their
redistributions of the Java Runtime Environment.
Unlimited Strength Java Cryptography Extension
Due to import control restrictions for some countries, the Java
Cryptography Extension (JCE) policy files shipped with the Java 2 SDK,
Standard Edition and the Java 2 Runtime Environment allow strong but
limited cryptography to be used. These files are located at:
<java-home>/lib/security/local_policy.jar
<java-home>lib/security/US_export_policy.jar
where <java-home> is the jre directory of the Java 2 SDK or the
top-level directory of the Java 2 Runtime Environment.
An unlimited strength version of these files indicating no restrictions
on cryptographic strengths is available on the Java 2 SDK web site for
those living in eligible countries. Those living in eligible countries
may download the unlimited strength version and replace the strong
cryptography jar files with the unlimited strength files.
Endorsed Standards Override Mechanism
An endorsed standard is a Java API defined through a standards
process other than the Java Community Process(SM) (JCP(SM)). Because
endorsed standards are defined outside the JCP, it is anticipated that
such standards will be revised between releases of the Java 2
Platform. In order to take advantage of new revisions to endorsed
standards, developers and software vendors may use the Endorsed
Standards Override Mechanism to provide newer versions of an endorsed
standard than those included in the Java 2 Platform as released by Sun
Microsystems.
For more information on the Endorsed Standards Override Mechanism,
including the list of platform packages that it may be used to
override, see
http://java.sun.com/j2se/1.4.1/docs/guide/standards/
Classes in the packages listed on that web page may be replaced only
by classes implementing a more recent version of the API as defined
by the appropriate standards body.
In addition to the packages listed in the document at the above
URL, which are part of the Java 2 Platform, Standard Edition
(J2SE(TM)) specification, redistributors of Sun's J2SE
Reference Implementation are allowed to override classes whose
sole purpose is to implement the functionality provided by
public APIs defined in these Endorsed Standards packages.
Redistributors may also override classes in the org.w3c.dom.*
packages, or other classes whose sole purpose is to implement
these APIs.
Copyright 2003 Sun Microsystems, Inc., 4150 Network Circle,
Santa Clara, California 95054, U.S.A. All rights reserved

Error during Installation - CE 7.2 - JCE

Hello experts,
I am trying to install NW CE 7.2 on Windows Vista.
When i try to select Java Cryptography Extension (JCE) policy jar files, i get an error stating "Invalid Zip file"
i have downloaded JCE files according to the note 1240081 given by SAP
Any pointers regarding this will be useful.
Regards,
Vivek
Edited by: Vivek D K on Mar 3, 2010 1:12 PM

Hi
Try this one
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=jce_policy-6-oth-JPR@CDS-CDS_Developer
BR
Satish Kumar

Installing JCE 1.2.2 in J2SE 1.3.1 enviroment

In response to an issue involving APC Powerchute 6 on a Windows 2000 server, we are attempting to follow the recommendation provided below. However, after downloading Java Cryptography Extension (JCE) 1.2.2 and unzipping the package, I cannot follow the instructions for installing the new JCE. Can someone please dummy the instructions down for me?
-Michael
Heads up about APC software and Servers stuck on applying computer settings
Posted on Thursday, July 28, 2005 4:52 PM
In order for PowerChute Business Edition to remain functional, users must
upgrade to any version of 7.x. Due to expiration of the Sun Java Runtime
Environment certificate, versions 6.x of PowerChute Business Edition will
cease to operate normally as of July 27, 2005. Failure to upgrade will
result in PowerChute Business Edition no longer providing monitoring and
************READ THIS CAREFULLY THIS SAYS THAT YOU DO NOT NEED TO RESTART THE COMPUTER*****************
After lengthy reasearch by an associate, here is the problem and the fix:
I researched the Microsoft and APC (and SUN) site and found the REAL cause of the problem.
Here it is:
1. Impact
The Java Cryptography Extension (JCE) 1.2.1 is an optional package for J2SE 1.2.x and 1.3.x that provides a framework and implementations for encryption, key generation, key agreement, and Message Authentication Code (MAC) algorithms. The digital certificate that was used to sign the JCE 1.2.1 jar files will expire on July 27, 2005, after which the product will no longer function.
2. Contributing Factors
This issue can occur in the following release:
Java Cryptography Extension (JCE) 1.2.1 (for J2SE 1.2.x and 1.3.x)
Notes:
JCE 1.2.1 is at "End of Service Life" (EOSL), and is no longer supported. JCE 1.2.1 was EOSL'ed in 2002 when JCE 1.2.2 was released.
The JCE that is integrated into J2SE 1.4 and later is not affected by this issue. This Sun Alert is specific to JCE 1.2.1, which is an optional package for use with J2SE 1.2.x. and 1.3.x (JCE 1.2.1 is not bundled with J2SE 1.2.x and 1.3.x).
3. Symptoms
After the expiration date, code calling into JCE 1.2.1 will fail with symptoms similar to the following:
[xxxxxx@xxxxxx] 258 >java BlowfishKey
Exception in thread "main" java.lang.ExceptionInInitializerError:
java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.b.<clinit>([DashoPro-V1.2-120198])
at javax.crypto.KeyGenerator.getInstance([DashoPro-V1.2-120198] )
Solution Summary Top
4. Relief/Workaround
There is no workaround. Please see the "Resolution" section below.
5. Resolution
This issue is addressed in the following releases:
Java Cryptography Extension (JCE) 1.2.2 (for J2SE 1.2.x and 1.3.x)
which is available at:
http://java.sun.com/products/jce/index-122.html
JCE in J2SE 1.4 and later
which is available at:
http://java.sun.com/j2se/1.4.2/download.html and http://java.sun.com/j2se/1.5.0/download.jsp

Hi Shakee,
go here http://java.sun.com/j2se/1.4.2/download.html
scroll down, load the unlimited strength jce package and read the instructions (you just have to replace some jars in your filesystem)
good luck,
sebastian

OC4J - cryptography - Sun JCE: is it compliant?

Similar Messages

Maybe you are looking for