Andrew, Thanks for your reply, I'm not sure if this is SSL related because the server was working fine after the power outage we had last week. It's just that this issue erupted only today after we moved the servers offsite following after the outage. We are not using any CAS client on one of the application, it's a java hack that our developers did to integrate our software and the other application that we use with cas is wiki and that as well we did a hack and it's using phpCAS, other than that I'm just puzzled by the whole thing. So both applications are failing to authenticate.
Thanks Serge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Petro Sent: Wednesday, November 21, 2007 1:04 AM To: Yale CAS mailing list Subject: Re: HELP Needed urgently- CAS no longer authenticating for prod serverafter server move Serge, The error you report could be caused by a bad SSL certificate on the CAS server, or by the client applications otherwise failing to trust the SSL certificate presented by the CAS server (e.g., improperly installed cert). It could be caused by the client application boxes resolving via DNS (or a hosts file) servers other than the ones you think they're resolving. Exactly what version of the Java CAS Client are you using? If you aren't using 2.1.1, dropping it in *might* get you slightly better error messaging, though that's a stretch. Exactly what configuration do you have in your web.xml configuring the CASFilter? In particular, are the client filters properly configured such that the service= value they present at cas/login and at cas/serviceValidate are the same? The stack traces you post look "sanitized", with domain names replaced to protect the innocent. That's fine, but that does mean that I can't tell whether *that's* the problem. The Java CAS Client, especially in its 2.1.1 version, included a fair amount of Commons Logging statements. Do you have a logger configured? Can you crank it up to TRACE level? Does it report anything helpful? Much to its detriment, the Yale Java CAS client code tends to obscure the underlying cause of error when it generates this "Unable to validate ProxyTicketValidator" message. That's probably my fault. That should be fixed, even as a tiny tactical change to Yale Java CAS Client 2.1.1 for release as a 2.1.1.1... Andrew Andrew Petro Unicon, Inc. Serge Bianda wrote: > We had a power outage in our building, so we decided to move our servers > offsite (Kerberos server (AD)and CAS Server as well). We changed IP > addresses and updated all DNS entries, however when we try to log into > the site that used to be authenticated by CAS, we get the following > error: > > ------------------------------------------------------------------------ > - > HTTP Status 500 - > > type Exception report > > message > > description The server encountered an internal error () that prevented > it from fulfilling this request. > > exception > > javax.servlet.ServletException: Unable to validate ProxyTicketValidator > [[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null] > [edu.yale.its.tp.cas.client.ServiceTicketValidator > casValidateUrl=[https://login.domainname.com/cas/serviceValidate] > ticket=[ST-48-sKW5zzvf0SMiXRGNnqdu] > service=[https%3A%2F%2Fintranet.domainname.com%2Fsuite%2Fportal%2Fssodet > ect.do] renew=false]]] > > edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:381) > > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte > r.java:81) > > root cause > > edu.yale.its.tp.cas.client.CASAuthenticationException: Unable to > validate ProxyTicketValidator > [[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null] > [edu.yale.its.tp.cas.client.ServiceTicketValidator > casValidateUrl=[https://login.domainname.com/cas/serviceValidate] > ticket=[ST-48-sKW5zzvf0SMiXRGNnqdu] > service=[https%3A%2F%2Fintranet.domainname.com%2Fsuite%2Fportal%2Fssodet > ect.do] renew=false]]] > > edu.yale.its.tp.cas.client.CASReceipt.getReceipt(CASReceipt.java:52) > > edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilt > er.java:455) > > edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:378) > > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte > r.java:81) > > note The full stack trace of the root cause is available in the Apache > Tomcat/5.5.9 logs. > ------------------------------------------ > We're still on 2.0.12 with CAS and it's been working fine until the > move, we had planned on upgrading, but now is not the time to focus on > upgrade, we need the site up first. > > Thanks > > > Serge > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
