CAS, Apache, Tomcat and mod_jk

[Scott Battaglia]

By recent I probably meant 3.0.5.

-Scott

On 11/2/06, Ryan Shelley <rshelley at csun.edu> wrote:
>
> I'm running 3.0.4, and I can't for the life of me find
> HttpClient3FactoryBean... I've looked under the org.jasig.cas.utilpackage, as well as hunted through all of the configuration files looking
> for a references to that bean, but to no avail.  How recent is "recent"?
>
> Ryan Shelley
> Lead Developer
> ITR Web Development/Middleware
> California State University, Northridge
>
> 818.677.4258
> rshelley at csun.edu
>
>
>
> On Nov 2, 2006, at 11:15 AM, Scott Battaglia wrote:
>
> If you're using more recent versions of CAS, you just need to propertly
> configure the HttpClient3Factory bean:
>
> http://developer.ja-sig.org/projects/cas/multiproject/cas-server/apidocs/org/jasig/cas/util/HttpClient3FactoryBean.html
>
> -Scott
>
> On 11/2/06, Ryan Shelley <rshelley at csun.edu> wrote:
> >
> > Right.. well, this is only a development server.  I don't see any
> > documentation online or within either of the configuration files that
> > mention disabling the strict name checking.  Is it a separate bean that
> > needs to be used instead of HttpBasedServiceCredentialsToPrincipalResolver?
> >
> > Ryan Shelley
> > Lead Developer
> > ITR Web Development/Middleware
> > California State University, Northridge
> >
> > 818.677.4258
> > rshelley at csun.edu
> >
> >
> >
> > On Nov 2, 2006, at 6:01 AM, Scott Battaglia wrote:
> >
> > The way HttpsUrlConnection in Java works is that it not only does the
> > SSL handshake but it also compares the host name on the certificate to the
> > host name requested.  If they don't match it fails. In newer versions of CAS
> > Server and CAS client you can disable the strict name checking because we
> > use HttpClient (however we don't recommend it in production).
> >
> > -Scott
> >
> > On 11/1/06, Ryan Shelley <rshelley at csun.edu > wrote:
> > >
> > > So after getting everything working with CAS on Tomcat, I'm now
> > > looking into proxying CAS through Apache using mod_jk.  Apache and mod_jk
> > > are setup properly, however, I'm having some certificate issues and not
> > > exactly certain how Apache and mod_jk should be configured in regards to
> > > their SSL definitions.  What is the proper organization of certificates in a
> > > CAS scenario where Server 1 is running Apache2, Tomcat 5.5 and mod_jk
> > > serving CAS, and Server 2 is also running Apache2, Tomcat 5.5 and
> > > mod_jk serving my application?  Who should be managing what certs?
> > > The reason I ask is because we're seeing an error that only occurs
> > > when we route traffic through Apache instead of going between Tomcat
> > > instances:
> > >
> > > javax.servlet.ServletException: Validation threw exception:
> > > javax.net.ssl.SSLHandshakeException:
> > > sun.security.validator.ValidatorException: PKIX path building failed:
> > > sun.security.provider.certpath.SunCertPathBuilderException : unable to
> > > find valid certification path to requested target,
> > > sun.security.validator.ValidatorException: PKIX path building failed:
> > > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> > > find valid certification path to requested target
> > >
> > > Now, Apache2 on Server 1 does have SSL enabled, however, the instance
> > > of Apache2 on Server 1 is running several VirtualHosts and has several
> > > cnames.  The SSL cert for Apache2 on Server 1 is only signed for one domain
> > > (which is different from the cname CAS is running under, ex: cert is for
> > > server1.csun.edu, however, the cname for CAS is cas-dev.csun.edu)
> > > since there is only one IP address on the server.  Also, the cert on Server
> > > 1 is an openssl PEM cert as opposed to the keytool-generated certs of
> > > Tomcat.  Tomcat on Server 1 is also configured for SSL with separate certs
> > > for cas-dev.csun.edu but is linked to Apache via mod_jk, so these
> > > certs do not come into play when handling requests originating from
> > > Apache.  Apache2 and Tomcat on Server 2 are configured similarly for the
> > > servlet having been developed.
> > >
> > > When I take Apache2 out of the mix on both sides and go from Tomcat to
> > > Tomcat, everything works fine, except that there are other hosts on the
> > > servers that require that Tomcat run on odd SSL ports (7443 as opposed to
> > > 443, for example).  This requires the port be in every request between the
> > > Tomcat instances (hence, the proxying through Apache2 and mod_jk).
> > > Obviously, we'd like to avoid that.  One option, being the most obvious, is
> > > to get an additional IP address for the servers dedicated to that cname...
> > > I'm looking into that.  In lieu of that, are there any configuration options
> > > that would enable this setup to function properly?
> > >
> > > Ryan Shelley
> > > Lead Developer
> > > ITR Web Development/Middleware
> > > California State University, Northridge
> > >
> > > 818.677.4258
> > > rshelley at csun.edu
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Yale CAS mailing list
> > > cas at tp.its.yale.edu
> > > http://tp.its.yale.edu/mailman/listinfo/cas
> > >
> > >
> > >
> > _______________________________________________
> > Yale CAS mailing list
> > cas at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas
> >
> >
> >
> > _______________________________________________
> > Yale CAS mailing list
> > cas at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas
> >
> >
> >
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20061102/ce701f57/attachment.html