If you have multiple JVMs on the same server, please make sure that you install the certificates into the correct cacerts file. I have, on occasion, installed them into the wrong one!
On Thu, Feb 12, 2009 at 5:04 PM, zhang li <[email protected]> wrote: > Howard Gilbert wrote: > >> There is a general problem that may affect other users, so I will try to >> describe the whole thing. >> >> This message is most commonly generated by a problem with Service Ticket >> Validation. >> After CAS redirects the browser back to the service (the CAS client >> application) the client has to send the ticket to CAS and get back the >> netid. This validation uses an SSL connection to CAS to maintain the >> integrity of security information. The Client is essentially checking to >> make sure that the CAS that validates the ticket is the machine it claims >> to >> be because the Server Certificate that it uses in the SSL connection has >> the >> expected host name. >> >> Strictly speaking, there is no reason why the SSL certificate used to >> validate a service ticket has to be one you purchased commercially, but >> since CAS also has to login users, and almost nobody distributes >> institutional free root certificates to all their users, CAS already needs >> a >> Verisign certificate for the login piece and therefore the /validate or >> /serviceValidate uses the same certificate. Assuming then that the CAS >> server SSL certificate is from one of the well known public commercial >> CAs, >> it should not be necessary to add that CA root certificate into the >> {jre}/lib/security/cacerts file. >> >> So, when you get the exception listed below, in most cases you are trying >> to >> run under JDK 1.4.x and CAS is running on a server that has a Verisign >> certificate purchased recently. There was a bug in versions of Java before >> 1.5 (or maybe the very last update to 1.4, but that is a rumor I have not >> tested). Old Java could not validate a valid certificate issued by a CA >> chain. Up to two years ago, Verisign issued Web server certificates signed >> by a root CA. Two years ago, Verisign started to issue certificates signed >> by a chain (a CA one up from the root), but it offered the option during a >> transition period to get old style certificates over the next two years. >> The >> grace period expired a few months ago, and since then you have only been >> able to get chain style certificates that JDK 1.4 x JVMs will not process >> correctly. >> If possible, upgrade to some version of JDK 1.5. If that is impossible, >> then >> you might try the last update of 1.4.x which might fix it (and get a >> reasonably new cacerts file). If you absolutely cannot run the application >> on any modern version of Java, then you are not going to be able to >> validate >> service tickets using a modern Verisign Web server SSL certificate. I >> suppose you could create a second SSL port number, associate it with a >> certificate for the same web server name generated by a local CA, and add >> that local CA to the {jre}/lib/security/cacerts file. Then you only use >> this >> new port for /validate or /serviceValidate URL requests which are only >> generated by applications that know about the locally generated CA, while >> browsers continue to use the normal public port with the Verisign >> certificate. >> >> This is a problem with Verisign and old Java. It has nothing to do >> specifically with the CAS 2 client or the CAS 3 server, except that if you >> run an old client you may be running it under an old Java, and everybody >> has >> to eventually go to modern Verisign certificates as their old certificates >> expire. If you do not have this problem now, you may have it later the >> year >> (whenever the current Verisign certificate expires on you CAS server if >> the >> current certificate is an old style unchained cert and you have any CAS >> clients that run on old JVMs). >> >> -----Original Message----- >> From: zhang li [mailto:[email protected]] Sent: Thursday, February 12, >> 2009 3:07 PM >> To: [email protected] >> Subject: [cas-user] Yale CAS 2 client connecting with CAS 3.3.1 server >> >> Hi, >> >> I'm using Yale CAS 2 client connecting with CAS 3.3.1 server, >> I was able to login, but after login, I got the following error: >> >> javax.servlet.ServletException: sun.security.validator.ValidatorException: >> PKIX path building failed: >> sun.security.provider.certpath.SunCertPathBuilderException: unable to find >> valid certification path to requested target >> >> >> Looks like the browser can not find the right location of the certificate. >> >> >> Can anybody tell me how to fix it ? >> >> >> Thanks. >> >> >> Li >> >> >> >> >> > Hi Howard, > > Both of my client and server machine has JDK 1.6 installed, so I'm not sure > whether it's the same > issue with the Java version. > > > Thanks. > > Li > > > > -- > 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
