RE: [cas-user] Need help configuring phpCAS on Windows

[Neil Sabol]

Hello Adam,

Not sure if this is what you are looking for but to address the non-https 
redirect, you can use phpCAS::setFixedServiceURL to specify the service URL 
(https://... ) that CAS should redirect to after successful authentication. 
Admittedly, I’ve not tried this on Windows. What webserver are you running by 
the way?

I cannot speak to specifics, but If CAS is not seeing that your application is 
using https, it is probably looking for a webserver environment variable that 
does not exist (likely something to the effect of $_SERVER['HTTPS']).

I hope that helps.

Thanks,
-Neil

From: Adam Causey [mailto:apcau...@vcu.edu]
Sent: Tuesday, October 13, 2015 5:51 AM
To: cas-user@lists.jasig.org
Subject: [cas-user] Need help configuring phpCAS on Windows

I am working with
​a
 department that decided to install php on Windows, and would now like to use 
phpCAS to secure their application.

There are a few issues we've been working on for days without luck.  I'm hoping 
someone
​can
 offer some advice.
​There are two main problems:​

​
When we try to login, the website redirects to CAS, but it is redirecting to 
the non-https version of the
​client application
 instead of the https version.
​  An error occurs when we login using both the non-https and https version of 
the application.​
We commented out "phpCAS::setNoCasServerValidation();" and have tried 
uncommenting
​ ​
"phpCAS::setCasServerCACert($cas_server_ca_cert_path);"
​.
Which certificate (crt) file do we point this to?  Currently it is pointing to 
the server public certificate.  Also, does this make a difference in whether 
the site uses http or https?​

Second problem: we can't find the debug logs.  We setup debugging by following 
the directions 
here, but the log 
file is non-existent.  We also looked in all of the Windows temp folders (as 
instructed on the phpCAS website), but the log file is nowhere to be found.

​If we can't figure this out, would it be possible to use the .Net CAS client 
to secure the application context?​

Thanks,

Adam Causey
VCU



--

You are currently subscribed to 
cas-user@lists.jasig.org as: 
nssa...@unm.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

Re: [cas-user] ticketRegistry starts up but webpage does not resolve

[Jonas Steinberg]

1) yes
2) right, no filtering
3) looked at parent pom.  no .name variable calls.

On Fri, Oct 16, 2015 at 4:03 PM, Ray Bon  wrote:

> 1) You are performing a variable substitution for server.prefix with the
> variable ${server.name}, thus when you run the application, does
> server.prefix = https://myserver.com:8080/cas?
> 2) Your response indicates that you are not using maven filtering so this
> is most likely not your problem.
> 3) If you were/are experiencing the same problem as me, this would be a
> workable solution.
>
> Ray
>
>
> On 2015-10-16 14:55, Jonas Steinberg wrote:
>
> 1) What do you mean the "result" of server.prefix?
> 2) How could maven filtering help me?
> 3) Really?  .nom?!?
>
> On Fri, Oct 16, 2015 at 3:51 PM, Ray Bon  wrote:
>
>> What is the result of server.prefix while running?
>> Are you performing any maven filtering?
>>
>> We have some values filtered into our CAS application at build time. I
>> found that maven would perform a substitution of the project name
>> (defined at the top of pom.xml) for any variable ending in .name; e.g.,
>> ${server.name} or ${foo.bar.name}.
>> I changed the few locations in the code from ${server.name} to
>> ${server.nom}.
>>
>> Ray
>>
>> P.S. When I get some breathing room I intend to investigate this more
>> and submit a bug report (to Maven) if I can reproduce with a simple
>> project.
>>
>>
>> On 2015-10-16 14:07, Jonas Steinberg wrote:
>> > so my ticketRegistry starts but the page I pointed cas.properties at
>> does not resolve the basic cas login screen.  Here's my cas.properties file
>> in a nutshell:
>> >
>> > server.name= https://myserver.com:8080
>> > server.prefix=${server.name}/cas
>> > cas.securityContext.status.access=hasIpAddress('IPv4serveraddress')
>> > cas.security.statistics.access('IPv4serveraddress')
>> > host.name=myserverhostname
>> >
>> > I haven't changed anything else.  It starts without errors but the page
>> doesn't resolve.
>> >
>> > The cas.properties is attached.
>> >
>> >
>>
>>
>> --
>> You are currently subscribed to 
>> cas-user@lists.jasig.org as: jonassteinbe...@gmail.com
>> 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: r...@uvic.ca
> 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: 
> jonassteinbe...@gmail.com
> 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

Re: [cas-user] ticketRegistry starts up but webpage does not resolve

[Ray Bon]

