James and Sun JSSE

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

I'm forwarding to the user list (adding some comments) a message that Serge and myself received from Brad Wetmore of Sun, as it may be of 
general interest.

As Brad says, *under Sun jdk/jre 1.4.2* everything works (I tested it - under james 2.2.0, never tried under james 2.1.*) using 
sunjce_provider.jar. But we need to put it in <james-instdir>/lib, not in <java-home>/lib/ext/sunjce_provider.jar nor in 
<james-instdir>/apps/james/SAR-INF/lib. The SunJCE provider must also be registered with the Security class either statically (in 
<java-home>/lib/security/java.security - it's there by default in jdk/jre 1.4+) or dynamically. I will update the wiki page: thank you Brad.

But this will help only those users running under jdk/jre 1.4.2+. The others will need a different provider, (I like myself the Bouncy 
Castle stuff, but others are welcome).

We have also to remember (see http://www.bouncycastle.org/latest_releases.html) that the setup of the Bouncy Castle stuff is dependent on 
the jdk/jre release: there are different jars for 1.3, 1.4 and *1.5*, so (unless I'm missing something) probably we cannot bundle their 
provider jars, because we would remain stuck to a specific java release (are they back compatible? We should ask). Moreover jdk/jre 1.3 
requires their JCE jar.

I think in any case that we should at least require jdk/jre 1.4.2+ (not just 1.4+) for the future James releases, to simplify the life for 
everybody.

Something we could do to help installers is to dynamically register some providers in the James startup code, based on a new entry in 
config.xml, with a "provided" default set of providers (Sun and Bouncy Castle IMHO) that can be changed if needed by the James 
administrator. I can look at this - just give me an OK.

Any comments?

Vincenzo

-------- Original Message --------
Subject: James and Sun JSSE.
Date: Thu, 15 Jul 2004 16:02:31 -0700
From: Brad Wetmore <Br...@Sun.COM>
To: sergek@lokitech.com, vincenzo.gianferraripini@praxis.it
CC: Christian Eyrich <ch...@gmx.net>


Hi Serge/Vincenzo,

I work at Sun, and one of your James users contacted me about a JSSE bug
that James users are encountering.

If you're not the right people to be talking to, please forward as
appropriate, but it looked like you might be in positions to help.  I
found your names in:

http://marc.theaimsgroup.com/?l=james-user&m=108870153132339&w=2

Christian Eyrich (cc'ing him on this email) wrote:

>>Hm, I guess I overlooked one existing bug there. I just found it and it
>>has some recently added comments on it: see
>>http://nagoya.apache.org/jira/browse/JAMES-301

>At least for me it's quite irritating - maybe they just work around a
>James-Bug by adding this Bouncycastle lib. But maybe you can find
>something enlighting there.

What it comes down to is the following:

In Sun JDK 1.4.1 and above, if you install a JCE provider before the
JSSE provider, JSSE will use the crypto implementations from that
provider before using it's internal algorithms.

In Sun's JDK 1.4.2, we support the AES cipher suites, but we require the
JCE environment to provide the AES cipher.  Normally, in a Sun 1.4.2 JDK
distribution, this AES comes from the SunJCE provider, which normally
coexists with JSSE/JCE in the standard Sun JDK, and is loaded by the
standard extension class loader by looking in the file
<java-home>/lib/ext/sunjce_provider.jar.  (The JSSE and JCE framework
are loaded by the System class loader.)

(Note there was no support for AES cipher or ciphersuites in versions
prior to 1.4.2, or in the unbundled JSSE which ships for JDK's 1.2.x and
1.3.x.)

(Of course, the SunJCE provider must also be registered with the
Security class either statically or dynamically:  by default, it's
registered statically.)

To your problem, for some reason, that SunJCE jar isn't being found
(standard extension ClassLoader isn't being used?), or the provider has
been removed from the list of installed providers, or perhaps something
else.  Whatever is happening, adding the BouncyCastle provider may take
care of the problem, but this means that any of the other SunJCE
algorithms won't be used either.

I'm not saying the Bouncy Castle route is bad, just that there is
probably something unexpected going on here by not finding SunJCE at all.

One last comment, in JDK 1.5, for various reasons, all crypto has been
removed from the JSSE, and we expect the JCE environment to provide all
crypto.  If you can't find SunJCE (or any other crypto libraries), there
may be problems.  You might want to check on this before 1.5 ships.

You can find the latest 1.5.0 snapshot at:

     http://java.sun.com/j2se/1.5.0/snapshots

I hope this clears things up.  I don't know where the problem lies,
perhaps it's rooted in another library you guys use, if so, you might
want to let them know what's going on.

When this gets resolved, you might want to update the references on your
Wiki page as well.

http://wiki.apache.org/james/UsingSSL

Thanks,

Brad


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org