RE: Query: HSTS | Tomcat 9.0.50

[Deepti Sharma S]

Hi Olaf,

 Let me explain more on my use-case :

1. There is no reverse proxy in between tomcat and UA in my use case.
2. In Tomcat/conf/server.xml I have below connector settings :

 


 

When I configure HSTS in Tomcat/conf/web.xml and try to access website via 
HTTPS https://[domain]:8443, HSTS header is returned but ignored
as in when I change URL to http://[domain]:8080 URL is not changed to secured 
URL.

 

3. When I change conf/server.xml with below connector settings along with HSTS :

 



 

Try to access website via HTTPS https://[domain]:433 URL is changed to 
https://[domain], 
HSTS header is returned and honoured as in when I change URL to 
http://[domain]:80 URL is changed to secured URL https://[domain].

 

So my query is how to configure HSTS on explicit custom ports(like in my case 
mentioned in point 2 8080/8443) or what is the recommendation, please suggest?


Regards,
Deepti Sharma 
PMP® & ITIL 

-Original Message-
From: Olaf Kock  
Sent: 16 January 2023 13:56
To: users@tomcat.apache.org
Subject: Re: Query: HSTS | Tomcat 9.0.50


On 16.01.23 06:57, Deepti Sharma S wrote:
> Hello Team,
>
> Can you please help us for below query:
>
> Query : How to enable HSTS in Apache Tomcat on non-default ports?
>   We have custom ports for http and https and we want to enable HSTS on 
> those custom ports.
>
> Note: We could see HSTS is working with default ports 80/443 though it's not 
> working on other custom ports, please let us know if there are different 
> steps to enable HSTS on non-default ports.
>
In order to "work", HSTS *must* be on https, by specification.

When you say you got it working on 80/443, you haven't. You might see the 
headers, but it's not working. Most likely the header is ignored by the browser.

Whereever you handle your https termination - that might be on Tomcat, or on a 
reverse proxy that sees traffic before Tomcat does - you'll best do the HSTS 
handling. /That/ server knows it's serving https. And there the header actually 
is valid and working.

If you try to configure a http (not https) connector on Tomcat for adding the 
HSTS headers, it's well within the specification to ignore that setting.

Technically you can do some trickery around that, but to make that sensible and 
safely would take more than a quick answer. And leave room for 
misinterpretation and configuration mistakes. So: Configure it anyhwere you 
terminate https, and ignore it on http.

Olaf



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SSO Token not found with RewriteRules

[Jerry Malcolm]

Well, after downloading and installing the Tomcat source in my Eclipse 
environment and tracking through a bunch of breakpoints, I figured out 
what was happening.   SingleSignOn.invoke() was querying for the list of 
cookies in the request (that were indeed present in the request), but 
was returning null.  Since no cookies were 'found' there was no 
JSESSIONIDSSO cookie found, and everything failed from that point on.  
So I started tracking why the cookies that were present were being 
ignored.  convertCookies was called, which did a getContext() which 
returned null, so everything aborted.  getContext() failed apparently 
because I did not have a ROOT webapp (context) defined.  I added a dummy 
ROOT webapp, and voila


So the bottom line to the entire problem is that RewriteRules with 
SSO is not permitted UNLESS there is a dummy ROOT webapp defined.  I'm 
not sure why this would be  a requirement, and I was not able to find 
any documentation about it.   I understand why SSO might require 
contexts.  But the primary purpose of RewriteRules is to hide the 
plumbing on the URL line.  If the requirement for context present is 
required for SSO, then it would seem to me that the context should be 
checked on the target of the rewrite, not the original string being 
rewritten, since it most likely will not have a valid context.  And a 
dummy unused ROOT webapp just takes up resources. The reason it worked 
in the other virtual host is that I actually did have a need in that 
host for a ROOT context.


This one was painful.  Just out of curiosity, is this restriction 
intended?  If so, error messages and/or documentation of it might need a 
review.


Thanks.

Jerry