1) You are performing a variable substitution for server.prefix with the
variable ${server.name}, thus when you run the application, does
server.prefix = https://myserver.com:8080/cas?
2) Your response indicates that you are not using maven filtering so
this is most likely not your problem.
3) If you were/are experiencing the same problem as me, this would be a
workable solution.

Ray

On 2015-10-16 14:55, Jonas Steinberg wrote:
> 1) What do you mean the "result" of server.prefix?
> 2) How could maven filtering help me?
> 3) Really?  .nom?!?
>
> On Fri, Oct 16, 2015 at 3:51 PM, Ray Bon  > wrote:
>
> What is the result of server.prefix while running?
> Are you performing any maven filtering?
>
> We have some values filtered into our CAS application at build time. I
> found that maven would perform a substitution of the project name
> (defined at the top of pom.xml) for any variable ending in .name;
> e.g.,
> ${server.name } or ${foo.bar.name
> }.
> I changed the few locations in the code from ${server.name
> } to
> ${server.nom}.
>
> Ray
>
> P.S. When I get some breathing room I intend to investigate this more
> and submit a bug report (to Maven) if I can reproduce with a
> simple project.
>
>
> On 2015-10-16 14:07, Jonas Steinberg wrote:
> > so my ticketRegistry starts but the page I pointed
> cas.properties at does not resolve the basic cas login screen. 
> Here's my cas.properties file in a nutshell:
> >
> > server.name =https://myserver.com:8080
> > server.prefix=${server.name }/cas
> > cas.securityContext.status.access=hasIpAddress('IPv4serveraddress')
> > cas.security.statistics.access('IPv4serveraddress')
> > host.name =myserverhostname
> >
> > I haven't changed anything else.  It starts without errors but
> the page doesn't resolve.
> >
> > The cas.properties is attached.
> >
> >
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org
>  as: jonassteinbe...@gmail.com
> 
> 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: r...@uvic.ca
> 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

Re: [cas-user] ticketRegistry starts up but webpage does not resolve

[Jonas Steinberg]

1) What do you mean the "result" of server.prefix?
2) How could maven filtering help me?
3) Really?  .nom?!?

On Fri, Oct 16, 2015 at 3:51 PM, Ray Bon  wrote:

> What is the result of server.prefix while running?
> Are you performing any maven filtering?
>
> We have some values filtered into our CAS application at build time. I
> found that maven would perform a substitution of the project name
> (defined at the top of pom.xml) for any variable ending in .name; e.g.,
> ${server.name} or ${foo.bar.name}.
> I changed the few locations in the code from ${server.name} to
> ${server.nom}.
>
> Ray
>
> P.S. When I get some breathing room I intend to investigate this more
> and submit a bug report (to Maven) if I can reproduce with a simple
> project.
>
>
> On 2015-10-16 14:07, Jonas Steinberg wrote:
> > so my ticketRegistry starts but the page I pointed cas.properties at
> does not resolve the basic cas login screen.  Here's my cas.properties file
> in a nutshell:
> >
> > server.name=https://myserver.com:8080
> > server.prefix=${server.name}/cas
> > cas.securityContext.status.access=hasIpAddress('IPv4serveraddress')
> > cas.security.statistics.access('IPv4serveraddress')
> > host.name=myserverhostname
> >
> > I haven't changed anything else.  It starts without errors but the page
> doesn't resolve.
> >
> > The cas.properties is attached.
> >
> >
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> jonassteinbe...@gmail.com
> 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

Re: [cas-user] ticketRegistry starts up but webpage does not resolve

[Ray Bon]

What is the result of server.prefix while running?
Are you performing any maven filtering?

We have some values filtered into our CAS application at build time. I
found that maven would perform a substitution of the project name
(defined at the top of pom.xml) for any variable ending in .name; e.g.,
${server.name} or ${foo.bar.name}.
I changed the few locations in the code from ${server.name} to
${server.nom}.

Ray

P.S. When I get some breathing room I intend to investigate this more
and submit a bug report (to Maven) if I can reproduce with a simple project.


On 2015-10-16 14:07, Jonas Steinberg wrote:
> so my ticketRegistry starts but the page I pointed cas.properties at does not 
> resolve the basic cas login screen.  Here's my cas.properties file in a 
> nutshell:
>
> server.name=https://myserver.com:8080
> server.prefix=${server.name}/cas
> cas.securityContext.status.access=hasIpAddress('IPv4serveraddress')
> cas.security.statistics.access('IPv4serveraddress')
> host.name=myserverhostname
>
> I haven't changed anything else.  It starts without errors but the page 
> doesn't resolve.
>
> The cas.properties is attached.
>
>


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

[cas-user] ticketRegistry starts up but webpage does not resolve

[Jonas Steinberg]

so my ticketRegistry starts but the page I pointed cas.properties at does not 
resolve the basic cas login screen.  Here's my cas.properties file in a 
nutshell:

