Embedded Tomcat behind Apache HTTPd: Why can't this seem to be configured?

[Drew Northup]

My coworker and I have tried pretty much everything we can think of to get the embedded Tomcat CAS to work behind an Apache HTTPd (which is doing all of the HTTPS stuff, because (1) it is our standard configuration and we don't hate our fellow sysadmins, and (2) we don't hate ourselves).

I'm not going to say up-front what our current configuration is because (1) that's not the point of this question, and (2) it would poison the conversation.

Again, this isn't what "what we've done wrong" this is about "how is it supposed to work".

If the answer is "do the TLS in java" don't expect a friendly response, as that's not an answer. This is standard configuration which should work. If it doesn't, then that's a bug. This is all on one host, between daemons on the same host, and not on the open network.

(signature block probably missing because I'm using the Google Groups interface)

[AJ]

That setup is working fine for me, except my Tomcat isn’t embedded, it’s running on its own, but only on localhost serving http only.  Apache is configured to terminate ssl and proxy requests to tomcat for the /cas endpoint.

On Jan 28, 2026, at 9:08 PM, Drew Northup <drew.n...@maine.edu> wrote:

My coworker and I have tried pretty much everything we can think of to get the embedded Tomcat CAS to work behind an Apache HTTPd (which is doing all of the HTTPS stuff, because (1) it is our standard configuration and we don't hate our fellow sysadmins, and (2) we don't hate ourselves).

--
- Website: https://apereo.github.io/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
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 cas-user+u...@apereo.org.
To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/26818e29-12bd-421a-97aa-9e4f94e3db3cn%40apereo.org.

[Derek Badge]

I ran a similar setup for years, so this feels like a configuration issue. In my previous case, I had the embedded server on 8443, with the proxy handling 443 and communicating via SSL to that backend. I’m wondering if there’s a specific limitation with the embedded server here? Since I didn’t perform the initial setup on this system, I’m not sure on the original intent/sin/decision.

[Phil Hale]

Here is my configuration for an Apache HTTPD reverse proxy in front of an embedded tomcat 10 CAS 7.3.x deployment:

  SSLProxyEngine On
  ProxyRequests Off
  ProxyPreserveHost On

  <IfModule env_module>
    SetEnvIf Front-End-Https "^on$" HTTPS=on
  </IfModule>

  <Proxy *>
     Order allow,deny
     Allow from all
  </Proxy>

  ProxyPass           /cas/             http://localhost:8080/cas/
  ProxyPassReverse    /cas/             http://localhost:8080/cas/

This has been working for years with no issues.

Phil

[Drew Northup]

Thanks Derek & AJ,

My experience has also been that using the external servlet container is more flexible and the configuration options tend to more often do what the plain language of the documentation indicates that they should. We'll drop the attempt to use the embedded Tomcat container and move forward using a system daemon instead.

[Jonathon Taylor]

Hi Drew,

We run embedded Tomcat just fine on CAS 7.3.  I know you specifically asked about httpd, we use Caddy, but similar concepts apply and if it's something in your Tomcat config perhaps this will help.  We terminal HTTPS in Caddy and Tomcat listens on 8080, same host.  Good luck!

cas.properties

# ---------------------------------------

# Embedded Tomcat configuration

# ---------------------------------------

server.tomcat.basedir=tomcat-basedir

server.tomcat.max-http-form-post-size=2MB

server.tomcat.threads.max=300

# Proxied

server.port=8080

server.ssl.enabled=false

server.max-http-request-header-size=2MB

cas.server.tomcat.http-proxy.enabled=true

cas.server.tomcat.http-proxy.secure=true

cas.server.tomcat.http-proxy.scheme=https

cas.server.tomcat.http-proxy.protocol=HTTP/1.1

# Logging

server.tomcat.accesslog.enabled=true

# uncomment below when trouble-shooting

#server.tomcat.accesslog.buffered=false

server.tomcat.accesslog.directory=/etc/cas/log

server.tomcat.accesslog.prefix=access_cas

server.tomcat.accesslog.suffix=.log

server.tomcat.accesslog.max-days=7

server.tomcat.accesslog.rename-on-rotate=true

server.tomcat.accesslog.pattern=%t %a %{X-FORWARDED-FOR}i \"%r\" %s (%D ms) %{User-Agent}i

Caddyfile

{

servers {

max_header_size 2MB

}

log {

output stdout

}

}

server.domain.berkeley.edu alias.domain.berkeley.edu {

log {

output stdout

}

tls {

ca https://acme.sectigo.com/v2/InCommonRSAOV

eab "blah" "blahblahblah"

}

header {

# enable HSTS

Strict-Transport-Security max-age=31536000;

}

request_body {

max_size 2MB

}

@miscreants {

header_regexp User-Agent (?i).+msnbot.+|.+scrapbot.+|.+ExchangeWebServices.+

}

respond @miscreants 400

reverse_proxy http://localhost:8080 {

trusted_proxies x.x.x.x/26 x.x.x.x/26 x.x.x.x/26

header_up X-Forwarded-Ssl on

header_up X-Real-IP {client_ip}

# this is required to make pac4j WebContext.getRequestURL return port

# the OIDC endpoint validation uses this

header_up X-Forwarded-Port {http.request.port}

header_up X-Url-Scheme {scheme}

header_down content-security-policy {http.response.header.content-security-policy}

}

}