On 1/16/2023 12:40 AM, Jerry Malcolm wrote:
I have one virtual host working fine on a Windows 11 TC 9 install. I 
am adding a 2nd virtual host to that same running installation. This 
TC is standalone, handling http requests directly (not via httpd).   
Both virtual hosts have a rewrite.config.   On the new domain, I go to 
a page that requires a login, do the standard login, and it show the 
page.  I can F5 refresh the page and it continues to appear.  But if I 
enter a url that redirects to this same page, I get the signin screen. 
If I try to sign in again, I get an error "The requested resource 
[/idmanager/j_security_check] is not available"  I enabled redirect 
logs, and they show SSO token not found.   I know the redirect is 
working fine for the new  virtual host since there's no problems going 
to unprotected (no sign-in) redirected pages.


This exact scenario works perfectly fine (with rewrite rules) on the 
other virtual host in the same TC.   I've compared the two host 
configurations in server.xml and they appear identical other than than 
the name and path.  i.e. SingleSignOn valve is specified on both.


The fact that SSO only fails on redirects and not on URLs without 
redirects, plus the fact that it works fine on one virtual host and 
not on the other is baffling me.  All indications point to some sort 
of config error or typo on the something in the new virtual host.  But 
I have spent more hours that I want to admit on this, and I simply 
can't figure out anything that would cause this.  I'm sure I made some 
config change somewhere a long time ago on the first virtual host 
that's making it work correctly. But I can't find anything, and I'm at 
a total loss.


What could be causing rewrite rules to not find SSO cookies? Where did 
I mess up?


Thanks

Jerry


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat for Apple silicon coming soon?

[Mark Thomas]

On 16/01/2023 20:40, Robert Turner wrote:

You can run an aarm64 version of the Java runtime (various distributions
exist) and run Tomcat on that -- it works well. No specific version of
Tomcat is required as it a Java package.


+1

I've been running the Tomcat unit tests on Apple silicon for a while now.

Generally, if there is a JRE that meets the minimum Java version 
requirement for a platform, then Tomcat will run.


Mark





On Mon, Jan 16, 2023 at 3:38 PM m...@cvkimball.com 
wrote:



I'd like to run Tomcat on one of the new Apple products based on the
Apple Mac silicon ARM64 architecture.

Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in
the near future?

Thanks,

Chris Kimball

Redding, CT


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat for Apple silicon coming soon?

[Robert Turner]

You can run an aarm64 version of the Java runtime (various distributions
exist) and run Tomcat on that -- it works well. No specific version of
Tomcat is required as it a Java package.



On Mon, Jan 16, 2023 at 3:38 PM m...@cvkimball.com 
wrote:

>
> I'd like to run Tomcat on one of the new Apple products based on the
> Apple Mac silicon ARM64 architecture.
>
> Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in
> the near future?
>
> Thanks,
>
> Chris Kimball
>
> Redding, CT
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat for Apple silicon coming soon?

[m...@cvkimball.com]

I'd like to run Tomcat on one of the new Apple products based on the 
Apple Mac silicon ARM64 architecture.


Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in 
the near future?


Thanks,

Chris Kimball

Redding, CT


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Prometheus on Apache Tomcat multiple tomcat Instances

[logo]

Melvin,


> Am 16.01.2023 um 14:52 schrieb Melvin Oosterveen 
> :
> 
> 
> Hi all,
> 
> I'm currently working on Apache Tomcat stacks within my company and I would 
> like to integrate Prometheus into our deployments. We have decided to go for 
> the Advanced Configuration - Multiple Tomcat Instances on UNIX systems 
> described in the RUNNING.txt.
> 
> Does anyone have some experience with the setup of the JMX Prometheus 
> exporter using multiple Tomcat instances? My goal is to have a separate Java 
> process (Prometheus) started when I start an Apache Tomcat instance.
> 

in my case the prometheus java agent is tied 1:1 to a tomcat process. In my 
understanding, that would mean 1 prometheus exporter per tomcat (each on a 
different port of course).


> So far I have downloaded the JMX 
> exporter and added it to the 
> created Tomcat Instance with a minimal Prometheus configuration.
> 

As per the github page jmxagent is the recommended way and not the standalone 
http server (which queries tomcat remotely on the jmx port).
Can you explain which one you are really trying to use?

