Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HTTPS via proxy FROM a servlet causes handshake error (weblogic WLS81)

0 views
Skip to first unread message

Mike Williams

unread,
Jan 22, 2004, 7:36:53 AM1/22/04
to
Has anyone successfully accessed a HTTPS URL via a proxy _FROM_ a
weblogic servlet?


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)

Mike Williams

unread,
Feb 6, 2004, 5:19:53 AM2/6/04
to
For the benefit of others facing this problem...

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/

0 new messages