This content has been marked as final. Show 4 replies
As far as I can tell java 1.6.0_18 does not have fix for this issue, even though someone (at Sun?) mentioned that he/she intended to backport the fix into java 1.6.0_18.
I ended up backporting it myself and it resolved the issue for me.
If you have at least mid-level Java programming experience, you should be able to follow these steps:
step 1. Get this file, which has the fix:
and copy it to a local directory (create the directory first !) : channel-fix
step 2. make the following editing changes so that it will compile under java 1.6:
BEFORE: import sun.security.jgss.HttpCaller;
AFTER: import sun.security.jgss.GSSUtil;
BEFORE: if (context.getCaller() instanceof HttpCaller &&
AFTER: if (context.getCaller() == GSSUtil.CALLER_HTTP_NEGOTIATE &&
step 3. compile InitialToken.java using a java 1.6 compiler: javac InitialToken.java
step 4a. locate rt.jar (java runtime library) for the java 1.6 on your server machine (the machine where you're getting the channelbinding exception).
step 4b. make a backup copy of this rt.jar
step 4c. also copy this rt.jar to your local machine, to your channel-fix directory.
step 5. under your channel-fix directory, create the following directory structure: sun/security/jgss/krb5
step 6. copy InitialToken$OverloadedChecksum.class and InitialToken.class (the results of step 3) to this new directory that you just created: (sun/security/jgss/krb5/ )
step 7. copy rt.jar (from step 4) to channel-fix directory.
step 8. go to channel-fix directory and run the following command: jar uvf rt.jar sun
step 9. This version of rt.jar now has the channel binding fix in place. Copy this rt.jar back to the server machine, overwriting the rt.jar that's already there.
Edited by: ginolee on Mar 27, 2010 5:54 AM
Edited by: ginolee on Mar 27, 2010 5:57 AM