> ```bash
> 
> [root@melvin prometheus]# cat config.yml
> 
> hostPort: localhost:

is tomcat listening on this port with jmx? You are trying to query jmx on this 
host on this port (your tomcat process). But did you start the prometheus 
exporter as a separate java process?
java -jar jmx_prometheus_httpserver-0.17.2.jar 12345 config.yaml
prometheus >> exporter:12345 >> tomcat: (jmx)
> 
> rules:
> 
> - pattern: ".*"
> 
> ```
> 

> I have created a service file which allows me to start the Apache Tomcat 
> instances separately from each other. Inside this configuration I tried to 
> start the Prometheus Java process, but so far I have failed and the Java 
> process won't expose itself on the configured port.
> ```bash
> 
> [root@melvin prometheus]# cat /etc/systemd/system/tomcat-10@.service
> 
> [Unit]
> 
> Description=Tomcat - instance %i
> 
> After=syslog.target network.target
> 
> 
> [Service]
> 
> Type=forking
> 
> 
> User=tomcat
> 
> Group=tomcat
> 
> 
> WorkingDirectory=/var/tomcat/%i
> 
> 
> Environment="JAVA_HOME=/etc/alternatives/jre_openjdk"
> 
> Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom 
> -Djavaagent:/var/tomcat/tomcat10/lib/jmx_prometheus_javaagent-0.17.2.jar=10080:/var/tomcat/tomcat10/prometheus/config.yml"

At this point you are using the jmxagent - inside the tomcat process. Then you 
MUST leave out the hostPort. Did you try to curl localhost:10080 ? 

prometheus >> tomcat:10080 >> internal jmx lookup
If you really want to use the external exporter, you will have to configure jmx 
in JAVA_OPTS instead to run on port . I'm not sure if the following is 
enough or too much:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port= 
-Dcom.sun.management.jmxremote.rmi.port=10002 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

> Environment="CATALINA_PID=/var/tomcat/%i/run/tomcat.pid"
> 
> Environment="CATALINA_BASE=/var/tomcat/%i/"
> 
> Environment="CATALINA_HOME=/opt/tomcat/10/"
> 
> Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"
> 
> 
> ExecStart=/opt/tomcat/10/bin/startup.sh
> 
> ExecStop=/opt/tomcat/10/bin/shutdown.sh
> 
> 
> #RestartSec=10
> 
> #Restart=always
> 
> 
> [Install]
> 
> WantedBy=multi-user.target
> 
> ```
> 
> The instance then starts without errors and starts my sample.war application 
> which I have downloaded from Apache.org. The initiated Java process is even 
> shown.
> ```bash
> 
> tomcat115910   1  0 Jan12 ?00:02:24 
> /etc/alternatives/jre_openjdk/bin/java 
> -Djava.util.logging.config.file=/var/tomcat/tomcat10//conf/logging.properties 
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
> -Djava.security.egd=file:///dev/urandom 
> -Djavaagent:/var/tomcat/tomcat10/lib/jmx_prometheus_javaagent-0.17.2.jar=10080:/var/tomcat/tomcat10/prometheus/config.yml
>  -Djdk.tls.ephemeralDHKeySize=2048 
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M -Xmx1024M 
> -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath 
> /opt/tomcat/10//bin/bootstrap.jar:/var/tomcat/tomcat10//bin/tomcat-juli.jar 
> -Dcatalina.base=/var/tomcat/tomcat10/ -Dcatalina.home=/opt/tomcat/10/ 
> -Djava.io.tmpdir=/var/tomcat/tomcat10//temp 
> org.apache.catalina.startup.Bootstrap start
> 
> ```
> 

> I wonder if anyone could help me out with the right setup of Prometheus on 
> Apache Tomcat multiple tomcat Instances.
> 

I would go the javaagent route and get one tomcat fixed - then all others will 
work easily. To get authentication right, put a haproxy (or an Apache httpd if 
it already exists) in front of your exporter, so you can limit queries to your 
prometheus host.

> Thanks in advance,
> 
> Melvin Oosterveen


Hope this helps.

Peter

Prometheus on Apache Tomcat multiple tomcat Instances

[Melvin Oosterveen]

Hi all,

I'm currently working on Apache Tomcat stacks within my company and I would 
like to integrate Prometheus into our deployments. We have decided to go for 
the Advanced Configuration - Multiple Tomcat Instances on UNIX systems 
described in the RUNNING.txt.