# this is required for the health checks hitting the ip_address/actuator to work

x.x.x.x x.x.x.x {

log {

output stdout

}

tls internal {

}

reverse_proxy http://localhost:8080 {

trusted_proxies x.x.x.x/26 x.x.x.x/26 x.x.x.x/26

header_up X-Forwarded-Ssl on

header_up X-Real-IP {client_ip}

# this is required to make pac4j WebContext.getRequestURL return port

# the OIDC endpoint validation uses this

header_up X-Forwarded-Port {http.request.port}

header_up X-Url-Scheme {scheme}

header_down content-security-policy {http.response.header.content-security-policy}

}

}

To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/66a0eb0e-29ae-4567-8672-9de184bfaff6n%40apereo.org.

--

Jonathon Taylor

Information Security Office | University of California, Berkeley

jona...@berkeley.edu

[Daniel Maldonado]

I run the embedded Tomcat at 8080 and terminate the certificate on an NGINX server, which connects to the Tomcat server.

Take a look at these CAS options:

server.ssl.enabled=false
server.port=8080
cas.server.tomcat.http-proxy.enabled=true
cas.server.tomcat.http-proxy.protocol=HTTP/1.1
cas.server.tomcat.http-proxy.secure=true
cas.server.tomcat.http-proxy.scheme=https
server.servlet.context-path=/

So you can use something like:

ProxyPass "/" "http://cas-server:8080/" 

ProxyPassReverse "/" "http://cas-server:8080/" 

in your Apache server.

On Thursday, January 29, 2026 at 1:32:44 AM UTC-5 Derek Badge wrote:

[Drew Northup]

Daniel,
When we tried using cas.server.tomcat.http-proxy.secure=true it stopped dead because we weren't suppling it certificates to use for TLS inside of the embedded Tomcat. Are you sure that NGINX is forwarding HTTP and not HTTPS to the container?

[Derek Badge]

A packet sniffer on either end would prove it, and tcpdump on Linux is a fantastic tool for that purpose. You don't need extensive knowledge of packets to use it; with HTTP, the traffic will appear as readable text, whereas with HTTPS, the encryption will make it unreadable.

Best regards,

Derek Badge

You received this message because you are subscribed to a topic in the Google Groups "CAS Community" group.
To unsubscribe from this topic, visit https://groups.google.com/a/apereo.org/d/topic/cas-user/FMB8OqgJnQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cas-user+u...@apereo.org.
To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/e3e0648c-2a4e-45b3-aed5-9e6f2aec2158n%40apereo.org.

[Drew Northup]

We tried a bunch of different ideas from different people here (and otherwise). We attempted using the one distributed in the docker container, but it is missing modules that we need. After a great deal of futzing we got it to say "oh yeah, https", but only after stuffing a 10-year self-signed certificate into it, which is a crappy solution...yet it did stop puking up spurious "not HTTPS" errors. However, each time we build one ourselves, which has the modules in it that we need, we get a tons of the following warnings prior to fatal errors:

2026-02-02 08:39:45,928 TRACE [org.springframework.security.web.savedrequest.HttpSessionRequestCache] - <matchingRequestParameterName is required for getMatchingRequest to lookup a value, but not provided>

This indicates to me that there is a fatal error somewhere in the build chain—somewhere we here haven't modified. Somebody please come up with explanation indicating that isn't the case...please. As if the build chain we are getting directly from Apereo and using with a stock Amazon Corretto Java has a fatal error in it that's a major problem for everyone.

[Richard Frovarp]

What's not working? We have it working.

server.port=8080
server.ssl.enabled=false

cas.server.tomcat.http-proxy.enabled=true
cas.server.tomcat.http-proxy.protocol=HTTP/1.1
cas.server.tomcat.http-proxy.secure=true
cas.server.tomcat.http-proxy.scheme=https
cas.server.prefix=${cas.server.name}/cas

In the CAS config. I don't think we're doing anything too special in the proxy config. Unsure if this was for CAS or something else, but it is part of our standard: RequestHeader set X-Forwarded-Proto "https"

--

- Website: https://apereo.github.io/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
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 cas-user+u...@apereo.org.

To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/b5dff768-3358-4969-8726-5d96a986b099n%40apereo.org.