Your suspicion of the certificate is probably the leading candidate at the moment. We're using self-signed certs, though they're from an internal root CA that all of our systems have in their keystore, so it should be trusted, I believe. Any suggestions on where I would try to track down a possible cert issue? (The certs on the CAS server and JIRA server were both generated with that same root. The browser also has that root, as well as the CAS and JIRA server certs imported into it. I'm not sure where else to check.)
I've checked and re-checked the CAS URLs specified in web.xml and seraph-config.xml, and all 3 of them (casServerUrlPrefix in web.xml), (login.url and link.login.url in seraph-config.xml) are good. (I've copied each of the values from the respective files and pasted them in to a browser to be sure that I didn't have any fat-finger issues - they all point to valid, functioning URLs). I've also confirmed that the https://[MyCasServer]/cas/proxyValidate URL is valid.) I monitored the process via WebScarab to see if there is anything going on there, but from what I can determine, all looks fine - I see the initial JIRA request, the redirect to the CAS server with the service param, the form POST and the redirect back to JIRA with the ticket. The piece I seem to be not seeing is the call to proxyValidate, which I presume happens server-to-server during the filter process? At any rate, if there is any additional direction that can be provided, I'd be much indebted. Thanks, Jim -- View this message in context: http://www.nabble.com/JA-SIG-CAS-Client-and-JIRA-tp20959030p21155729.html Sent from the CAS Users mailing list archive at Nabble.com. _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
