The ssl warning is actually good test to demonstrate that something is broken and dysfunctional in your deployment. As Scott said, you will need to find a way to relay the SSL context back to the application server. The warning shows up only if that chain is broken. You’ll need to consult apache/tomcat.load balancer docs to see how to configure your containers. There is nothing in CAS that requires/enables you do this, other than the expectation that HTTPS is available by simply checking the request. (Which is the piece you can turn off, but should not since the problem is elsewhere)
- Misagh > On Feb 9, 2016, at 9:29 AM, Stephan Arts <[email protected]> wrote: > > My workaround was indeed to do this: > > internet -[HTTPS]> load-balancer -[HTTP]> apache -[HTTPS]> tomcat... > > I don't like it either, since it requires me fiddling around with the java > keystore and self-signed certificates, which is an administrative overhead > with no added value when it comes to security. > > I'd much rather have apache provide the X-Forwarded-Proto header set to HTTPS > and instruct tomcat to tell cas 'every thing is fine, walk along'. > > Unfortunately, that does not work. (CAS 4.0.7) - Is there a way I can > suppress the HTTPS warning? There really is no reason to encrypt the data > going over the loopback device. > > Cheers, > > Stephan > > On Mon, Feb 8, 2016 at 6:55 PM, Scott Battaglia <[email protected] > <mailto:[email protected]>> wrote: > If something is fronting CAS that is terminating SSL, you should be able to > indicate to the servlet container hosting CAS that it really is a secure > connection. Does that not work? (sorry I can't remember the specifics of it) > > On Mon, Feb 8, 2016 at 12:52 PM, Robert <[email protected] > <mailto:[email protected]>> wrote: > Hi Misagh, > > Thanks for your reply. > > How can we enable SSO without HTTPS? > > > On Monday, February 8, 2016 at 12:20:57 PM UTC-5, Misagh Moayyed wrote: > >> On Feb 8, 2016, at 8:14 PM, Robert <[email protected] <>> wrote: >> >> Our current Production Setup >> >> For CAS3.x.x having SSL was not required to support Single Sign On. This was >> perfect as we have Reverse Proxy Servers fronting our Application Server >> farm and it took care of providing all TLS for our user facing interface. >> All handshake between the reverse-proxy server and JBOSS/ IBM WAS server >> farm was “as if” no SSL was in place. This also helped us immensely in terms >> of performance, as all SSL encryption/decryption was handled on our Reverse >> Proxy Servers. And helped cut cost for our clients in terms of maintaining >> and purchasing certificates to bare essential. >> > > All of that still true in CAS4. >> >> >> Now, we are trying to work with CAS4 >> >> We found out that it requires HTTPS or else Single Sign On just won’t work. >> > > HTTPS is always required by default. How you satisfy that requirement remains > the same across all CAS versions. There are not considerations on the CAS > side to dictate a particular form of container configuration. > >> >> Can you help us understand as to how do we make this new solution work >> within our production sites? >> >> 1. Will this not force us to have certificates deployed on each >> and every Application Server? How do we make our clients understand the cost >> benefit of doing so when having Reverse Proxy Fronting was already taking >> care of this? >> >> 2. What happens where the server farms are running behind 3-Zone >> architecture? >> >> 3. What would be performance hit on Application Server when >> during peak load the server would also have to deal with TLS over and above >> the work that it is currently supposed to be handling? >> >> >> Can we turn off this HTTPS requirement to support SSO with CAS4? If so can >> you help us as to where to begin. >> > > You can enable SSO without HTTPS. This is of course a bad idea. >> >> >> Our situation has become very urgent, so we don't mind if we have to write >> Java code and change XML configuration. >> >> >> >> Thanks for your help. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "CAS Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <>. >> Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/ >> <https://groups.google.com/a/apereo.org/group/cas-user/>. > > > -- > You received this message because you are subscribed to the Google Groups > "CAS Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/ > <https://groups.google.com/a/apereo.org/group/cas-user/>. > > > -- > You received this message because you are subscribed to the Google Groups > "CAS Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/ > <https://groups.google.com/a/apereo.org/group/cas-user/>. > > > > -- > "The number of Unix installations has grown to 10, with more expected." > -- The Unix Programmer's Manual, 2nd Edition, June, 1972 > > -- > You received this message because you are subscribed to the Google Groups > "CAS Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/ > <https://groups.google.com/a/apereo.org/group/cas-user/>. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