Does anyone have some experience with the setup of the JMX Prometheus exporter 
using multiple Tomcat instances? My goal is to have a separate Java process 
(Prometheus) started when I start an Apache Tomcat instance.

So far I have downloaded the JMX 
exporter and added it to the 
created Tomcat Instance with a minimal Prometheus configuration.

```bash

[root@melvin prometheus]# cat config.yml

hostPort: localhost:

rules:

- pattern: ".*"

```

I have created a service file which allows me to start the Apache Tomcat 
instances separately from each other. Inside this configuration I tried to 
start the Prometheus Java process, but so far I have failed and the Java 
process won't expose itself on the configured port.
```bash

[root@melvin prometheus]# cat /etc/systemd/system/tomcat-10@.service

[Unit]

Description=Tomcat - instance %i

After=syslog.target network.target


[Service]

Type=forking


User=tomcat

Group=tomcat


WorkingDirectory=/var/tomcat/%i


Environment="JAVA_HOME=/etc/alternatives/jre_openjdk"

Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom 
-Djavaagent:/var/tomcat/tomcat10/lib/jmx_prometheus_javaagent-0.17.2.jar=10080:/var/tomcat/tomcat10/prometheus/config.yml"

Environment="CATALINA_PID=/var/tomcat/%i/run/tomcat.pid"

Environment="CATALINA_BASE=/var/tomcat/%i/"

Environment="CATALINA_HOME=/opt/tomcat/10/"

Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"


ExecStart=/opt/tomcat/10/bin/startup.sh

ExecStop=/opt/tomcat/10/bin/shutdown.sh


#RestartSec=10

#Restart=always


[Install]

WantedBy=multi-user.target

```

The instance then starts without errors and starts my sample.war application 
which I have downloaded from Apache.org. The initiated Java process is even 
shown.
```bash

tomcat115910   1  0 Jan12 ?00:02:24 
/etc/alternatives/jre_openjdk/bin/java 
-Djava.util.logging.config.file=/var/tomcat/tomcat10//conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.security.egd=file:///dev/urandom 
-Djavaagent:/var/tomcat/tomcat10/lib/jmx_prometheus_javaagent-0.17.2.jar=10080:/var/tomcat/tomcat10/prometheus/config.yml
 -Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M -Xmx1024M 
-server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath 
/opt/tomcat/10//bin/bootstrap.jar:/var/tomcat/tomcat10//bin/tomcat-juli.jar 
-Dcatalina.base=/var/tomcat/tomcat10/ -Dcatalina.home=/opt/tomcat/10/ 
-Djava.io.tmpdir=/var/tomcat/tomcat10//temp 
org.apache.catalina.startup.Bootstrap start

```

I wonder if anyone could help me out with the right setup of Prometheus on 
Apache Tomcat multiple tomcat Instances.

Thanks in advance,

Melvin Oosterveen

Re: Query: HSTS | Tomcat 9.0.50

[Olaf Kock]

On 16.01.23 06:57, Deepti Sharma S wrote:

Hello Team,

Can you please help us for below query:

Query : How to enable HSTS in Apache Tomcat on non-default ports?
  We have custom ports for http and https and we want to enable HSTS on 
those custom ports.

Note: We could see HSTS is working with default ports 80/443 though it's not 
working on other custom ports, please let us know if there are different steps 
to enable HSTS on non-default ports.


In order to "work", HSTS *must* be on https, by specification.

When you say you got it working on 80/443, you haven't. You might see 
the headers, but it's not working. Most likely the header is ignored by 
the browser.


Whereever you handle your https termination - that might be on Tomcat, 
or on a reverse proxy that sees traffic before Tomcat does - you'll best 
do the HSTS handling. /That/ server knows it's serving https. And there 
the header actually is valid and working.


If you try to configure a http (not https) connector on Tomcat for 
adding the HSTS headers, it's well within the specification to ignore 
that setting.


Technically you can do some trickery around that, but to make that 
sensible and safely would take more than a quick answer. And leave room 
for misinterpretation and configuration mistakes. So: Configure it 
anyhwere you terminate https, and ignore it on http.


Olaf



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org