That sounds like the Service Ticket validation step, which is performed by
the cas-management application when it connects to the CAS server.
I think it may have been mentioned already, but you'll need your CAS
server's CA cert installed in the Java keystore that is used by the
cas-management application.
Andy
On Fri, 16 Oct 2015, Nicolás wrote:
> 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 [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
>
--
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
