Nice tip M. That is a very verbose trick.
I got the sll debug and I think it all looks fine, then at the very end
I get:
%% Cached client session: [Session-4, TLS_RSA_WITH_AES_128_CBC_SHA]
http-127.0.0.1-8082-1, WRITE: TLSv1 Application Data, length = 352
http-127.0.0.1-8082-1, handling exception: java.net.SocketException:
Connection reset
%% Invalidated: [Session-4, TLS_RSA_WITH_AES_128_CBC_SHA]
http-127.0.0.1-8082-1, SEND TLSv1 ALERT: fatal, description =
unexpected_message
http-127.0.0.1-8082-1, WRITE: TLSv1 Alert, length = 32
http-127.0.0.1-8082-1, Exception sending alert:
java.net.SocketException: Broken pipe
http-127.0.0.1-8082-1, called closeSocket()
http-127.0.0.1-8082-1, called close()
http-127.0.0.1-8082-1, called closeInternal(true)
Mar 13, 2009 10:18:38 AM org.apache.catalina.core.StandardWrapperValve
invoke
SEVERE: Servlet.service() for servlet Login threw exception
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at
com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java
:789)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.
java:746)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at
java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at
java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at
sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec
tion.java:1049)
at
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl.ge
tInputStream(HttpsURLConnectionOldImpl.java:204)
at
edu.yale.its.tp.cas.util.SecureURL.retrieve(SecureURL.java:91)
at
edu.yale.its.tp.cas.client.ServiceTicketValidator.validate(ServiceTicket
Validator.java:218)
at
edu.yale.its.tp.cas.client.CASReceipt.getReceipt(CASReceipt.java:52)
at
edu.yale.its.tp.cas.client.filter.CASValidateFilter.getAuthenticatedUser
(CASValidateFilter.java:393)
at
edu.yale.its.tp.cas.client.filter.CASValidateFilter.doFilter(CASValidate
Filter.java:342)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
86)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
5)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Is that something triggering an SSL bailout right after the client makes
the connection correct?
-perry
-----Original Message-----
From: Marvin Addison [mailto:[email protected]]
Sent: Friday, March 13, 2009 10:11 AM
To: [email protected]
Subject: Re: [cas-user] 505 Exception
> sniffer on the dc/gc sees the initial ldap bind, the search, and the
> success return, so this is something failing in CAS before it hands me
> back off to uportal, not the ldap connection.
I would agree with that analysis based on the stack trace. The
failure appears to happen when the CAS client attempts to connect to
CAS for service ticket validation.
You mentioned this could be related to SSL, but I've not seen this
sort of error caused by SSL trouble. But I would agree that
investigating that a little deeper would be a good first step. I
recommend you produce an SSL trace on the client application
(uPortal?). Assuming you're running tomcat:
1. Create/edit a $TOMCAT_HOME/bin/setenv.sh with the following:
CATALINA_OPTS=$CATALINA_OPTS" -Djavax.net.debug=ssl"
export CATALINA_OPTS
2. Restart the container and attempt to reproduce the problem
3. Examine the file containing the contents of stdout (catalina.out by
default), which should contain the trace
Send the trace to the list if you need help reading/analyzing it.
M
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
