I have a servlet running in WLS81 which accesses a remote HTTPS
server.
When accessing the server directly (no proxy) everything is fine. When
a proxy is configured (via command line: -Dhttps.proxyHost=xxx and
-Dhttps.ProxyPort=xxx) I'm getting a handshake error:
HANDSHAKE_FAILURE - The handshake handler was unable to negotiate an
acceptable set of security parameters.
After turning on SSL debug (-Dssl.debug=true
-Dweblogic.StdoutDebugEnabled=true) I'm seeing multiple
NullPointerException events:
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000> <SSLManager:
loaded 15 trusted CAs from C:\bea\jdk141_03\jre\lib\security\cacerts>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000> <clientInfo
settings applied>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000>
<SSLIOContextTable.findContext(is): 32994287>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000> <write
SSL_20_RECORD>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000>
<24212996readRecord()>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000> <24212996
SSL3/TLS MAC>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000> <24212996
received HANDSHAKE>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000>
<HANDSHAKEMESSAGE: ServerHello>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000>
<HANDSHAKEMESSAGE: Certificate>
<19-Jan-2004 14:04:18 o'clock GMT> <Debug> <TLS> <000000> <Exception
during hand shake, stack trace follows java.lang.NullPointerException
at com.certicom.tls.record.handshake.ClientStateReceivedServerHello.handle(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown
Source)
at com.certicom.tls.record.ReadHandler.interpretContent(UnknownSource)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown
Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown
Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown
Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.java:98)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:288)
at weblogic.net.http.HttpURLConnection.getResponseCode(HttpURLConnection.java:697)
I believe this is caused by a bug in weblogic's protocol stack.
The only successful workaround I've found is to create my own
custom-protocol handler which extends *Sun's* HTTPS handler
(sun.net.www.protocol.https.Handler) but doesn't override any of its
methods:
package com.mycompany.protocol.httpsfix;
public final class Handler extends sun.net.www.protocol.https.Handler
{
public Handler() {}
}
Package the handler into a JAR and install it on the system classpath
(i.e. in the classpath found in startManagedWeblogic.sh script).
Add your protocol package to java's search list by specifying JVM
argument:
-Djava.protocol.handler.pkgs=com.mycompany.protocol
Specify the https proxy in the usual way:
-Dhttps.proxyHost=xxx -Dhttps.proxyPort=xxx
Finally, change the protocol of your URL from https to httpsfix
httpsfix://www.securesite.com/