In my case, that file is:
lrwxrwxrwx 1 root root 27 jul 24 14:37
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts ->
/etc/ssl/certs/java/cacerts
The cert was imported on both nodes at the exception time in that file,
one failing and the other not, which is quite odd.
Any other idea?
Thanks.
El 16/10/15 a las 20:27, Jay escribió:
> That error simple means your certificate is not in the Java store....
>
> You may have to import your certificate into java store ..... which is
> a file called cacerts inside your jre foler something like
> jre/lib/security
>
> Cheers
> Jay
>
>
> On Fri, Oct 16, 2015 at 7:56 PM, Nicolás <nico...@devels.es
> <mailto:nico...@devels.es>> 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
> <http://cas.whatever.com>). This works quite well so far.
> 1.2) Our /cas-management site has a wildcard certificate
> (*.whatever.com <http://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 tocas-u...@lists.jasig.org
> <mailto:cas-user@lists.jasig.org> as:india....@gmail.com
> <mailto:india....@gmail.com>
> To unsubscribe, change settings or access archives,
> seehttp://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: nico...@devels.es
> 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
