Login to CAS failed!

[yinshi]

I, while studying Acegi and CAS; Always present this mistake and does not solve very much
The mistake is as follows:

Your CAS credentials were rejected.

Reason: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderE xception: unable to find valid certification path to requested target

:?: :?:
:!:

[Ben Alex]

Try reading the suggestions in ACEGI_SECURITY/samples/contacts/ssl/howto.txt. The CAS client code needs to perform a request over HTTPS to the CAS server. If the CAS client keystore does not trust the HTTPS certificate presented by the CAS server, you'll get exceptions like this.

[allan.axon]

I've implemented the contacts-cas.war and a CAS server on localhost. I have followed the suggestions in the trouble shooting section of the ssl howto.txt provided with the acegisecurity samples. I still get

Reason: sun.security.validator.ValidatorException: No trusted certificate found

returned after a successful CAS login on return to the original contacts-war resource.

I have tried the contacts-cas example with our "real" CAS server and the one on localhost and I get the same result.

I'm using Tomcat 5.0.18 and I can successfully get to https://localhost/ after accepting the certificate.

I've imported the acegisecurity certificate export file into the JDK cacerts file and I've also set the CasAuthenticationProvider.trustStore to the path to the JDK cacerts file.

Is there another step regarding making sure the certificate is trusted when the contacts-cas and the CAS server are on the same host? If so, what are the steps when you have the CAS server on a different host? BTW, of course all my certificates are self signed now. I can also see some issues when the CAS server is being called through a proxy server when it is "brokering" SSL between a browser and the CAS server.

Thanks,

[Ben Alex]

I'm afraid this is a Java SSL-specific issue (not Acegi Security), so I can't offer much more help. I documented troubleshooting approaches I needed to use in the howto.txt, but as I cannot reproduce your problem I am unable to assist much further. When you find the solution, please post it here or send me an update for the howto.txt.

[allan.axon]

Thanks for your help. After looking more closely at the SSL issues, I've discovered that as long as the CAS server (whether its on localhost or another host) is trusted by the server running the Acegi-protected application, the CAS/Acegi interaction works. This may be such a well-known fact of SSL operation that only SSL-inexperienced users like myself would have this problem. You might change your documentation or readme to remind users of this, but if you don't I'll just say that I've found your examples and documentation to be excellent compared with many open source projects.

[Ben Alex]

I've added the following to the etc/ssl/howto.txt troubleshooting section:

* First of all, most CAS-Acegi Security problems are because of untrusted
SSL certificates. So it's important to understand why. Most people can
load the Acegi Security webapp, get redirected to the CAS server, then
after login they get redirected back to the Acegi Security webapp and
receive a failure. This is because the CAS server redirects to something
like https://server3.company.com/webapp/j_acegi_cas_security_check?ticket=ST-0-ER94xMJmn6pha35CQRoZ
which causes the "service ticket" (the "ticket" parameter) to be validated.
net.sf.acegisecurity.providers.cas.ticketvalidator .CasProxyTicketValidator
performs service ticket validation by delegation to CAS'
ProxyTicketValidator class. The ProxyTicketValidator class will perform a
HTTPS connection from the web server running the Acegi Security webapp
(server3.company.com) above to the CAS server. If for some reason the
web server keystore does not trust the HTTPS certificate presented by the
CAS server, you will receive various failures as discussed below. NB: This
has NOTHING to do with client-side (browser) certificates. You need to
correct the trust between the two webserver keystores alone.

[richardsang2004]

It sounds good that I need to resolve the handshake between the CAS server and the Acegi server. Since they are both local, running on localhost; there is only one keystore. I don't know how I am going to change it to resolve the handshake problem. Can you be more specific on how to do it.
Right now my cas-acegi still having some problems even though I have follow the howto.txt and generated the keystore and store it inside tomcat.

[Ben Alex]

Did you set the CasProxyTicketValidator.trustStore property to the full file system location to your cacerts file (I just noticed this was incorrect in howto.txt)? I found this the easiest way to ensure you're using the correct keystore.