server.name=https://myserver.com:8080
server.prefix=${server.name}/cas
cas.securityContext.status.access=hasIpAddress('IPv4serveraddress')
cas.security.statistics.access('IPv4serveraddress')
host.name=myserverhostname

I haven't changed anything else.  It starts without errors but the page doesn't 
resolve.

The cas.properties is attached.


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


cas.properties
Description: Binary data

Re: [cas-user] Unable to find valid certification path to requested target

[Andrew Morgan]

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

Re: [cas-user] Unable to find valid certification path to requested target

[Nicolás]

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

Re: [cas-user] Unable to find valid certification path to requested target

[Andrew Morgan]

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

Re: [cas-user] Unable to find valid certification path to requested target

[Jay]

May be that node is refereing to a different java location...
Check which java location its refereing to through logs

Jay

On Fri, Oct 16, 2015 at 8:37 PM, Nicolás  wrote:

> 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  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: 
>> india@gmail.com
>> 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: 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: 
> india@gmail.com
> 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

Re: [cas-user] Unable to find valid certification path to requested target

[Nicolás]

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  > 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 tocas-u...@lists.jasig.org 
>   as: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

Re: [cas-user] Unable to find valid certification path to requested target

[Jay]

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  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: 
> india@gmail.com
> 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

[cas-user] Unable to find valid certification path to requested target

[Nicolás]

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: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

[cas-user] maven not throwing my cas.properties into war file

[Jonas Steinberg]

Maven is not throwing my modified cas.properties file in 
/target/war.../WEB-INF/.  Right now to simplify things I am following this 
basic deployment EXACTLY:

http://www-public.tem-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:ssocas:cas4install

I have also noted that in my parent pom, cas.properties has been excluded.  And 
that seems correct, since I'm modifying the cas.properties file that's included 
when you clone simple-cas4-overlay-template.

But for whatever reason maven won't build my cas.properties file or my 
log4j.xml into the war, hence when I deploy the war tomcat has no idea what 
server cas is pointing at.  Any thoughts...
-- 
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

[cas-user] cas install review question

[Jonas Steinberg]

My war is building and exploding in tomcat without errors, but cas is not 
resolving when I browse to it.

This is exactly what I did.  I'd like to know if there's anything I'm missing:

1) git clone g...@github.com:UniconLabs/simple-cas4-overlay-template.git

2) git checkout cas41-with-HZ-and-LDAP

3) (not authenticating for ldap) wiped pom ldap depend. 

4) copy and pasted this: 
https://github.com/Jasig/cas/blob/v4.1.0/cas-server-webapp/src/main/webapp/WEB-INF/deployerConfigContext.xml
into my deployerConfigContext

5) edited cas.properties to fit my network

6) mvn clean package from parent pom directory

7) deploy war to tomcat

8) restart tomcat, browse to server

Doesn't resolve http or https.  

Any insight would be greatly appreciated.
-- 
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

Re: [cas-user] CAS behind proxy - Log client IP recorded at proxy

[Dmitriy Kopylenko]

Carl,

configure the CAS’ Inspektr client info filter as such (in CAS’ web.xml):


  CAS Client Info Logging Filter
  
com.github.inspektr.common.web.ClientInfoThreadLocalFilter
  
  alternativeIpAddressHeader
  X-Forwarded-For
  


Best,
D.

> On Oct 16, 2015, at 9:43 AM, Waldbieser, Carl  wrote:
> 
> 
> When placing CAS behind an HTTP proxy, it is possible to include the client 
> IP connecting to the proxy in an HTTP header that is passed on to the back 
> end CAS service (e.g. X-Forwarded-For).
> Is it possible to configure CAS to log the value of such a header rather than 
> the actual client IP (which would be the proxy in this case, and would not be 
> terribly useful).
> 
> I am interested in knowing how to do this for both CAS 3.5 and 4.x.
> 
> My goal is ultimately to log CAS authentication data (successes, failures) 
> along with the actual client IP information from a proxied CAS service.
> 
> Thanks,
> Carl Waldbieser
> ITS Systems Programmer
> Lafayette College
> 
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: 
> dkopyle...@unicon.net
> 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

[cas-user] CAS behind proxy - Log client IP recorded at proxy

[Waldbieser, Carl]

When placing CAS behind an HTTP proxy, it is possible to include the client IP 
connecting to the proxy in an HTTP header that is passed on to the back end CAS 
service (e.g. X-Forwarded-For).
Is it possible to configure CAS to log the value of such a header rather than 
the actual client IP (which would be the proxy in this case, and would not be 
terribly useful).

I am interested in knowing how to do this for both CAS 3.5 and 4.x.

My goal is ultimately to log CAS authentication data (successes, failures) 
along with the actual client IP information from a proxied CAS service.

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College

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