Bill,
When CAS contacts the proxy callback URL, it needs to have the CA cert
that signed the SSL cert (or the self-signed cert) of the proxy callback
URL. This would need to be in the JVM's default
$JAVA_HOME/jre/lib/security/cacerts file (a truststore not a keystore).
Alternatively, the truststore is somewhere specified in an argument to
the JVM to set the system property, javax.net.ssl.trustStore, something
like:
java -Djavax.net.ssl.trustStore=my-cacerts ...rest of command line...
When Apache fronts Tomcat via mod_jk, it has the server certificate and
intermediate (or chain) CA certificate configured in its httpd.conf or
similar file (some use conf.d/ssl.conf). As Matt mentioned, Tomcat
wouldn't be the one doing the SSL connection. Clients would need to
have one of the following in their cacerts file: the CA cert that signed
the intermediate CA cert, the intermediate CA cert, or the server cert.
Non-Java clients need the same thing is their equivalent cacerts file.
To recap for Java, servers need the private key and server cert in their
keystore while clients need the CA cert that signed the server cert in
their truststore. The default keystore is ~/.keystore in *NIX-land and
the default truststore is $JAVA_HOME/jre/lib/security/cacerts. In the
case of proxy tickets, CAS is both a server and a client; server
handling requests (logins and validating tickets) and client sending the
proxy ticket to a CASified application.
Hope this helps,
Russ
On Tue, 21 Aug 2007, Bill Bailey wrote:
>
> Thanks, Matt.
>
> I may fool around with it a bit more if I have time, but for now I guess
> I should just be happy it is working. Just FYI ... the last error I got
> just before fixing it was 'SSL peer not verified' and it occurred when
> CAS tried to call back to my proxy callback URL to deliver the proxy
> ticket.
>
> I vaguely remember some option in Apache or mod_jk that had to do with
> SSL certificates and certificate chains. Maybe there is some
> configuration that is different between my environment and yours that
> allows yours to work.
>
> If I find a more satisfactory explanation of why the problem occurred
> I'll post it here for the benefit of anyone else who might travel this
> road.
>
> Thanks.
>
> Bill
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Smith, Matt
> Sent: Tuesday, August 21, 2007 9:24 AM
> To: Yale CAS mailing list
> Subject: RE: CAS Behind Apache HTTPD
>
> I am not using Proxy Tickets, but I have had no problems
> hiding /serviceValidate behind Apache. As a matter of fact, I turn off
> Tomcat's HTTP/HTTPS ports, and only leave the AJP port enabled. As long
> as the CAS protected application trusts the certificate (either by
> trusting the signing CA, or the cert itself), I have not had any
> problems.
>
> -Matt
>
> On Tue, 2007-08-21 at 09:04 -0400, Bill Bailey wrote:
>> After a few bobbles I finally have it all up and running. The one
>> problem I encountered I will mention here just in case someone else
>> stumbles in the same place.
>>
>>
>>
>> In the Acegi configuration, there are a number of places where you
>> must provide URL's ... CAS login, proxy validate, service names, proxy
>> retrieval, etc. On my first pass, I went a bit overboard and changed
>> all of the URL's to go through Apache HTTPD (i.e. removed the port
>> 8443). I am using self signed certificates and apparently there are
>> some problems with certificate chains getting propagated properly when
>> you go to Tomcat through mod_jk so I started seeing errors when
>> validating tickets and or trying to deliver proxy tickets (which are
>> very picky about SSL trust issues). Once I changed my configuration to
>> have all 'client visible' URL's go through Apache HTTPD and all the
>> 'behind the scenes' URL's go directly to Tomcat, things started
>> working OK.
>>
>>
>>
>> I'm curious if anyone else has encountered any issues with this. I'm
>> thinking this MIGHT NOT be a problem if I wasn't using self-signed
>> certificates, but I can't be sure.
>>
>>
>>
>> Bill
>>
>>
>>
>>
>>
>>
>> ______________________________________________________________________
>> From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> On Behalf Of Scott Battaglia
>> Sent: Tuesday, August 21, 2007 12:26 AM
>> To: Yale CAS mailing list
>> Subject: Re: CAS Behind Apache HTTPD
>>
>>
>>
>>
>> We run CAS and all of our applications behind Apache and have not had
>> any issues. Acegi should be fine as its underlying client is the Yale
>> CAS client.
>>
>> -Scott
>>
>> On 8/17/07, Bill Bailey <[EMAIL PROTECTED]> wrote:
>>
>> Thanks, Matt. That is encouraging since I will probably start setting
>> things up today. I'll hit the list again if I run into more specific
>> questions.
>>
>> Bill
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> On Behalf Of Smith, Matt
>> Sent: Thursday, August 16, 2007 5:02 PM
>> To: Yale CAS mailing list; Yale CAS mailing list
>> Subject: RE: CAS Behind Apache HTTPD
>>
>> Bill-
>> Most of my CAS protected apps are tucked away behind Apache. I've
>> been using the stock Yale Java client for a while, and have recently
>> tried out the JA-SIG client, both with success in this
>> configuration. I
>> have not (yet) tried the Acegi client. Essentially, the mod_jk or
>> mod_proxy_ajp that you are using to forward the requests from Apache
>> to
>> Tomcat's AJP port (generally 8009) just does the *Right Thing* for
>> you
>> as far as URL mapping goes.
>>
>> HTH,
>> -Matt
>>
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] on behalf of Bill Bailey
>> Sent: Thu 2007-08-16 16:06
>> To: Yale CAS mailing list
>> Subject: CAS Behind Apache HTTPD
>>
>> Hi,
>>
>>
>>
>> I have CAS configured and running under Tomcat and so far all is well.
>> However, in production we will be introducing Apache HTTPD in between
>> the users and Tomcat. All requests will come in on port 80 or 443 to
>> Apache HTTPD which will forward the requests to Tomcat where
>> necessary.
>> I should also note that we are using ACEGI security as well.
>>
>>
>>
>> In theory, this doesn't seem like it should cause any problems, but
>> since CAS is heavily reliant on HTTPS and ACEGI requires URL's to be
>> configured in numerous places, I sense at least the potential for
>> problems in getting the setup right. Is anyone else running in a
>> similar
>> configuration? Does anyone have any experiences to report or warnings
>> or
>> suggestions?
>>
>>
>>
>> Thanks.
>>
>>
>> Bill Bailey
>>
>> Senior Developer / DBA
>> Northland, A Church Distributed
>>
>>
>>
>>
>> _______________________________________________
>> Yale CAS mailing list
>> [email protected]
>> http://tp.its.yale.edu/mailman/listinfo/cas
>> _______________________________________________
>> Yale CAS mailing list
>> [email protected]
>> http://tp.its.yale.edu/mailman/listinfo/cas
>>
>>
>>
>>
>>
>> --
>> -Scott Battaglia
>>
>> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>>
>>
>> _______________________________________________
>> Yale CAS mailing list
>> [email protected]
>> http://tp.its.yale.edu/mailman/listinfo/cas
>
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
