The request was made to the /cas-management URI, actually. I opened up
https://cas.whatever.com/cas-management, as I wasn't authenticated, I
was redirected to https://cas.whatever.com/cas/login?..., I entered my
credentials and *then*, after redirected back to the cas-management
webapp the exception showed up.
That's the strange thing, if there was an error with the cert of any of
both sites, it would have failed the first time they were opened up, right?
El 16/10/15 a las 21:21, Andrew Morgan escribió:
This error message is caused by Java being unable to resolve the remote
SSL certificate. In this instance, Java is the SSL *client*, trying to
connect to an SSL/TLS resource.
In my experience, this happens when CAS tries to contact a CAS client to
send a SLO (Single LogOut) request. Was there a URL logged along with
this stack dump? You may be able to find information in the CAS audit log
too.
Andy
On Fri, 16 Oct 2015, Nicolás wrote:
Hi,
We're using CAS 4.1.0 and we're having some sporadic issues with our
certs. This is the exception:
Caused by: sun.security.validator.ValidatorException: PKIX path
building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
at
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
at sun.security.validator.Validator.validate(Validator.java:260)
at
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
at
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1451)
... 55 more
Caused by:
sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
at
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196)
at
java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
... 61 more
I've read this [1], but in our case we don't use self-signed certs, but
real Geotrust certs.
Our scenario is the following:
1) We have an Nginx which proxies requests back to Tomcat7 (via
proxy_pass). SSL certs are configured here, for two sites, whose SSL
certs are different.
1.1) Our /cas site has a dedicated certificate (cas.whatever.com). This
works quite well so far.
1.2) Our /cas-management site has a wildcard certificate
(*.whatever.com). This one's throwing the exception, but only on one of
our nodes (we have 2 exactly equal with the very same configuration).
2) We imported both public keys into the system Keystore located in
/etc/ssl/certs/java/cacerts with Keytool (Ubuntu 14.04).
3) Tomcat is using its own Keystore (/etc/tomcat7/keystore.jks)
My questions are:
a) Should this configuration be enough to avoid the exception above? If
yes, why are we getting an exception on point 1.2?
b) Is point 3 relevant?
c) In case this gets painful, is there a non-intrusive way to disable
SSL checking in the CAS-Management webapp?
Thanks.
Nicolás
[1]:
https://wiki.jasig.org/display/casum/ssl+troubleshooting+and+reference+guide
--
You are currently subscribed to cas-user@lists.jasig.org as: mor...@orst.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
