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
--
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
