I guess you're using self signed certificates. If so, you can use http
as a lenient way to validate your CAS ticket rather than https. Though
this is not recommended in any production environment.
Regards,
Shi Yusen/Beijing Langhua Ltd.
在 2009-02-12四的 17:04 -0500，zhang li写道：
> 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
