Re: Context Name replacement variable for conf/context.xml

2022-10-02 Thread Christopher Schultz



Kok Hoor,

On 10/1/22 10:20, Chew Kok Hoor wrote:

I would like to configure $CATALINA_BASE/conf/context.xml to set up
a Manager


Don't do this.

but would like to add the context name as one of the 
parameters to the manager (keyPrefix).


It's much easier to copy webapps/manager/META-INF/context.xml to 
CATALINA_BASE/conf/Catalina/localhost/keyPrefix-manager.xml and allow it 
so auto-deploy to that context-path.


Is there a variable or a list of variables I can use for this 
purpose? As using environment or java defined variables will not fit

this use case.
If you can't use system properties or environment variables, then what 
options do you actually have?


-chris

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



Re: Install CA signed certificate on Tomcat 9

2022-09-29 Thread Christopher Schultz

Veni,

On 9/29/22 13:21, Janardhanan, Veni wrote:

Hi,

My Tomcat version is 9. I am trying to install a CA signed certificate on 
Tomcat, tomcat error log says Invalid Keystore format.
Followed instructions given in 
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Installing_a_Certificate_from_a_Certificate_Authority


What kind of keystore are you using? Please post the output of this command:

$ keytool -list -keystore [path to keeystore]

Please post your  with all secrets removed.

-chris


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



Re: MaxRequestWorkers error

2022-09-27 Thread Christopher Schultz

Koustav,

On 9/27/22 11:09, Naha, Koustav wrote:
We have Tomcat and Apache installed in our production environment since 
5/6 years. Everything was going fine until we started getting 
application not responding status from users, upon checking we found out 
that there was a MaxRequest error as below,


  * In Apache log we have found this error.

[Tue Sep 20 10:48:08.134955 2022] [mpm_event:error] [pid 23940:tid 
140413844547328] AH00484: server reached MaxRequestWorkers setting, 
consider raising the MaxRequestWorkers setting


  * we have seen the below error on tomcat logs


Your attachment has been removed from the mailing list. Can you please 
provide a text-only description of the problem?


We increased 16gb memory on both servers , now we have 32 Gb memory in 
each servers. But the issue still is there.


You could have 1TiB of memory on your server and it would not solve the 
issue you are reporting.



Suddenly we start getting the error and we have to restart Tomcat and
Apache.

FAQ:

 1. Need permeant Solution on this as restarting the instances has
became too frequent these days.
 2. We increased MaxRequestWorker value 400 from 200.


 StartServers 3
 MinSpareThreads 75
 MaxSpareThreads250
 ThreadsPerChild 25
 MaxRequestWorkers  400
 MaxConnectionsPerChild   0



Your error message says "[mpm_event:error]" which suggests you are using 
the "event" MPM and not the "worker" MPM. You have configured the 
"worker" MPM above. Do you have a different config section for 
mpm_event_module?


Another relevant setting is "ServerLimit".


 3. Database and network team reported no unusual activity during the issue.


Good. That suggests you don't actually have a "problem". You are just 
hitting the limits imposed by your configuration.



 4. Code is refreshed every month , no issue found on coding side.
 5. While the issue starts the server becomes low on memory.


If you are running httpd and Tomcat on the same machine, my guess is 
that the memory increase is due to additional load on the application, 
not the web server. The web server should be using minimal memory 
compared to your application.


-chris

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



Re: certificate re-loading for apache tomcat without the apache restart

2022-09-26 Thread Christopher Schultz

Raghavendran,

On 9/26/22 7:43 AM, Ragavendhiran Bhiman (rabhiman) wrote:

Is there any way to reload new certificates as well with restarting the tomcat 
services?


Yes, but you will have to use JMX to essentially re-configure the 
connector, and then reload/restart it.



The mail below explains the modification of certificates only considered and 
not the new ones.
Our scenario is to load new certificates as well if the nssdb got changed 
dynamically.


Usually a "new" certificate would be one that doesn't just replace an 
existing one, but requires a separate , etc.


Maybe if you explain what you are really trying to do, we could give you 
better help.


-chris


From: Ivano Luberti 
Date: Monday, 26 September 2022 at 12:51 PM
To: users@tomcat.apache.org 
Subject: Re: certificate re-loading for apache tomcat without the apache restart
Agree

Here you can find documentation of what Peter says

https://tomcat.apache.org/tomcat-10.0-doc/manager-howto.html#Reload_TLS_configuration

using  a call to the manager app.

It doesn't take into account new certificates but only existing ones,
because it dosn't reparse server.xml

Il 26/09/2022 09:18, l...@kreuser.name ha scritto:

Raghavendran,


Am 26.09.2022 um 08:54 schrieb Ragavendhiran Bhiman 
(rabhiman):

Hi All,

I have a scenario where I need to reload the certificates which are newly 
updated in the NSS DB without restarting the apache – tomcat.
Is there any way to do it?

Kindly share some piece of code to achieve the reloading of the certificates 
without restarting the apache tomcat service itself.



curl -u  -p  
"https://myserver.mydomain/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port==reloadSslHostConfig="

you need that  with at least roles="manager-jmx" in tomcat-users.xml



Note : Trial from my side : Tried to restart the Apache connector, but still it 
is reloading the old certificates only and not the new certificates.
If possible how to achieve the loading of the new one?


Many Thanks for your help.

Regards,

Raghavendran


Hope this helps

Peter

--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
2003 n. 196
per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: 
www.linkedin.com/in/ivanoluberti
facebook: 
www.facebook.com/archimedeinformaticapisa/



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



Re: Tomcat 8.5.8x patch upgrade failing

2022-09-26 Thread Christopher Schultz

Doug,

On 9/23/22 11:20 AM, Cannatella, Douglas wrote:

We are currently using Tomcat 8.5.53 and tried to upgrade patch
8.5.81 & 8.5.82 using Ivanti Patch tool.

Did it work?


Our project is using OpenJDK version: 1.8.0_242, Microsoft
Framework 4.0.0 running TR/ OneSource Indirect Tax Determination

That sounds like a fun environment.


Ivanti patch tool has overlayed Tomcat service running on the D
drive, on the C drive including war files and registry settings.
Sounds great. Is that what it's supposed to do? We don't know anything 
about Ivanti.



Is there any way to manual install patches to keep Tomcat version
8.5.82 current on the D drive which is running Catalina under Windows
2019 Server.
The Apache Tomcat project periodically produces new versions of 
supported versions of Apache Tomcat. All 4 currently-supported major 
versions (8.5, 9.0, 10.0, and 10.1) receive roughly monthly patch releases.


The Apache Tomcat team does not distribute actual patches. Instead, we 
release new versions of the complete package. It should be easy to stay 
up-to-date if you are comfortable with Apache Tomcat. Simply download 
and install the update whenever it becomes available.


Here are two resources you might want to refer to:

https://tomcat.apache.org/presentations.html#latest-split-installation

https://github.com/Bill-Stewart/ApacheTomcatSetup

Generally, releases within the same major version (e.g. 8.5.x) are all 
compatible, but READ THE CHANGELOG 
(https://tomcat.apache.org/tomcat-8.5-doc/changelog.html) to see if 
anything might affect your environment. You are upgrading past a LOT of 
revisions, so you will haev to do a lot of reading.


Also read the MIGRATION GUIDE 
(https://tomcat.apache.org/migration.html), especially the "Notable 
Changes" section for your version(s).



Do I need capture logs which one's and capture Tomcat access
log
, or threadumps?
You only need to do such things if you care to do so. Thread dumps are 
only useful if you are experiencing a problem. Logs can either be useful 
or not, depending on your needs.



Next steps to download Tomcat manual installation on DEV
environment? Next step to download Apache Tomcat(r) - Apache Tomcat 8
Software Downloads
windows-x64.zip?
Yes, that's the right place to get the latest ZIP distribution of Apache 
Tomcat.



https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics
Apache Tomcat 8 (8.5.82) - Tomcat 
Setup


Yes, that's a good place to get started.

-chris

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



Re: [OT] which missing file prevents tomcat 10 from starting as windows service ?

2022-09-21 Thread Christopher Schultz

Chuck lives!

On 9/21/22 08:58, Chuck Caldarale wrote:

[2022-09-19 13:09:07] [debug] ( javajni.c:817 ) [ 7652] JVM Option[12] 
-Djava.class.path=c:\Dematic\apache-tomcat-10.0.23\bin\bootstrap.jar;c:\Dematic\apache-tomcat-10.0.23\bin\tomcat-juli.jar
[2022-09-19 13:09:07] [debug] ( javajni.c:817 ) [ 7652] JVM Option[13] exit
[2022-09-19 13:09:07] [debug] ( javajni.c:817 ) [ 7652] JVM Option[14] abort
[2022-09-19 13:09:07] [debug] ( javajni.c:817 ) [ 7652] JVM Option[15] -Xms128m
[2022-09-19 13:09:07] [debug] ( javajni.c:817 ) [ 7652] JVM Option[16] -Xmx256m



The above JVM options include “exit” and “abort”, which seems rather odd. The 
JVM may be looking for files with those names.

   - Chuck


-
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: HOW TO ENABLE LDAPS ON TOMCAT 8.5

2022-09-21 Thread Christopher Schultz



Rakesh,

On 9/20/22 17:56, rakesh meka wrote:

I will just ask the my AD team to provide the CA certificate which is
already installed on the AD domain controller and then place it in client
(tomcat web server) trust store if it is not official.


If you post your configuration, we may be able to help point you in the 
right direction.



Apart from this, i have done some much R in this concern but found mixed
answers. By if you have an idea, can you please share any insights.

While generating keystore/csr for SSL/TLS using keytool, I used RSA and my
CA Team wants me to use 4096 as keysize. And when i configured. I recieve
certificate is invalid in browser.


The browser is telling you that the certificate is *untrusted*, not invalid.


Then the first question raised is does keytool RSA support 4096 or
only 2048 keysize encryption. Java 1.8
Java supports arbitrary key sizes up to 16384 for RSA keys. Oddly 
enough, keytool for Java 8 will tell you that's the maximum. Later 
versions (I used 16.something) will just say "invalid key size" for 
those larger than 16k.


-chris


On Mon, Sep 19, 2022, 12:09 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:


Hello,


-Ursprüngliche Nachricht-
Von: rakesh meka 
Gesendet: Sonntag, 18. September 2022 22:57
An: Tomcat Users List 
Betreff: Re: HOW TO ENABLE LDAPS ON TOMCAT 8.5

Hi Thomas,

Thanks your so much for the quick response and help.

Having read all the response clearly once again.Not sure if I'm being

foolish.


First question:

So here in general, I would like to just summarize that client will be

the

application server where I have tomcat installed & application is

deployed.

Server will the  domain controller server(LDAPs certificate to be

installed as

per the below Microsoft article).

Please correct me if the understanding is correct ?


Yes, private key (e.g. pfx) is installed on the server side, the AD domain
controller, let's call it AD


Second Question:

LDAPs certificate is to be installed domain controller. So that all the

other

apps on different app servers can query by having connection to domain
controller (in other terms LDAPs server).



The server needs the pfx-file (private key) and also the certificates
(end-certificate and intermediates if not already present).
The private key is stored secretly and the certificate + intermediates are
sent to the client during initial handshake.



Third Question:

Domain controller does already have the required certificates installed

for

LDAP authentication already because previously when I tried with port
no:389. I could see successful LDAP Connection established & user could
login successfully.

So now inorder to change from LDAP to LDAPS. Can now please let me know
the how could I proceed further

IF LDAPS certificate to installed on the APPLICATION SERVER:
-
1. generate the certificate request using keytool. Following the same

process

as per article 2. Csr 3. Get it signed by CA.
4. Keep CA's certificate in Java truststore.
5. Then make the port changes & host(domain/LDAP server name).
6. Restart the tomcat so that webapp is deployed automatically.


The client only needs the CA certificate. Certificate requests are not
needed, this is only done once for the server part.
If an official CA was used (e.g. verisign), then the java client normally
already has the CA certificate in the truststure.
If not, you have to import the CAs certificate. The URL hast to change to
https and the LDAPS-port 636.

The client needs to be able to validate the certificate. For this
validation, the certificates which are sent by the server are used
(end-certificate, intermediates)
and last but not least the CA certificate is used. This builds up a
validation chain from the root-CA, intermediates up to the end-certificate.
As the client trusts the root-CA, it also can trust the servers
certificate (end-certificate).


Thanks & Regards,
Meka Rakesh.



On Sun, Sep 18, 2022, 4:46 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:


Hello,


-Ursprüngliche Nachricht-
Von: rakesh meka 
Gesendet: Sonntag, 18. September 2022 11:53
An: Tomcat Users List 
Betreff: Re: HOW TO ENABLE LDAPS ON TOMCAT 8.5

Hi Thomas,

Good day

Thanks for the Response.

I'm not using self signed certificate. I have given the csr file to
our organization certificate admin team. And they got it signed by
some third party vendor and gave me root& intermediate 
certificate where I already installed them using keytool on server
side. However, I didn't

kept

those in Java truststore.

So I confirm that domain certificate is not self signed.

I got to know from one of my colleague that for LDAPs also we need
to generate certificate similarly like domain certificate. Is it
true?  If

yes can you

let me how to generate the certificate for LDAPs.

Application: used by internal purpose Server : windows
server(actually LDAP authentication certificate is

already

configured with windows truststore 

Re: tomcats starting with 200 threads

2022-09-21 Thread Christopher Schultz

Jon,

Try using an . You are using a non-nuanced configuration and 
will therefore get inflexible threading behavior.


Thanks,
-chris

On 9/20/22 02:47, Jonathan Yom-Tov wrote:

hi Christopher,

Configuration follows:



   
   
   
   
   
   
   
   


   

 


 

   

 

   
   



   
  
 
   







On Mon, Sep 19, 2022 at 7:45 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Jon,

On 9/19/22 10:46, Jonathan Yom-Tov wrote:

Sometimes one of our production Tomcats will start with the maximum (200)
number of threads in the https pool. That is, it doesn't start with some
minimum and works its way up to the maximum, it immediately starts with

the

maximum. There's no reason for it since most of the threads stay idle
through the lifetime of the Tomcat. The issue is that this takes up

memory

and eventually something pushes the Tomcat over the edge and it dies with
an out of memory error. Any ideas on how to debug or solve this?

The Tomcat version is 9.0.64.0, running on Amazon Linux 2 (amd64) and

Java

Corretto 1.8.0_312-b07.


Can you post your configuration?

-chris

-
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: tomcats starting with 200 threads

2022-09-19 Thread Christopher Schultz

Jon,

On 9/19/22 10:46, Jonathan Yom-Tov wrote:

Sometimes one of our production Tomcats will start with the maximum (200)
number of threads in the https pool. That is, it doesn't start with some
minimum and works its way up to the maximum, it immediately starts with the
maximum. There's no reason for it since most of the threads stay idle
through the lifetime of the Tomcat. The issue is that this takes up memory
and eventually something pushes the Tomcat over the edge and it dies with
an out of memory error. Any ideas on how to debug or solve this?

The Tomcat version is 9.0.64.0, running on Amazon Linux 2 (amd64) and Java
Corretto 1.8.0_312-b07.


Can you post your configuration?

-chris

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



Re: HOW TO ENABLE LDAPS ON TOMCAT 8.5

2022-09-19 Thread Christopher Schultz

Rakesh,

On 9/17/22 23:02, rakesh meka wrote:

Currently of the application is deplye Don the tomcat 8.5 uses LDAP
protocol for AD authentication of sap users. I need to change the LDAP to
LDAPS. So I installed domain certificate using keytool. But when i change
the port number to 636 I see an error saying LDAP Connection has been
closed.

I need your help to how to enable the process for enabling/Changing LDAPS.
Do I need to import the LDAP certificate to the tomcat truststore and then
import certificate to keystore ?


Can you please post your WORKING non-secure LDAP configuration back to 
the list? When asking about how to configure things, please always 
include the configuration you already have.


Please remember to remove any secrets that may be in your configuration 
before posting.


-chris

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



Re: Unexpected double-slash in javax.servlet.forward.request_uri

2022-09-19 Thread Christopher Schultz

All,

On 8/24/22 14:15, Christopher Schultz wrote:
I haven't tried narrowing this down very much yet, but I have a 
situation where I'm using javax.servlet.forward.request_uri to build a 
URI and the string I'm pulling from there starts with TWO / characters 
instead of one.


This ends up breaking navigation because the browser interprets this as 
a protocol-relative URI instead of a host-relative URI and Bar Things 
happen.


Has anyone ever seen anything like this?

Tomcat 8.5.latest.


I believe I have located the source of this. I'm using mod_proxy, 
mod_proxy_http, and mod_proxy_balancer to front Tomcat with httpd. Here 
was my balancer confioguration:



  BalancerMember http://localhost:8217/
  ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On


And here was an example ProxyPass directive that I tried with the 
Examples web app in order to determine if my application was responsible 
(it wasn't).


ProxyPass /examples/ balancer://my-balancer/examples/

That trivially reproduces the problem when visiting:
http://localhost/examples/servlets/servlet/RequestInfoExample

The problem is that my "balancer" configuration contains a trailing / 
character, and should have been:


  BalancerMember http://localhost:8217

(Note the missing trailing-slash.)

It's frustrating that it's so easy to make configuration errors like that.

-chris

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



Re: How to check no of user request coming in tomcat application in a minute

2022-09-08 Thread Christopher Schultz

Priyanka,

On 9/8/22 13:20, Kumawat, Priyanka wrote:
Do you want to be able to pick an arbitrary minute, or are you 
more interested in e.g. "the most recent minute or activity"?


We wanted to count the number of users hitting the application on 
tomcat/Apache , as an example for today how many users hits/send

request to the application


Requests != users.


How shall we check this request , please suggest.


I think you need to have a more well-defined question.

For example:

For a given day, we'd like to know how many requests we get per-minute, 
so we want data that looks like this:


date,hour,minute,request_count
2022-09-08,00,01,123
2022-09-08,00,02,456
2022-09-08,00,03,789
2022-09-08,00,04,876
2022-09-08,00,05,256
...

If you want to know the number of users, you'll have to define "user". 
And you probably won't be able to get that information from the 
access-log without some additional work. If you mean "established user 
session", then you'll have to probe Tomcat to find out how many sessions 
exist on whatever schedule you want. If you mean "established session 
with authentication" then you'll have to do a different kind of probe.


If you want to know how many unique authenticated-users made requests 
during a specific minute, that's yet another question and one that CAN 
be answered by looking at the access-log, as long as you add some 
convenient information to it (the user principal) and then use some 
text-processing tools to collate the information.


-chris


-Original Message-
From: Christopher Schultz 
Sent: 08 September 2022 20:04
To: users@tomcat.apache.org
Subject: Re: How to check no of user request coming in tomcat application in a 
minute

Koustav,

On 9/8/22 10:06, Naha, Koustav wrote:

Just want to know how can we calculate the number of user request processed by 
tomcat in a particular minute.


Do you want to be able to pick an arbitrary minute, or are you more interested in e.g. 
"the most recent minute or activity"?


Can we do it from Apache access logs?


Sure.

$ grep '08/Sep/2022:14:32:' access.log | wc


Version

*   Tomcat 8.5.5


Ouch. That version is 6 years old with published security vulnerabilities. I 
strongly suggest that you upgrade ASAP.


*   Apache 2.4


I'm gonna guess that this is out-of-date, too. Latest is 2.4.54 from back in 
June 2022.

-chris

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



DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

-
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: Get more debug information?

2022-09-08 Thread Christopher Schultz

Hua,

On 9/8/22 10:30, Hua Zhang wrote:

Hi Tomcat,

I have a question about how to get more debug information in a tomcat log
file. Sometimes my websites, which run on tomcat 9.0.43, suddenly all went
down without a good reason.


You might want to consider an upgrade. That version of Tomcat is 18 
months old.



When this happens, the only thing I can do is restart the Tomcat service.

I am trying to figure out why it happened, however in the log file
(catalina.out), there is just a repeated bunch of java NullPointerException.

[2022-09-07 21:44:01] [crit] Error processing request
[2022-09-07 21:44:01] [crit] java.lang.NullPointerException
[2022-09-07 21:48:59] [crit] Error processing request
[2022-09-07 21:48:59] [crit] java.lang.NullPointerException
[2022-09-07 21:54:48] [crit] Error processing request
[2022-09-07 21:54:48] [crit] java.lang.NullPointerException

So my question is: is there a way to get more debug information in the log
file? If so, how?


Can you post the contents of your logging.properties file? My guess is 
that you have changed it from the default. Better yet -- can you send a 
'diff' of your file relative to the stock logging.properties file that 
shipped with your Tomcat package?


-chris

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



Re: How to check no of user request coming in tomcat application in a minute

2022-09-08 Thread Christopher Schultz

Koustav,

On 9/8/22 10:06, Naha, Koustav wrote:

Just want to know how can we calculate the number of user request processed by 
tomcat in a particular minute.


Do you want to be able to pick an arbitrary minute, or are you more 
interested in e.g. "the most recent minute or activity"?



Can we do it from Apache access logs?


Sure.

$ grep '08/Sep/2022:14:32:' access.log | wc


Version

   *   Tomcat 8.5.5


Ouch. That version is 6 years old with published security 
vulnerabilities. I strongly suggest that you upgrade ASAP.



   *   Apache 2.4


I'm gonna guess that this is out-of-date, too. Latest is 2.4.54 from 
back in June 2022.


-chris

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



Re: PGP key missing for 9.0.65

2022-08-29 Thread Christopher Schultz

Arno,

On 8/28/22 22:38, Arno Hautala wrote:

You aren't using the KEYS file in the above command. gpg works with
keyrings, and you have to import then use it:

# Import
$ gpg --import --no-default-keyring --primary-keyring apache-9.0-keys < KEYS

# Verify against the custom key ring
$ gpg --keyring apache-9-keys --no-default-keyring --verify
apache-tomcat-9.0.65.tar.gz.asc



Ah, the KEYS files are different for each Tomcat release.


Correct.


I must have downloaded the file for 8 or 10 and tried to use it with 9.


That will do it :)


And some of the keys aren’t published to a server.


Can you give me an example?


I re-downloaded and was able to verify the files.

And thanks for the tip about the alternate keyring. That keeps things organized.


Sure. It's part of how I test each release. [1]

-chris

[1] 
https://github.com/ChristopherSchultz/apache-tomcat-stuff/blob/master/bin/test-tomcat-release.sh


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



Re: PGP key missing for 9.0.65

2022-08-26 Thread Christopher Schultz

Arno,

On 8/26/22 08:50, Arno Hautala wrote:

I’m trying to verify the PGP signatures for the 9.0.65 release, but the public 
key is missing from the KEYS.txt file and it isn’t available on any keyservers 
that I’ve checked.

Can someone point me in the right direction or update the KEYS.txt?

Thanks for your help,
–Arno



$ sha512sum -c apache-tomcat-9.0.65.tar.gz.sha512.txt
apache-tomcat-9.0.65.tar.gz: OK
$ gpg --verify apache-tomcat-9.0.65.tar.gz{.asc.txt,}
gpg: Signature made Thu Jul 14 08:36:27 2022 EDT
gpg:using RSA key 48F8E69F6390C9F25CFEDCD268248959359E722B
gpg: requesting key 68248959359E722B from hkp server pgp.mit.edu
gpg: Can't check signature: No public key


You aren't using the KEYS file in the above command. gpg works with 
keyrings, and you have to import then use it:


# Import
$ gpg --import --no-default-keyring --primary-keyring apache-9.0-keys < KEYS

# Verify against the custom key ring
$ gpg --keyring apache-9-keys --no-default-keyring --verify 
apache-tomcat-9.0.65.tar.gz.asc


-chris

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



Re: AW: Unexpected double-slash in javax.servlet.forward.request_uri

2022-08-25 Thread Christopher Schultz

Thomas,

On 8/25/22 11:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Chris,
I think I misread your message, sorry.
So the request attribute javax.servlet.forward.request_uri contained a URL 
starting with // , right?

Do you have the initial http request, how it looks like?


As I said, I haven't traced-through this the whole way. It's entirely 
possible that some component in my own product is doing this.


I've never seen it when deployed into a real environment. This kind of 
thing only happens when I'm using "localhost".


-chris



Von: Christopher Schultz 
Gesendet: Mittwoch, 24. August 2022 20:15:25
An: Tomcat Users List
Betreff: Unexpected double-slash in javax.servlet.forward.request_uri

All,

I haven't tried narrowing this down very much yet, but I have a situation where
I'm using javax.servlet.forward.request_uri to build a URI and the string I'm
pulling from there starts with TWO / characters instead of one.

This ends up breaking navigation because the browser interprets this as a
protocol-relative URI instead of a host-relative URI and Bar Things happen.

Has anyone ever seen anything like this?

Tomcat 8.5.latest.

-chris

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



-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH)

Gesendet: Donnerstag, 25. August 2022 10:48
An: Tomcat Users List 
Betreff: AW: Unexpected double-slash in javax.servlet.forward.request_uri

Hello Chris,

I think it matches the RFC7231
https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2

It allows relative URLs which refers to:
https://www.rfc-editor.org/rfc/rfc3986#section-4.2

Which allows protocol relative paths:
relative-part = "//" authority path-abempty
 / path-absolute
 / path-noscheme
 / path-empty

Greetings, Thomas


-
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



Unexpected double-slash in javax.servlet.forward.request_uri

2022-08-24 Thread Christopher Schultz

All,

I haven't tried narrowing this down very much yet, but I have a 
situation where I'm using javax.servlet.forward.request_uri to build a 
URI and the string I'm pulling from there starts with TWO / characters 
instead of one.


This ends up breaking navigation because the browser interprets this as 
a protocol-relative URI instead of a host-relative URI and Bar Things 
happen.


Has anyone ever seen anything like this?

Tomcat 8.5.latest.

-chris

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



Re: Tomcat Native and macOS 10.15.7

2022-08-24 Thread Christopher Schultz

Thad,

On 8/23/22 10:49, Thad Humphries wrote:

On Tue, Aug 23, 2022 at 10:18 AM Mark Thomas  wrote:


On 23/08/2022 14:12, Thad Humphries wrote:

I'm trying to understand a problem I'm having with Tomcat Native since
moving from 1.2.x to 2.0.

For several years I have been running Tomcat 9.0.12 in Eclipse and 9.0.37
for localhost on my home and office Mac Mini's with macOS 10.15.7

Catalina.

Both use OpenJDK 8 from Amazon. To support development I have a

self-signed

certificate and until recently used Tomcat Native 1.2.x installed with
Homebrew. I added `CATALINA_OPTS="-Xmx1024m
-Djava.library.path=/usr/local/opt/tomcat-native/lib"` to my

bin/setevn.sh


With this configuration I was able to the
connector org.apache.coyote.http11.Http11AprProtocol with UpgradeProtocol
for org.apache.coyote.http2.Http2Protocol

Recently Homebrew replaced Tomcat Native 1.2.x with 2.0.1. Since then

when

Tomcat starts I see in catalina.out "The Apache Tomcat Native library

which

allows using OpenSSL was not found on the java.library.path:
[/usr/local/opt/tomcat-native/lib]". I've had to switch my development to
connector org.apache.coyote.http11.Http11NioProtocol (I need SSL for my
client-server setup).

I've tried using a Tomcat Native 2 I built myself, but get the same "not
found on the java.library.path" message. I tried using a Tomcat Native
1.2.35 I built myself but got the following stacktrace in catalina.out

23-Aug-2022 03:07:29.541 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded

Apache

Tomcat Native library [1.2.35] using APR version [1.7.0].
23-Aug-2022 03:07:29.541 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false],

random

[true].
23-Aug-2022 03:07:29.541 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
23-Aug-2022 03:07:29.544 SEVERE [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Failed to
initialize the SSLEngine.
org.apache.tomcat.jni.Error: 70023: This function has not been

implemented

on this platform
at org.apache.tomcat.jni.SSL.initialize(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at


sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at


sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
at


org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:289)

at


org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:136)

at


org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)

at


org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:135)
at org.apache.catalina.startup.Catalina.load(Catalina.java:690)
at org.apache.catalina.startup.Catalina.load(Catalina.java:712)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at


sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at


sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)

What is the issue I'm seeing and how might it be corrected if I want to

run

Tomcat Native for the APR protocol?


You can't.

The APR connector has been deprecated and has been removed in Tomcat
10.1.x onwards.

Tomcat Native 2.0.x does not support the APR connectors.

You need to switch to NIO or NIO2. If you want to use OpenSSL for TLS
then you can do so (you'll need Tomcat Native 2.0.x and OpenSSL). Look
at the docs for the sslImplementationName attribute.


BTW, this is not critical to me; I can live with NIO. However I'm the

*only*

person on this team who pays any attention to Tomcat, and I may be having
to explain this to my coworkers and our boss. Others use a mix of Linux,
Windows, and Mac. Most don't use SSL internally but some use the AJP
connector for Apache, and IIRC that needs Tomcat Native, too.


AJP does not require APR/Native. There are NIO and NIO2 implementations
for AJP.

Mark



Thank you, Mark. That all makes sense. I'll look at the docs you've
referenced. I recall once watching some YouTube videos on Tomcat
connectors. I'll find and rewatch those, too.


Some additional details:

tcnative 2.x, while not supporting the APR connector, supports 
everything you need for native cryptographic operations via OpenSSL. It 
likely works with LibreSSL as well but there hasn't been significant 
testing done, there.


Switching from APR to NIO+tcnative+OpenSSL should give you a reasonably 
efficient connector which is slightly "safer" 

Re: Tomcat 9.0.65 Clustering in Azure Kubernetes Service (AKS)

2022-08-17 Thread Christopher Schultz

All,

If you are havig issues with the CloudMembershipService, I would highly 
recommend that you continue to have this discussion.


The original author (remm) was mostly targeting OpenShift (he works for 
RedHat, so it's not a surprise) but it doesn't mean that its support 
cannot expand to include other deployments.


If the DNSMembershipService is more appropriate for k8s-on-Azure, that's 
fine, but if there is a community need (and especially if you are 
willing to do the research and contribute code) we'd be happy to 
accomodate you.


-chris

On 8/14/22 03:52, Chew Kok Hoor wrote:

Hi,

 I am trying to setup Tomcat clustering running in AKS, however the
standard settings don't seem to work.

As per the documentation I have setup following Cluster configuration in
server.xml inside my  tag:
  

  

  

But I received a 'Failed connection to
https://10.0.0.1:443/api/v1/namespaces/tomcat/pods' error. Is there any way
to resolve this?

Error message:

INFO: Cluster is about to start
Aug 14, 2022 3:44:26 PM org.apache.catalina.tribes.transport.ReceiverBase
bind
INFO: Receiver Server Socket bound to:[/10.240.0.76:4000]
Aug 14, 2022 3:44:26 PM
org.apache.catalina.tribes.membership.cloud.CloudMembershipProvider
getNamespace
WARNING: Namespace not set
Aug 14, 2022 3:44:26 PM
org.apache.catalina.tribes.membership.cloud.KubernetesMembershipProvider
fetchMembers
SEVERE: Failed to open stream
java.io.IOException: Failed connection to [
https://10.0.0.1:443/api/v1/namespaces/tomcat/pods] with token
[--redacted--]
 at
org.apache.catalina.tribes.membership.cloud.TokenStreamProvider.openStream(TokenStreamProvider.java:56)
 at
org.apache.catalina.tribes.membership.cloud.KubernetesMembershipProvider.fetchMembers(KubernetesMembershipProvider.java:136)
 at
org.apache.catalina.tribes.membership.cloud.CloudMembershipProvider.heartbeat(CloudMembershipProvider.java:127)
 at
org.apache.catalina.tribes.membership.cloud.KubernetesMembershipProvider.start(KubernetesMembershipProvider.java:116)
 at
org.apache.catalina.tribes.membership.cloud.CloudMembershipService.start(CloudMembershipService.java:152)
 at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:192)
 at
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:106)
 at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:190)
 at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:190)
 at
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.start(MessageDispatchInterceptor.java:224)
 at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:190)
 at
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:504)
 at
org.apache.catalina.ha.tcp.SimpleTcpCluster.startInternal(SimpleTcpCluster.java:564)
 at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:908)
 at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
 at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
 at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
 at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
 at
java.base/java.util.concurrent.AbstractExecutorService.submit(Unknown
Source)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
 at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
 at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:432)
 at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
 at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source)
 at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
 at java.base/java.lang.reflect.Method.invoke(Unknown Source)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
 at 

[ANN] Apache Tomcat 8.5.82 available

2022-08-13 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.82.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.82 is a bugfix and feature release. The notable
changes compared to 8.5.82 include:

 - Update the packaged version of the Tomcat Native Library to 1.2.35 to
   pick up Windows binaries built with OpenSSL 1.1.1q.

 - Enable the use of the FIPS provider for TLS enabled Connectors when
   using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.

 - Improvements to HTTP/2 header handling.

 - Fix CVE-2022-34305, a low severity XSS vulnerability in the
   Form authentication example.


Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Re: Simple SSL question

2022-08-12 Thread Christopher Schultz

Peter,

On 8/11/22 17:00, Peter Kreuser wrote:

I have tried all the fancy new cert options and they are cool.

And I do agree that it's more readable.

What would be useful would be one sample how to transfer a simple "old" config 
to SSLHostConfig.


Let's see if a PNG attachment makes it to the list.

It's really straightforward if you read the configuration guide[1], 
especially the section on deprecated configurations[2] which tells you 
where all the old things go in the new-style configuration.


Note that this example is for JSSE-based configuration which uses 
keystores and stuff like that. If you are using the APR/native 
connector, some of the attribute names are different.


-chris

[1] https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
[2] 
https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2_(deprecated)

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

Re: Issue with catalina.out not being generated (RHEL 7.9, tomcat 9.0.63)

2022-08-11 Thread Christopher Schultz

Paul,

On 8/11/22 13:03, Paul Chauvet wrote:

Hi Noelette,

Thanks for the reponse!

It logs to catalina--MM-DD.log, localhost.YY-MM-DD.log, 
localhost_access_log.-MM-DD.txt - but it doesn't use catalina.out.

When I temporarily started Tomcat via startup.sh it did create catalina.out 
(and start logging the things that it wasn't logging into the other files, 
/var/log/messages, or the systemd journal).

I'll see if I can get my setup (at least temporarily) working with startup.sh.


OH... you might just be misunderstanding what's happening.

When you use catalina.sh start (or startup.sh), that script just does this:

java [stuff] > ${CATALINA_BASE}/logs/catalina.out 2>&1

When you run with jsvc, it includes some built-in file-rotation and so 
catalina-[date].log is the same thing.


Are you irritated that you can't read the logs, or are you irritated 
that the log file isn't specifically "catalina.out"?


-chris



From: Noelette Stout 
Sent: Thursday, August 11, 2022 12:35 PM
To: Tomcat Users List 
Subject: Re: Issue with catalina.out not being generated (RHEL 7.9, tomcat 
9.0.63)

CAUTION: Message from a non-New Paltz email server. Treat message, links, and 
attachments with extra caution.


We use systemd with jsvc and our tomcat instances write to
$CATALINA_BASE/logs by default.

On Thu, Aug 11, 2022 at 10:10 AM Paul Chauvet  wrote:


Hello all,

I haven't been able to figure this out - but a catalina.out file is not
being generated for me.  Sadly - I'm trying to troubleshoot an issue (with
a vendor's saml implementation) which wants to write to that file (and
doesn't seem to be writing what I need to catalina.-DD-MM.logs,
/var/log/messages, or into the journal as seen by "journalctl
--unit=tomcat.service").


My environment:

   *   RHEL 7.9 (though the same happens on my RHEL 8 hosts)
   *   Tomcat 9.0.63 (installed from the .tar.gz download from
https://tomcat.apache.org/download-90.cgi - not from the OS repository)
   *   Using jsvc via a systemd startup script to start Tomcat (that script
is at the bottom of this message).

I've tried specifying CATALINA_OUT in setenv.sh, and in my systemd startup
script.  I've temporarily disabled SELinux to see if that makes a
difference.  Neither of those work.  What does work, though I would like to
avoid it, is if I start Tomcat via ./startup.sh.  If I do that -
catalina.out is generated but I'm not getting other settings I set in my
systemd script (or having it tied to startup/shutdown of the OS).

I don't know what I'm missing or doing wrong here, or if there's something
about jsvc that is an issue here that I can't figure out.  I've been unable
to find anything related to this (lots of posts about catalina.out related
to operating system distributed versions of Tomcat that don't appear to
apply).

Any advice here would be greatly appreciated!

My systemd startup script is below.


[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/tomcat.pid
UMask=0007

# Tomcat variables
Environment='JAVA_HOME=/usr/lib/jvm/java-openjdk'
Environment='CATALINA_PID=/var/run/tomcat.pid'
Environment='CATALINA_HOME=/opt/tomcat/latest'
Environment='CATALINA_BASE=/opt/tomcat/latest'
Environment='CATALINA_OPTS=-Xms512M -Xmx2048M -XX:+UseParallelGC -server'
Environment='CATALINA_OUT=/var/log/tomcat/catalina.out'

# Needed to make use of Tomcat Native Library
Environment='LD_LIBRARY_PATH=/opt/tomcat/latest/lib'

ExecStart=/opt/tomcat/latest/bin/jsvc \
 -Dcatalina.home=${CATALINA_HOME} \
 -Dcatalina.base=${CATALINA_BASE} \
 -Djava.awt.headless=true \

-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \

-Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.properties \
 -Dlog4j2.FormatMsgNoLookups=true \
 -cp
${CATALINA_HOME}/bin/commons-daemon.jar:${CATALINA_HOME}/bin/bootstrap.jar:${CATALINA_HOME}/bin/tomcat-juli.jar
\
 -pidfile ${CATALINA_PID} \
 -java-home ${JAVA_HOME} \
 -user tomcat \
 $CATALINA_OPTS \
 org.apache.catalina.startup.Bootstrap

ExecStop=/opt/tomcat/latest/bin/jsvc \
 -pidfile ${CATALINA_PID} \
 -stop \
 org.apache.catalina.startup.Bootstrap

[Install]
WantedBy=multi-user.target







Paul Chauvet, CISSP

Information Security Officer

State University of New York at New Paltz

chauv...@newpaltz.edu




--
Noelette Stout
ITS Enterprise Applications - Senior Application Administrator
Idaho State University
E-mail: stounoel "at" isu "dot" edu
Desk: 208-282-2554



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



Re: Simple SSL question

2022-08-11 Thread Christopher Schultz

Jon,

On 8/11/22 12:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

I was just wondering if there was a vanity name for the "new" structure is all, 
to differentiate in documentation.


*shrug*

"New"?

That kind of loses its lustre after a while. Today, that's just "the way 
you do it". So the "new" way is The Way and the old way is ... the Old Way.


Use SSLHostConfig. I'm sure you'll sleep better at night after you've 
switched.


-chris


-Original Message-
From: Christopher Schultz 
Sent: Thursday, August 11, 2022 11:29 AM
To: users@tomcat.apache.org
Subject: Re: Simple SSL question

Jon,

On 8/11/22 11:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

Is there a "name" for the new connector style? The old is known as the
Coyote Connector.

Coyote is just the name of the connector itself, for whatever reason.
Both the new and old-style configuration is using the same connector
underneath. When you configure everything on the , Tomcat
still creates an SSLHostConfig object under the covers and fills it with that
same data.

Why should you bother migrating? Two reasons:

1. The new configuration is easier to read IMO. It separates the TLS
host/key/certificate and all that associated stuff from the more basic socket-
type stuff for the 

2. It allows for more options such as proper name-based virtual-hosting with
TLS. It also allows multiple types of keys and certificates to be used. For
example, you can configure both RSA and EC certificates for a single host.
That's just not possible with the one-attribute-to-rule-them-all configuration
where everything is on the  element.

-chris


-Original Message-
From: Mark Thomas 
Sent: Wednesday, August 10, 2022 2:43 PM
To: users@tomcat.apache.org
Subject: Re: Simple SSL question

On 10/08/2022 19:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, I'm asking a rather simple, stupid (in my opinion) question, but
here

goes:


What is the best practice form of connector for SSL. Is it the
old-school

coyote connector or the connector with the  section?



The old style isn't supported in Tomcat 10.0.x onwards.


Are the two interchangeable, or does the SSLHostConfig one rely on

openssl and won't work without it? The documentation is confusing me
on a hump day afternoon.

They are interchangeable. However, if you want to configure TLS
virtual hosting with SNI you'll need to use SSLHostConfig.

Both approaches can be used with JSSE and OpenSSL based TLS
implementations.

Mark





Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508





jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>

This message may contain confidential and/or privileged information.
If you

are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply
e-mail and delete this message. Thank you for your cooperation.





-
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



-
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



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



Re: Tomcat 8 releases - where to get correct key

2022-08-11 Thread Christopher Schultz

Petr,

Please don't email committers directly. I'm replying to the Tomcat 
users' mailing list with my response, as it's useful information for 
everyone.


On 8/11/22 09:23, Petr Sumbera wrote:

I have a problem where to get correct key for previous version.

Can you please advice where to get correct key for validation?

>
> Source
> 
https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.81/src/apache-tomcat-8.5.81-src.tar.gz...

>  downloading...
>  validating signature... failed
> gpg: Warning: using insecure memory!
> gpg: Signature made Wed Jun  8 23:39:12 2022 CEST
> gpg:using RSA key 
3262A061C42FC4C7BBB5C25C1CF0293FA53CA458

>
> gpg: requesting key 1CF0293FA53CA458 from hkp server keys.gnupg.net
> gpg: Can't check signature: No public key

You have a couple of options.

The first option would be to simply download the key from a public key 
server. Something like this:


$ gpg --receive-keys 3262A061C42FC4C7BBB5C25C1CF0293FA53CA458

The second option is to fetch the KEYS file from any of the following 
places:


1. https://downloads.apache.org/tomcat/tomcat-8/KEYS
2. (During Voting) 
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.81/KEYS
   (After Release) 
https://dist.apache.org/repos/dist/release/tomcat/tomcat-8/v8.5.81/KEYS

3. https://github.com/apache/tomcat/tree/8.5.81/KEYS
4. apache-tomcat-8.5.81-src.tar.gz/KEYS
5. apache-tomcat-8.5.81-src.zip/KEYS

(Really, you shouldn't trust any KEYS file you get in a distribution 
because the distribution could have modified the KEYS file to include 
its own key ... and then changed all the signatures.)


If you visit the Tomcat downloads page[1] and read the "Release 
Integrity" section, you'll see a link to the KEYS file there. Note that 
KEYS files should always be downloaded directly from Apache, and not 
from anywhere else (okay, Github is probably fine).


Hope that helps,
-chris

[1] https://tomcat.apache.org/download-80.cgi

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



Re: Issue with catalina.out not being generated (RHEL 7.9, tomcat 9.0.63)

2022-08-11 Thread Christopher Schultz

Paul,

On 8/11/22 12:09, Paul Chauvet wrote:

Hello all,

I haven't been able to figure this out - but a catalina.out file is not being generated 
for me.  Sadly - I'm trying to troubleshoot an issue (with a vendor's saml 
implementation) which wants to write to that file (and doesn't seem to be writing what I 
need to catalina.-DD-MM.logs, /var/log/messages, or into the journal as seen by 
"journalctl --unit=tomcat.service").


My environment:

   *   RHEL 7.9 (though the same happens on my RHEL 8 hosts)
   *   Tomcat 9.0.63 (installed from the .tar.gz download from 
https://tomcat.apache.org/download-90.cgi - not from the OS repository)
   *   Using jsvc via a systemd startup script to start Tomcat (that script is 
at the bottom of this message).


Typically, systemd captures stdout/stderr and sends it to journald or 
whatever. Writing to log files is apparently too quaint.



I've tried specifying CATALINA_OUT in setenv.sh, and in my systemd startup 
script.  I've temporarily disabled SELinux to see if that makes a difference.  
Neither of those work.  What does work, though I would like to avoid it, is if 
I start Tomcat via ./startup.sh.  If I do that - catalina.out is generated but 
I'm not getting other settings I set in my systemd script (or having it tied to 
startup/shutdown of the OS).

I don't know what I'm missing or doing wrong here, or if there's something 
about jsvc that is an issue here that I can't figure out.  I've been unable to 
find anything related to this (lots of posts about catalina.out related to 
operating system distributed versions of Tomcat that don't appear to apply).


It seems that you are just resisting doing things the Systemd Way.

Have you tried poking-around with journalctl to see if you can get the logs?

If "catalina.sh start/run" works for you, then the issue lies with your 
systemd configuration/environment.


-chris

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



Re: .deb file to Tomcat 9.0.33

2022-08-11 Thread Christopher Schultz

Rhea,

On 8/11/22 11:47, Rhea Moubarak wrote:

Where can i find the .deb file to tomcat 9.0.33?


Probably in a Debian repository? Or Ubuntu?

The Apache Tomcat project doesn't formally deal with 
package-manager-specific artifacts such as .deb files, though there are 
members of this community who do (e.g. ebourg).


-chris

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



Re: Simple SSL question

2022-08-11 Thread Christopher Schultz

Jon,

On 8/11/22 11:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

Is there a "name" for the new connector style? The old is known as
the Coyote Connector.
Coyote is just the name of the connector itself, for whatever reason. 
Both the new and old-style configuration is using the same connector 
underneath. When you configure everything on the , Tomcat 
still creates an SSLHostConfig object under the covers and fills it with 
that same data.


Why should you bother migrating? Two reasons:

1. The new configuration is easier to read IMO. It separates the TLS 
host/key/certificate and all that associated stuff from the more basic 
socket-type stuff for the 


2. It allows for more options such as proper name-based virtual-hosting 
with TLS. It also allows multiple types of keys and certificates to be 
used. For example, you can configure both RSA and EC certificates for a 
single host. That's just not possible with the 
one-attribute-to-rule-them-all configuration where everything is on the 
 element.


-chris


-Original Message-
From: Mark Thomas 
Sent: Wednesday, August 10, 2022 2:43 PM
To: users@tomcat.apache.org
Subject: Re: Simple SSL question

On 10/08/2022 19:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, I'm asking a rather simple, stupid (in my opinion) question, but here

goes:


What is the best practice form of connector for SSL. Is it the old-school

coyote connector or the connector with the  section?



The old style isn't supported in Tomcat 10.0.x onwards.


Are the two interchangeable, or does the SSLHostConfig one rely on

openssl and won't work without it? The documentation is confusing me on a
hump day afternoon.

They are interchangeable. However, if you want to configure TLS virtual
hosting with SNI you'll need to use SSLHostConfig.

Both approaches can be used with JSSE and OpenSSL based TLS
implementations.

Mark





Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508



jonmcalexan...@wellsfargo.com

This message may contain confidential and/or privileged information. If you

are not the addressee or authorized to receive this for the addressee, you
must not use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you
for your cooperation.





-
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



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



Re: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have sslProtocol="TLSv1.2"

2022-08-10 Thread Christopher Schultz

James,

On 8/10/22 11:57, James H. H. Lampert wrote:

Interesting. The new "protocols" parameter.

Does this work with the traditional syntax? Can "protocols" and 
"sslProtocol" coexist in the same Connector?


It's pretty important here to specify your Tomcat version number(s). I 
see you have them at the bottom of this message, but not the original.


All our customer installations use JSSE security with a Java Keystore; 
I've never configured a successful IBM Midrange installation any other way.


Looking at the "Server Information" on the "Manager" webapp, I see:

The "problem" server ("#2" in the original post) is on 8.5.73, running 
under IBM OS/400 Java 8.0.5.25.


The "working" server ("#1" in the original post) is on 8.5.79, running 
under IBM OS/400 Java 8.0.6.35.


I'm mostly going to repeat things others have said elsewhere in this 
thread, but (a) all together and (b) with maybe some historical perspective.


Tomcat connectors have always supported the "sslProtocol" attribute 
(which is next to useless, other than that you have to put something in 
there that Java recognizes).


The other attribute used to be sslEnabledProtocols, now called 
protocols, which is the one that actually sets the list of specific 
protocol versions. Your versions should be sufficiently recent that the 
following excerpts from the user manual[1] are currently accurate:


"
sslProtocol

JSSE only.

The SSL protocol(s) to use (a single value may enable multiple protocols 
- see the JVM documentation for details). If not specified, the default 
is TLS. The permitted values may be obtained from the JVM documentation 
for the allowed values for algorithm when creating an SSLContext 
instance e.g. Oracle Java 7. Note: There is overlap between this 
attribute and protocols.

"

"
protocols   

The names of the protocols to support when communicating with clients. 
This should be a list of any combination of the following:


SSLv2Hello
SSLv3
TLSv1
TLSv1.1
TLSv1.2
TLSv1.3
all

Each token in the list can be prefixed with a plus sign ("+") or a minus 
sign ("-"). A plus sign adds the protocol, a minus sign removes it form 
the current list. The list is built starting from an empty list.


The token all is an alias for SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2,TLSv1.3.

Note that TLSv1.3 is only supported for JSSE when using a JVM that 
implements TLSv1.3.


Note that SSLv2Hello will be ignored for OpenSSL based secure 
connectors. If more than one protocol is specified for an OpenSSL based 
secure connector it will always support SSLv2Hello. If a single protocol 
is specified it will not support SSLv2Hello.


Note that SSLv2 and SSLv3 are inherently unsafe.

If not specified, the default value of all will be used.
"

*These are not interchangeable*

Setting sslProtocols to a list of things may fail and certainly won't do 
what you expect.


These days, you shouldn't even bother setting sslProtocol at all. Use 
protocols and /only/ protocols and you'll get what you want.


I also highly recommend that you "upgrade" your configuration to use:


  


There are certain things you cannot do without  and 
honestly it makes it WAY more clear in your configuration what you are 
trying to do.


So why does it have to be this confusing? Well, history...

Long ago, there was just "SSL". Java at some point gave programmers the 
option to use "TLS" which was this crazy new thing. If you wanted it, 
you need to say "TLS" when initializing the SSLEngine component of Java. 
When it was introduced into Tomcat 3.1 or whatever, that option was 
added because hey, maybe not everyone wanted to live on the edge with 
this new-fangled TLS thing. These days, it almost doesn't matter what 
string you give to Java when initializing the SSLEngine, you always get 
one that can do pretty much everything.


Okay, so at some point, we all switched from SSL to TLS and all was 
good. Except that we had to disable SSLv3 at some point, and then these 
new crazy people said we needed to support TLSv1.2, etc. and again not 
everybody wanted that "secure" stuff they were happy with their ROT13 
encryption and so sslEnabledProtocols was introduced: you could specify 
not only which SSL engine you wanted (SSL vs TLS) but also the 
individual protocols you were willing to support.


Fast-forward a few years and we have the situation where sslProtocols is 
all but useless and mostly everyone wants to use TLSv1.2 and TLSv1.3 and 
nothing else. But, backward-compatibility rules and so "all" (alias for 
"SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2,TLSv1.3") is the default. I've been 
pushing for the default to be changed to support only the later 
protocols and we are likely to do that in e.g. Tomcat 10.x but not other 
versions because, again, history. Tomcat major versions have had a 
lifetime of like 10 years and so we can't turn on a dime without 
someone's whole cluster going down because we changed the defaults and 
they didn't bother testing before 

Re: End user files uploaded to sftp getting stored in tomcat root directory

2022-08-09 Thread Christopher Schultz

Farash,

On 8/9/22 09:23, Farash Ahamad wrote:

Hi Chris,

There is an application portal running on tomcat used by many users, where
they create profiles, upload documents, etc.
When they upload the document via portal, the application pushes it to sftp
on another server, but sometimes a copy is stored in the root directory
tomcat server with exact details like filename, size, etc.


So your users upload to your application, which then uploads the file 
via sftp?


My guess is that your application does something like this:

public void service(Request, Response) {
  String filename = Request.getParameter("filename");
  InputStream in = Request.getInputStream();

  OutputStream out = new FileOutputStream(filename);
  while(in.read(...)) {
out.write(...);
  }
  out.close();
  in.close();

  FTPClient client = new FTPClient();
  client.connect();
  client.put(filename);
}

By using the Tomcat server as a temporary location for files, there is 
the possibility that uploaded-files will stick-around in that directory, 
especially if the code isn't very careful about resource-management and 
error-handling.


I would immediately audit your code for the following:

1. Proper destination directory. If users can upload files to your 
Tomcat directory, what happens if I upload a .jsp file and then request 
that file over HTTP from your server? Will it execute the file? :0 You 
should write all files into the container-provided temp directory. Ask 
if you don't know what this it.


2. Filename sanitization. If a user can upload a file, can they 
overwrite local files? Can they perform directory-traversals? What 
happens if I upload /etc/passwd or conf/server.xml?


3. Proper resource management (e.g. look for close() and delete() for 
everything you do locally)


4. Maybe you don't even need to store the file locally. Does your sftp 
client library allow you to stream files directly to the remote server? 
It would be better to never write the file bytes onto the Tomcat server 
in the first place.


Hope that helps,
-chris


On Tue, Aug 9, 2022 at 4:18 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Farash,

On 8/9/22 04:55, Farash Ahamad wrote:

Just to add, the file is getting uploaded to SFTP server, but there is an
exact copy in tomcat server as well.


Can you give more details? Is a human user pushing via sftp to your
Tomcat server? Or is your Tomcat-deployed application pushing via sftp
to another server? Or something more complicated?

Is the Tomcat server hosting the sftp server / destination?

-chris


On Tue, Aug 9, 2022 at 11:46 AM Mark Thomas  wrote:


This will always be an application issue.

Mark


On 09/08/2022 09:41, Farash Ahamad wrote:

Dear All,

I am observing there and several documents (pdf, png, jpeg, etc) which

the

end user uploads in the application getting stored in tomcat /

directory.


I would like to understand whether this is a bug in the application

code

or

in tomcat.

Application based on: Java Spring Boot 2.1.3
Tomcat version: 9.0.41
OS Version: RHEL 7.9
Document Destination: SFTP server (Unified gluster FS through Serv-U)

Appreciate your help.

Thanks & Regards,
Farash Ahamad



-
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






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



Re: End user files uploaded to sftp getting stored in tomcat root directory

2022-08-09 Thread Christopher Schultz

Farash,

On 8/9/22 04:55, Farash Ahamad wrote:

Just to add, the file is getting uploaded to SFTP server, but there is an
exact copy in tomcat server as well.


Can you give more details? Is a human user pushing via sftp to your 
Tomcat server? Or is your Tomcat-deployed application pushing via sftp 
to another server? Or something more complicated?


Is the Tomcat server hosting the sftp server / destination?

-chris


On Tue, Aug 9, 2022 at 11:46 AM Mark Thomas  wrote:


This will always be an application issue.

Mark


On 09/08/2022 09:41, Farash Ahamad wrote:

Dear All,

I am observing there and several documents (pdf, png, jpeg, etc) which

the

end user uploads in the application getting stored in tomcat / directory.

I would like to understand whether this is a bug in the application code

or

in tomcat.

Application based on: Java Spring Boot 2.1.3
Tomcat version: 9.0.41
OS Version: RHEL 7.9
Document Destination: SFTP server (Unified gluster FS through Serv-U)

Appreciate your help.

Thanks & Regards,
Farash Ahamad



-
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: Error during startup

2022-08-09 Thread Christopher Schultz

Joey,

On 8/8/22 09:21, Joey Cochran wrote:

Make sure /bin/tomcat-juli.jar is set to 755 (chmod 755 tomcat-juli.jar)


Nonsense. This would never cause a permissions problem as described by 
the OP. Also:


7 = owner read+write+execute
5 = group read+execute
5 = other read+execute

NOBODY needs execute permission on a JAR file (okay, unless it's a 
runnable JAR, which this one IS NOT).


This file is happy under any of the following, depending upon your needs.

0400
0440
0540

And surely other options with additional unnecessary permissions.

For my money, I'd have the file owners be something like user "tomcat" 
group "tomcat" and the euid of the Tomcat process something like user 
"runtomcat" group "tomcat" and have most things read-only for the 
"runtomcat" user. You can have group-write permission enabled for 
"tomcat" for the "work", "logs", and "temp" directories.


-chris


-Original Message-
From: Mohan T 
Sent: Monday, August 8, 2022 2:26 AM
To: Tomcat Users List 
Subject: [EXTERNAL] RE: Error during startup

We have added the contents under grant section.

Still we are getting the error message.

Error in Full Agent Registration Info Resolver reading environment 
variable/system property
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" 
"getenv.")
 at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
 at 
java.security.AccessController.checkPermission(AccessController.java:884)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 at java.lang.System.getenv(System.java:894)
 at 
com.singularity.ee.util.system.SystemUtils.getenv(SystemUtils.java:49)
 at 
com.singularity.ee.agent.resolver.ADefaultResolver.getProperty(ADefaultResolver.java:44)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.shouldCreateAgentInfoIfMissing(FullAgentRegistrationInfoResolver.java:83)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.(FullAgentRegistrationInfoResolver.java:72)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.(FullAgentRegistrationInfoResolver.java:60)
 at 
com.singularity.ee.agent.appagent.kernel.AppTierNodeDeterminerDelegate.executeGenericFunction(AppTierNodeDeterminerDelegate.java:260)
 at 
com.singularity.ee.agent.appagent.kernel.AppTierNodeDeterminer.executeGenericFunction(AppTierNodeDeterminer.java:128)
 at 
com.singularity.ee.agent.appagent.AgentEntryPoint.getAppTierNodeFromLib(AgentEntryPoint.java:1735)
 at 
com.singularity.ee.agent.appagent.AgentEntryPoint.determineAppAgentVersionToUse(AgentEntryPoint.java:1549)
 at 
com.singularity.ee.agent.appagent.AgentEntryPoint.premain(AgentEntryPoint.java:557)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
 at 
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:401)
Full Agent Registration Info Resolver found system property 
[appdynamics.agent.nodeName] for node name [Tomcat_iaasa7924_base0]
Full Agent Registration Info Resolver using selfService [false]
Full Agent Registration Info Resolver using selfService [false]
Full Agent Registration Info Resolver using ephemeral node setting [false]
Full Agent Registration Info Resolver using application name 
[ILAS-NonProd_34995]
Error in Full Agent Registration Info Resolver reading environment 
variable/system property
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" 
"getenv.")
 at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
 at 
java.security.AccessController.checkPermission(AccessController.java:884)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 at java.lang.System.getenv(System.java:894)
 at 
com.singularity.ee.util.system.SystemUtils.getenv(SystemUtils.java:49)
 at 
com.singularity.ee.agent.resolver.ADefaultResolver.getProperty(ADefaultResolver.java:44)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.getNodeNameFromJavaAgentArg(FullAgentRegistrationInfoResolver.java:387)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.run(FullAgentRegistrationInfoResolver.java:252)
 at 
com.singularity.ee.agent.appagent.kernel.AppTierNodeDeterminerDelegate.getAppTierNode(AppTierNodeDeterminerDelegate.java:150)
 at 

Re: Error during startup

2022-08-09 Thread Christopher Schultz

Han,

On 8/4/22 00:49, Han Li wrote:

Hi Mohan,

You can open CATALINA_BASE/conf/catalina.policy file, add following statement 
within  “grant” section:

permission java.lang.RuntimePermission "getenv.*";



While this will likely fix the "problem", it may not be the best 
solution. The OP is running under a Security Manager, probably for a 
reason. It would be best to restrict the getenv privilege to the minimum 
necessary to run the application properly in that environment. That may 
be something closer to


grant codeBase "file:some/specific.jar" {
  permission java.lang.RuntimePermission "getenv.oneVariableName";
}

Thanks,
-chris


2022年8月4日 11:33,Mohan T  写道:

Dear All,

We are using tomcat 8.5 on suse linux 7.

We are invoking Catalina.sh in java security enabled mode.

Kindly help me in resolving this .

Thanks

Mohan

Exception:
Error in Full Agent Registration Info Resolver reading environment 
variable/system property
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" 
"getenv.")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at 
java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.System.getenv(System.java:894)

DISCLAIMER: This communication contains information which is confidential and the 
copyright of Ramco Systems Ltd, its subsidiaries or a third party ("Ramco"). 
This email may also contain legally privileged information. Confidentiality and legal 
privilege attached to this communication are not waived or lost by reason of mistaken 
delivery to you.This email is intended to be read or used by the addressee only. If you 
are not the intended recipient, any use, distribution, disclosure or copying of this 
email is strictly prohibited without the express written approval of Ramco. Please delete 
and destroy all copies and email Ramco at le...@ramco.com immediately. Any views 
expressed in this communication are those of the individual sender, except where the 
sender specifically states them to be the views of Ramco. Except as required by law, 
Ramco does not represent, warrant and/or guarantee that the integrity of this 
communication has been maintained nor that the communication is free of errors, virus, 
interception or interference. If you do not wish to receive such communications, please 
forward this communication to market...@ramco.com and express your wish not to receive 
such communications henceforth.





Re: Tomcat is Automatically Getting Stopped Frequently

2022-08-03 Thread Christopher Schultz

Prasenjit,

On 8/3/22 11:43, Prasenjit Dey wrote:
Can you please tell us which OS logs in Ubuntu I need to check. I am new 
to this. Please help!


Look at CATALINA_BASE/logs/catalina.out and /var/log/messages. You may 
have to check other /var/log/* files, as each Linux distro tends to put 
certain things in other places. Might be /var/log/dmesg or 
/var/log/daemon or whatever.


-chris


*From: *Mark Thomas 
*Sent: *Wednesday, August 3, 2022 4:55 PM
*To: *users@tomcat.apache.org 
*Subject: *Re: Tomcat is Automatically Getting Stopped Frequently

Tomcat won't be shutting itself down. Something external must be
stopping the process.

Check the OS logs. This sounds like the Linux OOM killer.

Note: Attachments rarely make it to the list. If you need to share
attachments, use a file sharing service.

Mark


On 03/08/2022 09:12, Prasenjit Dey wrote:
 > Tomcat Version: 8.5.81.0
 >
 > Operating System: Ubuntu 20.04 LTS
 >
 > RAM: 8gb
 >
 > Java Version: 1.8.0_312
 >
 > Architecture: 64Bit
 >
 > Hi,
 >
 > I am facing a problem regarding our application hosted in Tomcat. Our
 > infrastructure is on Azure Cloud. We have hosted our application in
 > Tomcat on a virtual machine deployed from Azure. After few hours of
 > usage, we are experiencing that the Tomcat is going down automatically
 > and we are not able to browse the application. From the memory point of
 > view we have seen that when the problem is occurring then Tomcat service
 > is using 1.4GB of memory. Attaching the Tomcat logs and server.xml for
 > your reference. Please feel free to connect with us if you need any
 > additional information.
 >
 > *Thanks & Regards,*
 >
 > *Prasenjit Dey | Team Leader - Testing | Kovair Software*
 >
 > *Ph: +91.33. 40657016 Ext. 240 | **prasanjit...@kovair.com*
 > >
 >
 > *URL:**http://www.kovair.com*
 > 
>

 >
 > PPlease consider the environment before printing this email
 >
 >
 >
 > -
 > 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



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



Re: Tomcat is Automatically Getting Stopped Frequently

2022-08-03 Thread Christopher Schultz

Prasenjit,

On 8/3/22 03:19, Prasenjit Dey wrote:

Tomcat Version: 8.5.81.0
Operating System: Ubuntu 20.04 LTS
RAM: 8gb
Java Version: 1.8.0_312
Architecture: 64Bit

Hi,

I am facing a problem regarding our application hosted in Tomcat. Our 
infrastructure is on Azure Cloud. We have hosted our application in 
Tomcat on a virtual machine deployed from Azure. After few hours of 
usage, we are experiencing that the Tomcat is going down automatically 
and we are not able to browse the application. From the memory point of 
view we have seen that when the problem is occurring then Tomcat service 
is using 1.4GB of memory. Attaching the Tomcat logs and server.xml for 
your reference. Please feel free to connect with us if you need any 
additional information. We are awaiting for your reply.


Do you have anything in the Tomcat logs about the shutdown? Or does the 
process just disappear? Have you looked at /var/log/messages to see if 
the OOME killer is killing your application?


What are the parameters you use to launch Tomcat? (Specifically, your 
heap-related parameters)?


-chris

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



Re: Apache Tomcat 8.5.82 Release Date

2022-08-02 Thread Christopher Schultz

To whom it may concern,

On 8/2/22 01:28, Wai Siang, Chu wrote:

Dear Apache Tomcat Team,

Based on the previous email reply,
may we have an update regarding the estimated release date for the *Apache
Tomcat 8.5.82* ?


I can accept payments via Venmo if you want to accelerate the 
release-date of Tomcat 8.5.82 as part of *my volunteer efforts* to 
support Apache Tomcat.


-chris


On 7/26/22 00:13, Wai Siang, Chu wrote:

Based on the previous email reply,
may we have an update regarding the estimated release date for the

*Apache

Tomcat 8.5.82* ?


I expect to begin the release process around 1 August (6 days from today).

Please note that upgrading to Tomcat 8.5.82 once it is available should
not provide any actual security protections in a production environment.
If you have deployed the "examples" web application into production then
you are already making a mistake, security-wise. Simply removing the
application entirely mitigates the threat.

-chris


On Wed, Jul 13, 2022 at 6:00 PM Mark Thomas  wrote:


On 13/07/2022 10:46, Wai Siang, Chu wrote:

Dear Apache Tomcat Team,

We are aware there is a vulnerability found in the latest 8.5.xx

version.


*Low: Apache Tomcat XSS in examples web application* CVE-2022-34305


Hence, may we check is there an estimated timeline for the *Apache

Tomcat

8.5.82* release date?


Why?

Have you reviewed the vulnerability? It is a XSS in the examples app.
The examples app should never be deployed in a production environment.
Hence this vulnerability should be a non-issue for (nearly?) all users.

Like all currently supported Tomcat versions, 8.5.x is released on a
roughly monthly cycle. The July release for 8.5.x hasn't started yet so
I'd expect the release later this month.

If you want to follow release planning more closely, then that is
discussed on the dev list.

Mark





Thank you.

Regards,
Wai Siang

D: -
M: (65) 9821 0409
T: (65) 6837 2822
F: (65) 6756 3839
E : waisi...@toppanecquaria.com

11 Toa Payoh Lorong 3
#02-31 Block C, Jackson Square
Singapore 319579

Toppan Ecquaria Pte. Ltd.
Company Registration No: 199806305H

www.toppanecquaria.com

https://www.linkedin.com/company/toppan-ecquaria/




STRICTLY CONFIDENTIAL - This message, its contents and any files
transmitted with it are intended SOLELY for the addressee(s) and may be
legally privileged and/or confidential. Access by any other party is
unauthorised without the expressed written permission of the sender. If

you

have received this message in error, you may not copy or use the

contents,

attachments or information in any way. Please destroy it and contact us
immediately via e-mail return or by telephone at (65) 68372822. This
message has been prepared using information believed by the author to

be

reliable and accurate, but Toppan Ecquaria Pte. Ltd. and the Toppan

Group

of Companies ("Toppan") makes no warranty as to its accuracy or
completeness. Toppan does not accept responsibility for changes made to
this message after it was sent.



-
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






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



Re: Apache Tomcat 8.5.82 Release Date

2022-07-26 Thread Christopher Schultz

Wai Siang,

On 7/26/22 00:13, Wai Siang, Chu wrote:

Based on the previous email reply,
may we have an update regarding the estimated release date for the *Apache
Tomcat 8.5.82* ?


I expect to begin the release process around 1 August (6 days from today).

Please note that upgrading to Tomcat 8.5.82 once it is available should 
not provide any actual security protections in a production environment. 
If you have deployed the "examples" web application into production then 
you are already making a mistake, security-wise. Simply removing the 
application entirely mitigates the threat.


-chris


On Wed, Jul 13, 2022 at 6:00 PM Mark Thomas  wrote:


On 13/07/2022 10:46, Wai Siang, Chu wrote:

Dear Apache Tomcat Team,

We are aware there is a vulnerability found in the latest 8.5.xx version.

*Low: Apache Tomcat XSS in examples web application* CVE-2022-34305


Hence, may we check is there an estimated timeline for the *Apache Tomcat
8.5.82* release date?


Why?

Have you reviewed the vulnerability? It is a XSS in the examples app.
The examples app should never be deployed in a production environment.
Hence this vulnerability should be a non-issue for (nearly?) all users.

Like all currently supported Tomcat versions, 8.5.x is released on a
roughly monthly cycle. The July release for 8.5.x hasn't started yet so
I'd expect the release later this month.

If you want to follow release planning more closely, then that is
discussed on the dev list.

Mark





Thank you.

Regards,
Wai Siang

D: -
M: (65) 9821 0409
T: (65) 6837 2822
F: (65) 6756 3839
E : waisi...@toppanecquaria.com

11 Toa Payoh Lorong 3
#02-31 Block C, Jackson Square
Singapore 319579

Toppan Ecquaria Pte. Ltd.
Company Registration No: 199806305H

www.toppanecquaria.com

https://www.linkedin.com/company/toppan-ecquaria/




STRICTLY CONFIDENTIAL - This message, its contents and any files
transmitted with it are intended SOLELY for the addressee(s) and may be
legally privileged and/or confidential. Access by any other party is
unauthorised without the expressed written permission of the sender. If

you

have received this message in error, you may not copy or use the

contents,

attachments or information in any way. Please destroy it and contact us
immediately via e-mail return or by telephone at (65) 68372822. This
message has been prepared using information believed by the author to be
reliable and accurate, but Toppan Ecquaria Pte. Ltd. and the Toppan Group
of Companies ("Toppan") makes no warranty as to its accuracy or
completeness. Toppan does not accept responsibility for changes made to
this message after it was sent.



-
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: AW: Publishing Tomcat webapp

2022-07-25 Thread Christopher Schultz

Jasmin,

On 7/21/22 17:03, Jasmin Ćatić wrote:

I still didn't manage to configure SSL for my Tomcat. I tried a whole bunch
of tutorials and solutions but nothing worked for me.
Once again I will provide you with what I have, so if anybody can help me I
would really appreciate it.


I don't see anything posted here. Please post your  
configuration (minus any secrets) and the output of "keytool -list" for 
your keystore (if you use one) or confirmation that your PEM files exist 
and actually contain what is expected. (Do NOT post the keys here!)



If anyone has a free time I will provide you
with remote access to configure it together with me.


If you want realtime help, you are going to have to pay someone. Lots of 
people here are happy to help for free, but on their schedule.



So, I have a subdomain testjc.fgu.ba created in a cpanel, and it
automatically generated the SSL certificate for the testjc.fgu.ba and
www.testjc.fgu.ba. I have a certificate.crt, private.key and ca_bundle.crt
files in my cpanel.
The subdomain has an A record pointing to my PC IP address where I
installed Tomcat instance and it is currently running.
You can access it via http, but I want to do the encryption and be able to
have https access to my Tomcat.
What should I do next?


Tell us what you did with the files you have above.

-chris


čet, 21. srp 2022. u 14:25 Thomas Hoffmann (Speed4Trade GmbH)
 napisao je:





-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Donnerstag, 21. Juli 2022 14:11
An: users@tomcat.apache.org
Betreff: Re: AW: Publishing Tomcat webapp

Thomas,

On 7/17/22 03:07, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,


-Ursprüngliche Nachricht-
Von: Aryeh Friedman 
Gesendet: Sonntag, 17. Juli 2022 08:43
An: Tomcat Users List 
Betreff: Re: Publishing Tomcat webapp

On Sun, Jul 17, 2022 at 2:39 AM Aryeh Friedman

wrote:

Once you have it pointing to that domain just upload the war file to
it

and give people the link.

Small wording correction... I mean upload the war file as being a
part of the webapp and/or a part of an other webapp you have for

downloading...

take a look at the download section of the site I list in my

signature.


--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


Usually you need 2 things:
1) A webserver or webspace. This includes a public IP address
2) A domain. You can buy it online.

When you own a domain, you have access to the DNS settings. Create an

A-Record with the domain-name and point it to the IP address of your
server.

If an A-records already exists, modify it to point to the IP address

of the

server.


Install tomcat on the webserver and install your web-application.
Tomcat listens per default on all ports, so no special configuration

needed

(only if you host multiple domains on that server).

s/ports/interfaces/

-chris

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


Thanks for correcting my typo. Listens on all *interfaces* of course, not
ports 

-
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: *** Payara, GlassFish or Tomcat ***

2022-07-21 Thread Christopher Schultz

Zdenek,

On 7/21/22 04:39, Zdeněk Henek wrote:

Amn,

Our application is tested with Weblogic and Tomcat. I was asked to port our
application to any free application server or web container. I picked
Tomcat 5.5, now we are on Tomcat 9. I have to say maintaining our app and
its installer for Tomcat is very easy. Very good backward compatibility and
for development all of us in our development team use Tomcat.

There is one point where you may need to consider using Tomcat or something
else. Tomcat implements a subset of Jakarta EE / Java EE standards. Best
overview I know about is here https://tomcat.apache.org/whichversion.html


This one is pretty good because it shows all the stuff Tomcat doesn't have:
https://tomee.apache.org/comparison.html#_synthesis_of_differences_between_flavors


Some other Jakarta EE / Java EE spec implementations could be added to
Tomcat without problems. Another option is using the full Jakartra EE
application server as GlassFish. These may be more complex to configure or
use in development, but I don't have any experience with Payara or
GlassFish to compare. Weblogic is a bit harder to use for development when
I compare it with Tomcat.


Don't forget about TomEE, which uses Tomcat as its underlying servlet, 
etc. container and layers other EE tech on top of it. It comes in a few 
flavors so you don't need 500 libraries deployed into a server that only 
needs 4-5 of them.


-chris


On Wed, Jul 13, 2022 at 12:00 AM Amn  wrote:


Nu-B here.

Reading about Payara, GlassFish and Tomcat, I feel confused as to which
would be the best server to learn about when learning Jakarta EE.
Any suggestions?

--
*Using Fire Fox and Thunderbird.*
Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
platform has been exciting and most rewarding.
[ Ñ ]




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



Re: Publishing Tomcat webapp

2022-07-21 Thread Christopher Schultz

Aryeh,

On 7/18/22 09:08, Aryeh Friedman wrote:

Here are the steps to installing a SSL cert (it varies slightly based
on who your certificate authority [CA] is):

Generate a CSR


Stop. The OP already has a key, cert, and chain. None of this is necessary.


[..] with keytool (it must be key tool despite what the
tomcat docs say since for whatever reason it refuses to import from
any other SSL tool):

keytool –keystore clientkeystore –genkey –alias mykey

Submit the above to your CA (they will give you directions on how to
submit it) and have them issued a signed cert for it

The signed cert usually comes with some intermediate files (this is
the part that varies by CA) which you have to apply in order to the
keystore (the following is the set of files I use):



This may or may not be necessary, depending upon what CPanel is willing 
to give to you.



keytool -noprompt -importcert -alias AAACertificateServices -file
AAACertificateServices.crt -keystore sslStore

keytool -importcert -trustcacerts -keystore sslStore -file
USERTrustRSCA.crt -alias USERTrustRSCA

keytool -importcert -trustcacerts -keystore sslStore -file
/SectigoRSAOrganizationValidationSecureServerCA.crt -alias
SectigoRSAOrganizationValidationSecureServerCA

keytool -importcert -trustcacerts -alias mykey (this *MUST* match the
alias of the CSR you submitted to the CA)
 -file 1008013344repl_2.crt -keystore sslStore

Modify the tomcat server.xml to uncomment out the right https line in
the config and tell it where to find the sslStore (some OS's force you
to put it in $TOMCAT_HOME)... for example I do the following:




A modern configuration would use s and s, 
which I'd highly recommend doing.



Restart tomcat and you should have SSL how if you go to https if you
on port 8080 you will likely want to put in 8443 not 443


I disagree: using 443 is what the whole world expects for a 
publicly-accessible web site using https.


-chris

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



Re: AW: Publishing Tomcat webapp

2022-07-21 Thread Christopher Schultz

Thomas,

On 7/17/22 03:07, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,


-Ursprüngliche Nachricht-
Von: Aryeh Friedman 
Gesendet: Sonntag, 17. Juli 2022 08:43
An: Tomcat Users List 
Betreff: Re: Publishing Tomcat webapp

On Sun, Jul 17, 2022 at 2:39 AM Aryeh Friedman

wrote:

Once you have it pointing to that domain just upload the war file to
it

and give people the link.

Small wording correction... I mean upload the war file as being a part of the
webapp and/or a part of an other webapp you have for downloading...
take a look at the download section of the site I list in my signature.

--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


Usually you need 2 things:
1) A webserver or webspace. This includes a public IP address
2) A domain. You can buy it online.

When you own a domain, you have access to the DNS settings. Create an A-Record 
with the domain-name and point it to the IP address of your server.
If an A-records already exists, modify it to point to the IP address of the 
server.

Install tomcat on the webserver and install your web-application.
Tomcat listens per default on all ports, so no special configuration needed 
(only if you host multiple domains on that server).


s/ports/interfaces/

-chris

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



Re: Need remedy for the Vulnabilities

2022-07-21 Thread Christopher Schultz

Koustav,

On 7/19/22 05:49, Naha, Koustav wrote:

We have the below vulnerability in recent scan, mentioned below.

Environment details:


Apache - 2.4.25 version



Tomcat - 8.5.5 version


Can anyone take a look at the CVEs associated with the scan findings
and see if there are workarounds, rather than upgrading.
Wow, you are recklessly out of date. Depending upon your business sector 
and country-of-operation, you may even be /criminally/ out of date.


You have no options other than to upgrade to the latest version. Why 
would you not want to upgrade to the latest version?


-chris


CVE-2022-26377
Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') 
vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to 
smuggle requests to the AJP server it forwards requests to. This issue affects 
Apache HTTP Server Apache HTTP Server 2.4 version 2.4.53 and prior versions.
CVE-2017-7679
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_mime can read 
one byte past the end of a buffer when sending a malicious Content-Type 
response header.
CVE-2022-0778
The BN_mod_sqrt() function, which computes a modular square root, contains a 
bug that can cause it to loop forever for non-prime moduli. Internally this 
function is used when parsing certificates that contain elliptic curve public 
keys in compressed form or explicit elliptic curve parameters with a base point 
encoded in compressed form. It is possible to trigger the infinite loop by 
crafting a certificate that has invalid explicit curve parameters. Since 
certificate parsing happens prior to verification of the certificate signature, 
any process that parses an externally supplied certificate may thus be subject 
to a denial of service attack. The infinite loop can also be reached when 
parsing crafted private keys as they can contain explicit elliptic curve 
parameters. Thus vulnerable situations include: - TLS clients consuming server 
certificates - TLS servers consuming client certificates - Hosting providers 
taking certificates or private keys from customers - Certificate authorities 
parsing certification requests from subscribers - Anything else which parses 
ASN.1 elliptic curve parameters Also any other applications that use the 
BN_mod_sqrt() where the attacker can control the parameter values are 
vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is 
not parsed during initial parsing of the certificate which makes it slightly 
harder to trigger the infinite loop. However any operation which requires the 
public key from the certificate will trigger the infinite loop. In particular 
the attacker can use a self-signed certificate to trigger the loop during 
verification of the certificate signature. This issue affects OpenSSL versions 
1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on 
the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in 
OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 
1.0.2-1.0.2zc).
CVE-2020-1934
In Apache HTTP Server 2.4.0 to 2.4.41, mod_proxy_ftp may use uninitialized 
memory when proxying to a malicious FTP server.
CVE-2018-17189
In Apache HTTP server versions 2.4.37 and prior, by sending request bodies in a 
slow loris way to plain resources, the h2 stream for that request unnecessarily 
occupied a server thread cleaning up that incoming data. This affects only 
HTTP/2 (mod_http2) connections.
CVE-2017-9798
Apache httpd allows remote attackers to read secret data from process memory if 
the Limit directive can be set in a user's .htaccess file, or if httpd.conf has 
certain misconfigurations, aka Optionsbleed. This affects the Apache HTTP 
Server through 2.2.34 and 2.4.x through 2.4.27. The attacker sends an 
unauthenticated OPTIONS HTTP request when attempting to read secret data. This 
is a use-after-free issue and thus secret data is not always sent, and the 
specific data depends on many factors including configuration. Exploitation 
with .htaccess can be blocked with a patch to the ap_limit_section function in 
server/core.c.
CVE-2019-10082
In Apache HTTP Server 2.4.18-2.4.39, using fuzzed network input, the http/2 
session handling could be made to read memory after being freed, during 
connection shutdown.
CVE-2022-29404
In Apache HTTP Server 2.4.53 and earlier, a malicious request to a lua script 
that calls r:parsebody(0) may cause a denial of service due to no default limit 
on possible input size.

Re: QID 38863 - Cryptographically Weak Key Exchange Size

2022-07-21 Thread Christopher Schultz

Saicharan,

On 7/18/22 10:45, saicharan.bu...@wellsfargo.com.INVALID wrote:

Hi All,

A new vulnerability has surfaced regarding TLS and Key Exchange agreement (more 
specifically the key size.)

"The SSL/TLS server supports key exchanges that are cryptographically weaker 
than recommended. Key exchanges should provide at least 224 bits of security, which 
translates
to a minimum key size of 2048 bits for Diffie Hellman and RSA key exchanges. An 
attacker with access to sufficient computational power might be able to recover the 
session key and decrypt session content."

We would like to know if  Apache Tomcat was flagged by having a weak DH (Diffie 
Hellman) key exchange or ECDH
(Elliptic Curve) key exchange or RSA (Rivest - Shamir - Adleman) key exchange.  
How do we remediate this vulnerability to match the minimum requirements
(RSA & DHE=2048; ECDHE= P-256) ?


Tomcat only uses the cryptographic providers supplied by the environment 
in which it's running. You need to configure those environments 
appropriately.


Have you detected a vulnerability, or are you asking a theoretical question?

-chris

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



Re: SSL configuration for Tomcat 9

2022-07-21 Thread Christopher Schultz

Vince,

On 7/15/22 19:56, Vince Stewart wrote:

My system uses embedded Tomcat to connect to a HttpServlet instance.
I have just uprgraded from Tomcat 8.0.2 to 9.0.64
I am implementing SSL for the first time.

I created a keystore with no alias. Keytool gave it the alias "mykey". (2nd
entry below)
I imported an issued PEM certificate (4 items in chain)
The final item in the chain has the alias "tomcat" as per
https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Importing_the_Certificate
(The same documentation recommends the keystore alias also be 'tomcat' but
If the keystore and the issued certificate are both given the same alias
(ie 'tomcat'), keytool will import the final entry as "self generated" and
throw an error. Here is my abbreviated keystore list using alias 'mykey'
for the keystore.


You have to import the signed cert on top of the one that already 
exists. Because you used "mykey" as the alias for the key/cert 
initially, you must use the same alias when you import the signed cert. 
Your self-signed cert will be replaced with the signed one. Remove the 
"tomcat" one and tell Tomcat to use "mykey".


Remember to make a backup ;)

I hate keystores.

-chris


keystore listing___
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 5 entries
intermediate, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256):
68:B9:C7:61.
intermediate2, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256):
7F:A4:FF:68
mykey, 16/07/2022, PrivateKeyEntry,
Certificate fingerprint (SHA-256):
36:F8:64:73:.
root, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256): D7:A7:A0:FB..
tomcat, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256):
36:A9:B7:A9:..


Here is my startup code (no server.xml file)


 Tomcat tomcat = new Tomcat();
 tomcat.setPort(PATHS.getPortNumber());
 Connector c=tomcat.getConnector();
 c.setSecure(true);
 c.setScheme("https");
 c.setProperty("SSLEnabled","true");//crucial bit of code
 SSLHostConfig ss=new SSLHostConfig();
 //ss.setHostName("localhost"); this breaks the init process - leave as
"_default_"
 ss.setCertificateKeyAlias("mykey");   // if set to 'tomcat'
init will throw "Alias name [tomcat] does not identify a key entry"
 ss.setCertificateKeystorePassword("changit");
 ss.setCertificateKeystoreFile(PATHS.getHomePath()+"/ks/mykeystor.jks");
 ss.setCertificateKeystoreType("PKCS12");
 ss.setCertificateKeystoreProvider("SUN")
 c.addSslHostConfig(ss);
 org.apache.catalina.Context ctx = tomcat.addContext("", new
File(".").getAbsolutePath());
 Tomcat.addServlet(ctx, "myApp", new MyApp());
 ctx.addServletMappingDecoded("/*", "myApp");
 Logr.s("connector scheme "+c.getScheme());
 Logr.s("connector SSLEnabled "+c.getProperty("SSLEnabled"));
 Logr.s("connector redirect "+c.getRedirectPort()); //defaults to 443
 Logr.s("connector protocol "+c.getProtocol());
 tomcat.start();
 tomcat.getServer().await();

When I use "tomcat" as the alias for the keystore I cannot load the final
issued certificate without an error. If I use "mykey" as the keystore alias
everything seems to be working but the certificate returned to the browser
is not the domain-specific certified certificate but a certificate
generated with the certificate keystore fingerprint.  In a properly
operating implementation, what certificate should be returned to the
browser?
I'm obviously doing something wrong. But what ?


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



Re: *** Payara, GlassFish or Tomcat ***

2022-07-20 Thread Christopher Schultz

Amn,

On 7/12/22 17:59, Amn wrote:

Nu-B here.

Reading about Payara, GlassFish and Tomcat, I feel confused as to which 
would be the best server to learn about when learning Jakarta EE.


I would use whichever you can download, install, and launch with the 
least hassle. For Tomcat, that's just:


$ wget url-for-tomcat-distro.tar.gz
$ tar xzf apache-tomcat-version.tar.gz
$ cd apache-tomcat-version
$ bin/startup.sh

You may need to adapt that to your own environment, slightly.

-chris

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



Re: [OT] issues with Tomcat to Siteminder communication post mod-proxy setup

2022-07-20 Thread Christopher Schultz

Jon,

On 7/13/22 12:16, jonmcalexan...@wellsfargo.com.INVALID wrote:

Here is the error we are getting. The login form, hosted by Tomcat, does a POST 
to the /login/login.fcc for siteminder which is on the HTTPD server and is not 
behind the proxypass or proxypassreverse.

javax.net.ssl|DEBUG|96|https-jsse-nio-8305-exec-1|2022-07-12 13:12:49.399 
PDT|SSLSocketImpl.java:1615|close the SSL connection (passive)
 12 Jul 2022 13:12:49,399 ERROR [https-jsse-nio-8305-exec-1]: DEVT: 
  Unable to get Channel Secure Session: Unable to perform siteminder handshake
java.lang.Exception: Unable to perform siteminder handshake

Our SiteMinder team is telling us it's not their issue. Again, this POST worked 
fine when using mod_jk and SSL wasn't enabled for connection on Tomcat.


When you migrated from mod_jk -> mod_proxy, did you arrange to have all 
SSL information forwarded over the connection? mod_jk with the AJP 
connector handles a lot of that magic for you, but mod_proxy does not by 
default.


Have a look at this presentation, starting around slide 30: 
https://tomcat.apache.org/presentations.html#latest-migrate-ajp-http


If your users are using TLS client certs with httpd, they may not be 
sent-over to Tomcat and will therefore be unavailable for use from 
Tomcat -> SiteMinder. You can fix this with some 
SSLProxySomethingOrOther directives on the httpd side and the SSLValve 
on the Tomcat side. Note that if you aren't using SSLValve you probably 
are *also* not using RemoteIPValve, which you probably want to use.


-chris


-Original Message-
From: jonmcalexan...@wellsfargo.com.INVALID

Sent: Tuesday, July 12, 2022 5:22 PM
To: users@tomcat.apache.org
Subject: RE: [OT] issues with Tomcat to Siteminder communication post mod-
proxy setup

I'm wondering if it is having to do with the SMSESSION cookie not getting
passed correctly. Still trying to figure this one out.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you
must not use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you
for your cooperation.


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 12, 2022 9:16 AM
To: users@tomcat.apache.org
Subject: Re: [OT] issues with Tomcat to Siteminder communication post
mod- proxy setup

Jon,

On 7/8/22 16:48, jonmcalexan...@wellsfargo.com.INVALID wrote:

Chris,

Moving this discussion to here. Yes, it appears that I broke
something when

setting up the Tomcat Connector for the mod-proxy that is now
affecting, somehow, the SSL communication with the Site Minder
services. Here is the connector we added below.

The only reason I can think of that would cause your Tomcat TLS
connector configuration to affect your SiteMinder thing is if you are
trying to specify the javax.net.ssl.trustStore system property for the
entire JVM, and allowing Tomcat to inherit that.


Temporarily have set certificateVerification to optional to see if
it was something with the communication between HTTPD and Tomcat.

  
maxThreads="100"

compression="on" scheme="https" SSLEnabled="true" secure="true">

  
certificateVerification="optional" truststoreFile="" truststorePassword=""
truststoreType="JKS"


ciphers="TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,


Assuming truststoreFile is not actually _blank_, then this should be fine.


  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
  TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
  TLS_DHE_RSA_WITH_AES_128_CCM,
  TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
  TLS_DHE_RSA_WITH_AES_128_CCM_8,
  TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,
  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256">

 

Re: Secondary Authentication method for application

2022-07-20 Thread Christopher Schultz

Tim,

On 7/12/22 10:09, Tim K wrote:

Hello,
I currently have a custom realm in Tomcat 9 that uses form
authentication (j_username/j_password POST to j_security_check).  I'm
looking to create a secondary way to establish an authenticated
session.  I want to allow trusted sources to be able to POST a
username param to a specific URL and establish an authenticated
session with that provided username (I know, seems kind of scary, but
it's just for a proof of concept right now).  Eventually this
secondary method may replace the custom realm all together, i.e.
offloading authentication to an external provider.

I've searched the list and other internet sources which led me to
attempt to extend the ValveBase to try and set a UserPrincipal on the
org.apache.catalina.connector.Request.  I was trying to intercept POST
requests to a new specific RequestURI and if the provided username
param is acceptable, I do the request.setUserPrincipal with the role
that is required.

Am I going down the wrong path to accomplish this?  When the valve
code gets hit, It doesn't seem that the user is really getting
authenticated; I believe because the request comes/goes and the
principal is getting lost when the request is done...

Also, I'm getting a 405 error on the actual POST, even though it
appears the principal gets established for that request...  Not sure
if this has something to do with the JSESSIONID cookie...


There isn't much magic to what Tomcat does for a (normal) login. It just 
does the authentication (which you will handle) and shoves an object 
into the user's session. You can't access that object, but it drives the 
return values of Request.getUserPrincipal() and Request.isInRole().


You can very easily use a Filter to wrap the request in your own wrapper 
(hint: extend HttpRequestWrapper) and return whatever values from 
wherever you want them to go. You can maintain your own authentication 
source however you want. The big advantage to doing this is that you 
will end up with a container-agnostic solution that will continue to 
work even if Tomcat changes something it does. It's always best to have 
a standards-based solution.


Something like this:

class MyAuthenticationFilter implements Filter {
  public void filter(ServletRequest request, ServletResponse response, 
FilterChain chain) {

// Do all the checking/casting for HttpStuff
request = new MyAuthenticationWrapper(httpRequest);

chain.doFilter(request, response);
  }

  static interface MyPrincipal extends Principal {
public boolean isInRole(String role);
  }

  static class MyAuthenticationWrapper extends HttpServletRequestWrapper {
public static final String PRINCIPAL_KEY = "my.auth.principal";

public MyAuthenticationWrapper(HttpServletRequest request) {
  super(request);
}

public Principal getUserPrincipal() {
  Principal p = super.getUserPrincipal();

  if(null == p) {
HttpSession session = getSession(false);

if(null != session) {
  p = (Principal)session.getAttribute(PRINCIPAL_KEY);
}
  }

  return p;
}

public boolean isInRole(String role) {
  Principal p = getUserPrincipal();
  if(p instanceof MyPrincipal) {
return ((MyPrincipal)p).isInRole(role);
  } else {
// Let the container decide
return super.isInRole(role);
  }
}

// TODO: If you are really paranoid about your code, you should
//   wrap getSession to return a wrapped session that doesn't
//   allow anyone to set (or maybe even GET) a value for the
//   PRINCIPAL_KEY.
  }
}

Now, to authenticate your users using your hand-wavy authentication, 
just shove something into the HttpSession which implements MyPrincipal. 
Users who login as usual will get a "normal" principal and the container 
will handle the role checks. If you put an object in the session with 
the right key, this will work because the container doesn't have a 
container-managed Principal.


-chris

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



Re: Package TOMCAT 9.0.54 for Ubuntu 20.04

2022-07-12 Thread Christopher Schultz

Rhea,

On 7/12/22 02:58, Rhea Moubarak wrote:

This is the link to the bug we are facing:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64195

Is it fixed in 9.0.31?


Do you mean "is it fixed in the latest Tomcat 9.0.31 package available 
from Ubuntu?"


I think you'd have to ask Ubuntu that.

You might be able to find it in the changelog:

$ apt-get changelog tomcat9

Which version of Ubuntu are you using?

By the way, the bug you reference was never fixed. It was marked as a 
duplicate of this one: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=64202 (which WAS fixed).


This was not flagged as a security bug. You originally asked about 
security bugs, but this one is not listed as a security fix. So it's 
unlikely to have been back-ported to the Ubuntu repository.


-chris


-Original Message-----
From: Christopher Schultz 
Sent: Friday, July 8, 2022 8:57 PM
To: users@tomcat.apache.org
Subject: Re: Package TOMCAT 9.0.54 for Ubuntu 20.04

Rhea,

On 7/8/22 05:53, Rhea Moubarak wrote:

I asked Ubuntu-devel-discus if it's possible to integrate TOMCAT 9.0.54 in the 
official repositories of Ubuntu 20.04 as it helps fixing major security issues 
on TOMCAT installations.

(https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2022-July/0192
97.html)



They responded with the following:


Hi Rhea,



but gladly this isn't plain 9.0.31.



There was a similar bug request [1] which got resolved a while ago in [2] and I 
think has solved all those security issues in the 9.0.31 version that is in 
Focal.







On the other side there is the SRU policy [3] which prevents too big version 
jumps unless there is extra focus on stability and testing which needs further 
effort and dedication which for tomcat9 being only in universe isn't provided 
by anyone at the moment.







[1]: https://bugs.launchpad.net/ubuntu/+source/tomcat9/+bug/1915911



[2]: https://launchpad.net/ubuntu/+source/tomcat9/9.0.31-1ubuntu0.2



[3]: https://wiki.ubuntu.com/StableReleaseUpdates


Is it possible from anyone from your side to help with the stability
and testing of the version 9.0.54 to satisfy the SRU policy of Ubuntu?


We are all volunteers. If you'd like to volunteer to assemble the information we'd need 
to fulfill such a "stability and testing" plan, we might be able to move 
forward.

The Debian and Ubuntu teams track this project and incorporate patches (which 
is how *those* projects work, not Apache Tomcat which releases new versions for 
security fixes) for security issues as appropriate.

Whatever is in 9.0.54 that you need might actually be available through the Ubuntu 
package repository under the package whose nominal version number appears to be 
"9.0.31". You should read the release notes of the package history to see what 
security items have been addressed in their latest version. You may find that 
apache-tomcat-9.0.31-ubuntu-rev48 (or
whatever) addresses all of the reported CVEs between 9.0.31 and 9.0.54 even if 
the version number hasn't changed.

If you have a security auditor who is looking at software version numbers 
instead of the effective security provided from the package, you may have to 
either switch auditors, or switch package managers/repositories to one which 
meets your auditors requirements.

-chris

-
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



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



Re: [OT] issues with Tomcat to Siteminder communication post mod-proxy setup

2022-07-12 Thread Christopher Schultz

Jon,

On 7/8/22 16:48, jonmcalexan...@wellsfargo.com.INVALID wrote:

Chris,

Moving this discussion to here. Yes, it appears that I broke something when 
setting up the Tomcat Connector for the mod-proxy that is now affecting, 
somehow, the SSL communication with the Site Minder services. Here is the 
connector we added below.


The only reason I can think of that would cause your Tomcat TLS 
connector configuration to affect your SiteMinder thing is if you are 
trying to specify the javax.net.ssl.trustStore system property for the 
entire JVM, and allowing Tomcat to inherit that.


Temporarily have set certificateVerification to optional to see if 
it was something with the communication between HTTPD and Tomcat.


 

 

Assuming truststoreFile is not actually _blank_, then this should be fine.


 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
 TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
 TLS_DHE_RSA_WITH_AES_128_CCM,
 TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
 TLS_DHE_RSA_WITH_AES_128_CCM_8,
 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,
 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256">

 


Note: none of the TLS_XXX_ECDSA_* cipher suites will do anything for 
you, since you are using only an RSA key.


Is your SiteMinder client code using its own special trust store and key 
store? If you are getting a handshake failure (mentioned in your message 
to dev@httpd but not here yet: "javax.net.ssl.SSLHandshakeException: 
Received fatal alert: bad_certificate error"), you might want to start 
looking there. The problem is very unlikely to be your Tomcat 
configuration or anything related to it, unless you use the same key 
store and trust store for both.


-chris

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



Re: Package TOMCAT 9.0.54 for Ubuntu 20.04

2022-07-08 Thread Christopher Schultz

Rhea,

On 7/8/22 05:53, Rhea Moubarak wrote:

I asked Ubuntu-devel-discus if it's possible to integrate TOMCAT 9.0.54 in the 
official repositories of Ubuntu 20.04 as it helps fixing major security issues 
on TOMCAT installations.

(https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2022-July/019297.html)



They responded with the following:


Hi Rhea,



but gladly this isn't plain 9.0.31.



There was a similar bug request [1] which got resolved a while ago in [2] and I 
think has solved all those security issues in the 9.0.31 version that is in 
Focal.







On the other side there is the SRU policy [3] which prevents too big version 
jumps unless there is extra focus on stability and testing which needs further 
effort and dedication which for tomcat9 being only in universe isn't provided 
by anyone at the moment.







[1]: https://bugs.launchpad.net/ubuntu/+source/tomcat9/+bug/1915911



[2]: https://launchpad.net/ubuntu/+source/tomcat9/9.0.31-1ubuntu0.2



[3]: https://wiki.ubuntu.com/StableReleaseUpdates


Is it possible from anyone from your side to help with the stability
and testing of the version 9.0.54 to satisfy the SRU policy of Ubuntu?


We are all volunteers. If you'd like to volunteer to assemble the 
information we'd need to fulfill such a "stability and testing" plan, we 
might be able to move forward.


The Debian and Ubuntu teams track this project and incorporate patches 
(which is how *those* projects work, not Apache Tomcat which releases 
new versions for security fixes) for security issues as appropriate.


Whatever is in 9.0.54 that you need might actually be available through 
the Ubuntu package repository under the package whose nominal version 
number appears to be "9.0.31". You should read the release notes of the 
package history to see what security items have been addressed in their 
latest version. You may find that apache-tomcat-9.0.31-ubuntu-rev48 (or 
whatever) addresses all of the reported CVEs between 9.0.31 and 9.0.54 
even if the version number hasn't changed.


If you have a security auditor who is looking at software version 
numbers instead of the effective security provided from the package, you 
may have to either switch auditors, or switch package 
managers/repositories to one which meets your auditors requirements.


-chris

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



Re: AW: SSL handshake failure logs required for auditing purpose

2022-07-08 Thread Christopher Schultz

Raghav,

On 7/8/22 06:36, Ragavendhiran Bhiman (rabhiman) wrote:

That’s great, and thank ful for your reply.

Kindly look my below mail for my doubts,

And need one more query can we have the same jar updated to 9.0.x lower 
versions?

If that particular jar is updated what is the jar?

If jar is not possible what is the way we can get the solution to 9.0.x lower 
versions.


Does via syslog this solution is possible?


You can also get all of this using a network tap, sending it anywhere 
you want. No need to modify any software or even trust that the software 
is configured properly. Tomcat could be lying to you, and allowing 
failed connections from apache.org to be silently ignored.


It just occurred to me that your request suggests that (your) Tomcat is 
being used directly by clients on the public internet. This is obviously 
a perfectly valid setup, but if I were running a publicly-accessible 
web-based application (which I do for $work), I would put something 
between the internet and my application to terminate TLS, perform 
load-balancing, etc. for a number of reasons. Is there any reason not to 
use another product that does *exactly* what you want, here?


FWIW, I'm not sure if AWS/Azure/Oracle, httpd, nginx, squid, haproxy, 
etc. will report TLS handshake failures in a way that is acceptable to 
you and your certification body, either. I was just wondering...


-chris


From: Ragavendhiran Bhiman (rabhiman) 
Date: Friday, 8 July 2022 at 7:33 AM
To: Tomcat Users List 
Subject: Re: AW: SSL handshake failure logs required for auditing purpose
Thanks a lot for all your replies.

This auditing is for common criteria certification. The OS we use is  Red-hat 
Linux.
As you know common criteria requires these handshake failures need to be 
redirected to a syslog server.
Any attempt via the tcp-dump/wireshark is not acceptable by the certification.
So it needs to be only the syslogs.
I think from 9.0.65 it should be easy.
For the existing versions yes the log needs to be in syslog until it rotates.
If it gives cipher details that’s good, but importantly it should give the Ips.

Once again thanks a lot for your overwhelming responses. If I will be able to 
close this today, it is pretty great.

Also let me know in 9.0.65 is there any detailed attempt made to log about the 
ssl handshake including the ciphers etc.,?

Regards,

Raghav

From: Christopher Schultz 
Date: Friday, 8 July 2022 at 12:05 AM
To: users@tomcat.apache.org 
Subject: Re: AW: SSL handshake failure logs required for auditing purpose
Thomas,

On 7/7/22 13:36, Thomas Hoffmann (Speed4Trade GmbH) wrote:




-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH)

Gesendet: Donnerstag, 7. Juli 2022 19:23
An: Tomcat Users List 
Betreff: AW: SSL handshake failure logs required for auditing purpose

Hello Raghav,


-Ursprüngliche Nachricht-
Von: Ragavendhiran Bhiman (rabhiman) 
Gesendet: Donnerstag, 7. Juli 2022 18:13
An: Tomcat Users List 
Betreff: Re: SSL handshake failure logs required for auditing purpose

Version of tomcat used 9.0.x.
Kindly help on the ssl logging for auditing purpose other than -D
javax.net option.

From: Ragavendhiran Bhiman (rabhiman) 
Date: Thursday, 7 July 2022 at 9:41 PM
To: users@tomcat.apache.org 
Subject: SSL handshake failure logs required for auditing purpose Hi
All,

I require your kind help in logging the SSl connection failure logs
including iP in the tomcat, Is there any best way to do It without
performance impact other than -Djava.net debugs in jdk, is there any
direct way from tomcat? Or any way we can derive any class from JSSE
extension classes and add HandShakeListener while using the
connectors. All our SSL connections are going through connectors. So
kindly need your help how to log those SSL connection auditing logs

through best method.

Thanks a lot in advance.

Regards,
Raghav


Which OS are you using?
Can you use Wireshark or TCPDump for your purposes?
If you are using Chrome or FF as Client, you can set the environment variable
SSLKEYLOGFILE to write the current key to a file which Wireshark can take to
decrypt the traffic.

The handshake itself is not encrypted. If the handshake is enough, TCPDump
or Wireshark are sufficient.

Greetings,
Thomas



Short Addendum:
1) Do you want to write the log permanently or just for an audit session?
2) Which details do you want to log? Agreed cipher? Offered ciphers by the 
client? SNI-header? ...?
3) What is the purpose of the logging?
  Insecure ciphers can be mitigated by server configuration.


I think he wants to implement a poor-mans NIDS.

Raghav, please be aware that any web browser that first attempts to use
a SSLv3/TLSv1/TLSv1.3 handshake, fails, and retries with a
TLSv1.2/similar handshake will cause massive numbers of false-positives
in your logs.

I would ask whoever is requesting this logging why they are looking at
such failures. Handshake failures are not always indicative of some kind
of intrusion attempt

Re: AW: SSL handshake failure logs required for auditing purpose

2022-07-07 Thread Christopher Schultz

Thomas,

On 7/7/22 13:36, Thomas Hoffmann (Speed4Trade GmbH) wrote:




-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH)

Gesendet: Donnerstag, 7. Juli 2022 19:23
An: Tomcat Users List 
Betreff: AW: SSL handshake failure logs required for auditing purpose

Hello Raghav,


-Ursprüngliche Nachricht-
Von: Ragavendhiran Bhiman (rabhiman) 
Gesendet: Donnerstag, 7. Juli 2022 18:13
An: Tomcat Users List 
Betreff: Re: SSL handshake failure logs required for auditing purpose

Version of tomcat used 9.0.x.
Kindly help on the ssl logging for auditing purpose other than -D
javax.net option.

From: Ragavendhiran Bhiman (rabhiman) 
Date: Thursday, 7 July 2022 at 9:41 PM
To: users@tomcat.apache.org 
Subject: SSL handshake failure logs required for auditing purpose Hi
All,

I require your kind help in logging the SSl connection failure logs
including iP in the tomcat, Is there any best way to do It without
performance impact other than -Djava.net debugs in jdk, is there any
direct way from tomcat? Or any way we can derive any class from JSSE
extension classes and add HandShakeListener while using the
connectors. All our SSL connections are going through connectors. So
kindly need your help how to log those SSL connection auditing logs

through best method.

Thanks a lot in advance.

Regards,
Raghav


Which OS are you using?
Can you use Wireshark or TCPDump for your purposes?
If you are using Chrome or FF as Client, you can set the environment variable
SSLKEYLOGFILE to write the current key to a file which Wireshark can take to
decrypt the traffic.

The handshake itself is not encrypted. If the handshake is enough, TCPDump
or Wireshark are sufficient.

Greetings,
Thomas



Short Addendum:
1) Do you want to write the log permanently or just for an audit session?
2) Which details do you want to log? Agreed cipher? Offered ciphers by the 
client? SNI-header? ...?
3) What is the purpose of the logging?
 Insecure ciphers can be mitigated by server configuration.


I think he wants to implement a poor-mans NIDS.

Raghav, please be aware that any web browser that first attempts to use 
a SSLv3/TLSv1/TLSv1.3 handshake, fails, and retries with a 
TLSv1.2/similar handshake will cause massive numbers of false-positives 
in your logs.


I would ask whoever is requesting this logging why they are looking at 
such failures. Handshake failures are not always indicative of some kind 
of intrusion attempt.


-chris

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



Re: Tomcat in distroless image

2022-07-06 Thread Christopher Schultz

Stefan,

On 7/6/22 18:50, Stefan Mayr wrote:

Am 05.07.2022 um 23:36 schrieb Pawel Veselov:

Christopher, Stephan,

On Tue, Jul 5, 2022 at 11:18 PM Christopher Schultz
 wrote:


Stefan,

On 7/2/22 09:45, Stefan Mayr wrote:

Hi,

Am 01.07.2022 um 17:10 schrieb Christopher Schultz:

Thomas,

On 6/30/22 13:52, Thomas Meyer wrote:

Sadly currently Tomcat startup relies on shell script to bootstrap
JVM process.

In the light of distroless images (e.g.
https://blog.chainguard.dev/introducing-apko-bringing-distroless-nirvana-to-alpine-linux/) 




What are you thoughts on packaging tomcat in distroless base OCI
images that doesn't even contain any shell anymore?

Would it be possible to provide an alternative start mechanism which
directly starts JVM process which setup/prepare env like the current
catalina.sh shell script does?

What are your thoughts on above topic?


Speaking for myself, here, of course.

The Tomcat team doesn't package anything other than the "standard
distributions" such as the source and the pre-built Java binaries, 
plus

the Windows binaries for various things. We don't package anything
specific like Docker base containers, etc. and I don't think we 
want to

get into that business.

If someone in the community wants to do something like that: go for 
it.

But we have enough to do already and don't want to play favorites.

The only reason catalina.sh exists is to figure out what's going on 
with

the hosting environment. If you want to build a launch-process that is
integrated into a specific environment, then you don't need all that
tooling to figure out what is what: you can just write one big command
line and launch the JVM with all the necessary arguments.


I agree with that. In my opinion this part of environment detection is
not necessary in a container because a container is immutable. So it
should be enough to run Tomcat the way you want to have it and copy &
paste the java command line into our container image generation 
manifest

(e.g. Dockerfile).

To use Tomcat in a more container friendly way you should consider also
some other things too:
- because containers are static there is no need to explode WAR 
files or

scan the directory for changes. The extracted application can be copied
into the image and server.xml can be tuned to disable those features.
- you should avoid logging into files and tune the logging 
configuration

to log everything to stdout and stderr


Logging to stdout and stderr is a sure way to get oneself into a
serious bottleneck.


Maybe, but this is the convention most have agreed on for stateless 
(container) applications. It is factor #11 of the 12 factor app 
principles (https://12factor.net/logs).
As always, your choices depend on the infrastructure you have. Runnning 
on a single docker host with an image customized for your needs? Then 
you can always mount the local filesystem into your container to write 
your logs on. Is this an image you deliver to your customers or that 
will run in kubernetes? So don't log into files and stick to the 
defaults: log to stdout and stderr



This is something that I really don't understand about containerized
applications running like this. Maybe I'm too old-skool and think that
application logs go into application-log files and access-logs go into
access-log files.

Assuming an ideal case, where should all of these things go if your
choices are "stdout" or "stderr"?

1. HTTP Access logs
2. HTTP access logs from multiple virtual hosts (or is the idea that one
container ~= 1 virtual host)
3. Server logs (e.g. DEBUG/INFO/WARN coming from the app server)
4. Application logs (e.g. DEBUG/INFO/WARN coming from the application)
5. Application logs for applications other than the primary (e.g. Tomcat
Manager)


They don't go to files. They get sent to a logging router instead
(e.g., Fluentd), which send them to logging aggregators (e.g.,
Graylog)


And because it is very hard to parse those logs in a sensible way it is 
becoming increasingly popular for container apps to use a json based log 
format. This is "ugly" but still somewhat readable for human users and 
almost all central logging solutions have a built-in json parser. No 
regex-vodoo to parse multiline output required (e.g. Stacktraces). 
Switching from raw text to a structed log format also improves the 
posibilities for your search queries a lot.


Addressing questions 2 and 5: it is best practice to have only one 
application in your container and remove everything also. So having 
multiple applications would usually result in multiple different 
containers. They might share the same (Java+Tomcat) baseimage but 
include different apps. A container image is an immutable artefact. As 
such they should have a bit of "hardening" and I would not expect 
something like the manager app in a container. Changes should result in 
new images.


We use JMX extensively for our applications, including for

Re: JS fiddle for generating TLS keys and certs

2022-07-06 Thread Christopher Schultz

All,

If anyone was interested, I have an update:

https://jsfiddle.net/ny1egwaz/3/

-chris

On 6/28/22 12:43, Christopher Schultz wrote:

All,

I recently built this into an application at $work and I figured I would 
give it away for anyone who might get some use out of it.


https://jsfiddle.net/ny1egwaz/

It doesn't actually generate a key + cert – nor should you ever trust 
another site to generate your keys for you!. Instead, it gives you 
copy/paste commands that you can use to generate those keys + certs on 
your own computer, and spits them out on standard output you can can 
install them wherever you need them.


Suggestions welcome.

-chris


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



Re: Tomcat freezes with axios

2022-07-06 Thread Christopher Schultz

Stephane,

On 7/6/22 07:12, Stephane Passignat wrote:
Thanks for your help. I found that someone else was freezing the API 
server through the database (very long running uncommitted transactions).


That'll definitely do it.

This kind of thing isn't going to work in the real-world: tying-up a 
database with a transaction that lasts even a few seconds is going to 
absolutely kill your performance.


You need to work with that other group to figure out why they need 
long-running transactions and figure out how to solve the problem in a 
different way.


You should also protect yourself and set timeouts on writes that, if 
they fail, they fail "fast" and don't appear to freeze. You should be 
able to detect a write-timeout and reply to the API user saying "sorry, 
write failed after N ms" or something like that. Otherwise, you run the 
risk of a single uncommitted transaction stalling your entire business 
while writes pile-up. Users tired of waiting will re-request the same 
write over and over again. When the initial transaction finally commits, 
you'll have a huge storm of writes hitting your database all at the same 
time. It will be a mess.


Anyway I also limited the number of parallel connections on javascript 
side (axios).


This is always an excellent idea. There is no reason for a single client 
to be making huge numbers of queries to your database simultaneously.


-chris


Le 2022-06-30 à 18:42, Christopher Schultz a écrit :

All,

On 6/30/22 02:34, Mark Thomas wrote:

Hi,

We need more information to help you.

Tomcat version?

Tomcat connector configuration (from server.xml)?

httpd version?

httpd MPM and configuration?

mod_proxy configuration?

Was the httpd restart graceful or not?


Wild guess: missing finally { java.sql.Connection.close(); }

-chris


On 29/06/2022 19:36, Stephane Passignat wrote:

Hello,

I'm creating a SAP application performing REST call on an API 
running on Tomcat. Tomcat runs behind an apache reverse-proxy and 
communication between them use http. The calls are executed with 
axios using a basic authentication.



Everything runs fine for a moment, but for an unknown reason all 
http request are hanging after some time and hundreds or maybe 
thousands requests (if these metrics make any sense).



In chrome, the requests are in a 'pending' status.

Restarting chrome allows to do one or two requests and then issue 
occurs again


Restarting apache doesn't change anything.

Restarting Tomcat resolve the situation. Tomcat shutdow is a bit 
longer. Request in chrome ends when tomcat stops.



I'm not very inspired by this issue and actually trying to find 
inspiration in jmx and log files but nothing pops up.



Does someone have an idea ?



thanks

Stephane


-
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



-
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 in distroless image

2022-07-05 Thread Christopher Schultz

Stefan,

On 7/2/22 09:45, Stefan Mayr wrote:

Hi,

Am 01.07.2022 um 17:10 schrieb Christopher Schultz:

Thomas,

On 6/30/22 13:52, Thomas Meyer wrote:

Sadly currently Tomcat startup relies on shell script to bootstrap
JVM process.

In the light of distroless images (e.g.
https://blog.chainguard.dev/introducing-apko-bringing-distroless-nirvana-to-alpine-linux/) 



What are you thoughts on packaging tomcat in distroless base OCI 
images that doesn't even contain any shell anymore?


Would it be possible to provide an alternative start mechanism which
directly starts JVM process which setup/prepare env like the current
catalina.sh shell script does?

What are your thoughts on above topic?


Speaking for myself, here, of course.

The Tomcat team doesn't package anything other than the "standard
distributions" such as the source and the pre-built Java binaries, plus
the Windows binaries for various things. We don't package anything
specific like Docker base containers, etc. and I don't think we want to
get into that business.

If someone in the community wants to do something like that: go for it.
But we have enough to do already and don't want to play favorites.

The only reason catalina.sh exists is to figure out what's going on with
the hosting environment. If you want to build a launch-process that is
integrated into a specific environment, then you don't need all that
tooling to figure out what is what: you can just write one big command
line and launch the JVM with all the necessary arguments.


I agree with that. In my opinion this part of environment detection is 
not necessary in a container because a container is immutable. So it 
should be enough to run Tomcat the way you want to have it and copy & 
paste the java command line into our container image generation manifest 
(e.g. Dockerfile).


To use Tomcat in a more container friendly way you should consider also 
some other things too:
- because containers are static there is no need to explode WAR files or 
scan the directory for changes. The extracted application can be copied 
into the image and server.xml can be tuned to disable those features.
- you should avoid logging into files and tune the logging configuration 
to log everything to stdout and stderr


This is something that I really don't understand about containerized 
applications running like this. Maybe I'm too old-skool and think that 
application logs go into application-log files and access-logs go into 
access-log files.


Assuming an ideal case, where should all of these things go if your 
choices are "stdout" or "stderr"?


1. HTTP Access logs
2. HTTP access logs from multiple virtual hosts (or is the idea that one 
container ~= 1 virtual host)

3. Server logs (e.g. DEBUG/INFO/WARN coming from the app server)
4. Application logs (e.g. DEBUG/INFO/WARN coming from the application)
5. Application logs for applications other than the primary (e.g. Tomcat 
Manager)


-chris

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



Re: Tomcat in distroless image

2022-07-01 Thread Christopher Schultz

Thomas,

On 6/30/22 13:52, Thomas Meyer wrote:

Sadly currently Tomcat startup relies on shell script to bootstrap
JVM process.

In the light of distroless images (e.g.
https://blog.chainguard.dev/introducing-apko-bringing-distroless-nirvana-to-alpine-linux/)

What are you thoughts on packaging tomcat in distroless base OCI 
images that doesn't even contain any shell anymore?


Would it be possible to provide an alternative start mechanism which
directly starts JVM process which setup/prepare env like the current
catalina.sh shell script does?

What are your thoughts on above topic?


Speaking for myself, here, of course.

The Tomcat team doesn't package anything other than the "standard
distributions" such as the source and the pre-built Java binaries, plus
the Windows binaries for various things. We don't package anything
specific like Docker base containers, etc. and I don't think we want to
get into that business.

If someone in the community wants to do something like that: go for it.
But we have enough to do already and don't want to play favorites.

The only reason catalina.sh exists is to figure out what's going on with
the hosting environment. If you want to build a launch-process that is
integrated into a specific environment, then you don't need all that
tooling to figure out what is what: you can just write one big command
line and launch the JVM with all the necessary arguments.

-chris

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



Food for thought: /dev/random vs /dev/urandom

2022-07-01 Thread Christopher Schultz

All,

This war has been raging on for years. I for one consider myself 
"practical" when it comes to security. I think this write-up makes some 
good arguments, even if the top section is a little difficult to parse 
(it's sometimes tough to differentiate the author's words from that of 
the hypothetical foil):


https://www.2uo.de/myths-about-urandom/

Unfortunately, it doesn't have a "freshness" date on it, but he talks 
about specific Linux kernel versions, so there is at least a "no earlier 
than" date on it.


I'm not trying to start a flame-war about randomness, here. Just sharing 
information I found interesting to read.


-chris

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



Re: Tomcat freezes with axios

2022-06-30 Thread Christopher Schultz

All,

On 6/30/22 02:34, Mark Thomas wrote:

Hi,

We need more information to help you.

Tomcat version?

Tomcat connector configuration (from server.xml)?

httpd version?

httpd MPM and configuration?

mod_proxy configuration?

Was the httpd restart graceful or not?


Wild guess: missing finally { java.sql.Connection.close(); }

-chris


On 29/06/2022 19:36, Stephane Passignat wrote:

Hello,

I'm creating a SAP application performing REST call on an API running 
on Tomcat. Tomcat runs behind an apache reverse-proxy and 
communication between them use http. The calls are executed with axios 
using a basic authentication.



Everything runs fine for a moment, but for an unknown reason all http 
request are hanging after some time and hundreds or maybe thousands 
requests (if these metrics make any sense).



In chrome, the requests are in a 'pending' status.

Restarting chrome allows to do one or two requests and then issue 
occurs again


Restarting apache doesn't change anything.

Restarting Tomcat resolve the situation. Tomcat shutdow is a bit 
longer. Request in chrome ends when tomcat stops.



I'm not very inspired by this issue and actually trying to find 
inspiration in jmx and log files but nothing pops up.



Does someone have an idea ?



thanks

Stephane


-
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



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



Re: State of the Cat 2022

2022-06-30 Thread Christopher Schultz

Rémy, all,

On 6/28/22 09:58, Rémy Maucherat wrote:

On Tue, Jun 28, 2022 at 3:38 PM Christopher Schultz
 wrote:


Rémy,

On 6/28/22 05:33, Rémy Maucherat wrote:

On Mon, Jun 27, 2022 at 11:37 PM Christopher Schultz
 wrote:


Cathy,

On 6/27/22 15:01, Cathy Spears wrote:

Wondering if there will be a State of the cat 2022.


Rémy is scheduled to give a talked called "[Tomcat:] New and Upcoming"
at ApacheCon North America in October. I would imagine it would be very
similar to State of the Cat though perhaps without any retrospective info.


I'll integrate a lot of the content from the state of the cat, since
Mark is not coming this time.

BTW, when is the full conference schedule going to be out ?


When all of the "your presentation has been accepted" messages went out,
there were a FLOOD of requests for specific times, specific days, etc.
and so the folks working on the schedule (mostly Brian Proffitt, I
think) are losing their minds trying to figure it all out.

I'm not sure what their target date is for having the schedule complete,
but they are "working on it."


Makes sense. Since the Tomcat track is only one day, I'm not planning
on staying a full week. So have to wait for the schedule now.


Looks like it's up:

https://www.apachecon.com/acna2022/schedule.html

Unfortunately, there is no overarching schedule or anything on there, 
yet. Just a huge list of presentations and their date/times.


It looks like the Tomcat Track is on Wednesday 5 October. You are 
first-thing in the morning.


-chris

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



Re: JS fiddle for generating TLS keys and certs

2022-06-29 Thread Christopher Schultz

Jason,

On 6/28/22 20:41, Jason Tan wrote:

Looks good, Chris. I'll give it a try when I need to generate some
keys and cert next. SSL keys and certs concepts sounds logical and
easy but generating them is such a pain. No GUI tool to consolidate
and perform the lot for self signed. I started using keystore
explorer to examine the generated certs and keystore to understand it
better.


Does KSE not handle self-signed certs? By default, Java's keytool 
produces self-signed certs, and Keystore Explorer was written to work 
primarily with Java keystores (I think).



It doesn't help things that different app and different app
versions may have different security requirements which means old
keys and certs no longer work in the newer version. Or work for one
app but not a different app.
Every product should work with PKCS12 files. Forget JKS and JCEKS. KSE 
should be able to export to PEM, which is IMO the easiest possible file 
format to work with. Every product should work with X.509 certs, but 
some may have different requirements for what they will accept in terms 
of bit-strength-levels and stuff like that. For example, minting a 
512-bit RSA key is not acceptable these days, but it's possible to do.


I think you just need to become more familiar with "industry standard" 
acceptable practices if you are going to be responsible for generating 
your own keys and certs.


My tool tries to make it difficult for you to create garbage. For 
example, it doesn't allow you to create an RSA key with less than 3072 
bits, or an EC key with less than 128 bits. It encourages you to use 
4096 / 256 (but should include 384, honestly) because those are fairly 
forward-looking big-strengths.


-chris

[1] https://keystore-explorer.org/


-Original Message-----
From: Christopher Schultz 
Sent: Wednesday, 29 June 2022 2:44 AM
To: Tomcat Users List 
Subject: JS fiddle for generating TLS keys and certs

All,

I recently built this into an application at $work and I figured I would give 
it away for anyone who might get some use out of it.

https://jsfiddle.net/ny1egwaz/

It doesn't actually generate a key + cert – nor should you ever trust another 
site to generate your keys for you!. Instead, it gives you copy/paste commands 
that you can use to generate those keys + certs on your own computer, and spits 
them out on standard output you can can install them wherever you need them.

Suggestions welcome.

-chris

-
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



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



JS fiddle for generating TLS keys and certs

2022-06-28 Thread Christopher Schultz

All,

I recently built this into an application at $work and I figured I would 
give it away for anyone who might get some use out of it.


https://jsfiddle.net/ny1egwaz/

It doesn't actually generate a key + cert – nor should you ever trust 
another site to generate your keys for you!. Instead, it gives you 
copy/paste commands that you can use to generate those keys + certs on 
your own computer, and spits them out on standard output you can can 
install them wherever you need them.


Suggestions welcome.

-chris

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



Re: Error While importing certificate into keystore

2022-06-28 Thread Christopher Schultz

Mohan,

On 6/28/22 09:54, Mohan T wrote:
I am trying top import the certificate into keystore and encountered the 
below error.


Would appreciate if you could throw some light on this

$ keytool -importkeystore -srckeystore /home/ilas/Downloads/okta.cert 
-srcstoretype pkcs12 -destkeystore /home/ilas/Downloads/keystore.jks 
-deststoretype JKS


Importing keystore /home/ilas/Downloads/okta.cert to 
/home/ilas/Downloads/keystore.jks...


Enter destination keystore password:

Enter source keystore password:

keytool error: java.io.IOException: toDerInputStream rejects tag type 45


Open your okta.cert file in notepad/less or similar. Does it look like this?

-BEGIN CERTIFICATE-
[stuff]
-END CERTIFICATE-

If so, then you want to do this:

$ keytool -importcert -keystore /home/ilas/Downloads/keystore.jks -alias 
'Okta 2022' < /home/ilas/Downloads/okta.cert


The cert may be in DER format which is just the same format but not 
using base64-encoding with the -BEGIN and -END wrapper around 
it. keytool can read that type of cert as well using the command above.


If you aren't super comfortable with keystores, PEM and/or DER files, 
etc. then I would suggest that you use a tool that can help you manage 
these things that will help you avoid mistakes such as Keystore Explorer:

https://keystore-explorer.org/

-chris

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



Re: State of the Cat 2022

2022-06-28 Thread Christopher Schultz

Rémy,

On 6/28/22 05:33, Rémy Maucherat wrote:

On Mon, Jun 27, 2022 at 11:37 PM Christopher Schultz
 wrote:


Cathy,

On 6/27/22 15:01, Cathy Spears wrote:

Wondering if there will be a State of the cat 2022.


Rémy is scheduled to give a talked called "[Tomcat:] New and Upcoming"
at ApacheCon North America in October. I would imagine it would be very
similar to State of the Cat though perhaps without any retrospective info.


I'll integrate a lot of the content from the state of the cat, since
Mark is not coming this time.

BTW, when is the full conference schedule going to be out ?


When all of the "your presentation has been accepted" messages went out, 
there were a FLOOD of requests for specific times, specific days, etc. 
and so the folks working on the schedule (mostly Brian Proffitt, I 
think) are losing their minds trying to figure it all out.


I'm not sure what their target date is for having the schedule complete, 
but they are "working on it."


-chris

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



Re: Question ad 2021 presentation videos

2022-06-28 Thread Christopher Schultz

Rony,

On 6/28/22 05:44, Rony G. Flatscher (Apache) wrote:

Is there a link for the 2021 Tomcat presentation videos, if any?


Oh, I'm sorry. I was working on getting those onto the Presentations 
page and I got distracted and didn't finish.


I'll try to get back to that, today.

-chris

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



Re: State of the Cat 2022

2022-06-27 Thread Christopher Schultz

Cathy,

On 6/27/22 15:01, Cathy Spears wrote:

Wondering if there will be a State of the cat 2022.


Rémy is scheduled to give a talked called "[Tomcat:] New and Upcoming" 
at ApacheCon North America in October. I would imagine it would be very 
similar to State of the Cat though perhaps without any retrospective info.


-chris

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



Re: Root Module Deployment Error

2022-06-27 Thread Christopher Schultz

Seretseab,

On 6/27/22 09:01, Kenaw, Seretseab wrote:

We just upgraded from Tomcat 9.0.12 to 9.0.62, and after the upgrade the new 
Tomcat version is throwing an error while deploying the ROOT module. All the 
ROOT module has is a redirection to a specific page when the user tries to 
access the website. Here is the error message, any help is appreciated.
SEVERE: Error deploying deployment descriptor [E:\EBX1\EBX 
Server\conf\Catalina\localhost\ROOT.xml]
java.lang.IllegalStateException: Error starting child
   at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:729)
   at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698)
   at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696)
   at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:690)
   at 
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1889)
   at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
   at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
   at 
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
   at 
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
   at 
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:583)
   at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:473)
   at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618)
   at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319)
   at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
   at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
   at 
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
   at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946)
   at 
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
   at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
   at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
   at 
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
   at 
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
   at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
   at 
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:432)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:927)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
   at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
   at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)
Caused by: org.apache.catalina.LifecycleException: Failed to start component 
[OpenIDConnectAuthenticator[StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]]
   at 
org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
   at 
org.apache.catalina.core.StandardPipeline.startInternal(StandardPipeline.java:176)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5147)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at 

Re: Help Needed

2022-06-27 Thread Christopher Schultz

Mohan,

On 6/27/22 02:17, Mohan T wrote:

Dear All,

We have deployed a application in tomcat 8.5  and  while accessing

http://sebswarcnv08.ramco:8081/samldemo-0.0.1-SNAPSHOT/hello

Error retrieving metadata from 
https://dev-67198606.okta.com/app/exk5htsyx3S4UcaHA5d7/sso/saml/metadata
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


A stack trace will help, here.

The URL you have above has a TLS Certificate signed by DigiCert, which 
is a well-trusted Certificate Authority so, unless you have done 
something specific with your trust store for that connection, it's not 
likely the problem.


Because you are using SAML, I suspect that the error occurs when 
validating the SAML response itself, and your trust store does not 
contain the certificate required to validate the signed SAML response.


-chris

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



Re: AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

2022-06-15 Thread Christopher Schultz

Thomas,

On 6/15/22 03:08, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,


-Ursprüngliche Nachricht-
Von: Pavan Kumar Tiruvaipati 
Gesendet: Mittwoch, 15. Juni 2022 08:59
An: Christopher Schultz 
Cc: Tomcat Users List 
Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

Hi,

Tomcat server started successfully.

I'm seeing the following error in the tomcat logs when SSL is enabled in
server.xml

Application is not able to run on https://localhost:8080.

2022-06-15 12:02:43,923 [http-3003-1] DEBUG
*org.apache.tomcat.util.net.JIoEndpoint
- Handshake failed*

*javax.net.ssl.SSLHandshakeException: no cipher suites in common at
sun.security.ssl.Alert.createSSLException(Unknown Source) *

*at sun.security.ssl.Alert.createSSLException(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) *

*at sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Un
known
Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
Source) at
sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
Source) at
sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.TransportContext.dispatch(Unknown Source) at
sun.security.ssl.SSLTransport.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFac
tory.java:233)
at
org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
01)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:503)
at java.lang.Thread.run(Unknown Source)*

If I disable SSL in tomcat server.xml, It's working with Non-SSL (
http://localhost:8080).

Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
required to establish a handshake ?

Please let me know if you need more details.


Regards,
Pavan

On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Pavan,

Please reply to the list and not me personally.

On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:


maxSpareThreads="75"

 enableLookups="false" disableUploadTimeout="true"
 acceptCount="100"  scheme="https" secure="true"
connectionTimeout="2"
 clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
keystoreFile="conf/certificate" keystorePass="x"
useBodyEncodingForURI="true"
SSLEnabled="true"/>


That all looks pretty straightforward.

When you say it's "not working", can you be more specific? Does the
Tomcat server start? Are there any errors or warnings in the logs?

-chris


On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
mailto:ch...@christopherschultz.net>>

wrote:


 Pavan,

 On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
  > We have replaced JDK 1.8 with JRE 1.8.0_333.
  >
  > SSL configuration was working fine with Tomcat 6.0.45 before
 replacing JDK
  > with JRE.
  >
  > Now it's not working.
  >
  > In server.xml, SSL Protocol is set to "TLS".
  >
  > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
  >
  > Are there any specific protocols / versions to be used to enable
 SSL ?

 Please post your  configuration. Remove any secrets
that

may

 be in there (e.g. passwords).

 -chris





The error says that the client and the server couldn’t find a common cipher 
suite.
They couldn’t agree on any cipher.
Does your keystore contain a valid private key?


The problem is likely that Tomcat 6 (which is ancient) defaults to TLSv1 
and no higher (this is a guess; I'm not bothering to look at a 
14-year-old version of Tomcat to figure out what the problem really is). 
The client isn't willing to connect to such an ancient version of any 
protocol, so it fails with the handshake failure.



Maybe you can try to print out all available cipher suites on your environment:
https://stackoverflow.com/questions/9333504/how-can-i-list-the-available-cipher-algorithms
You can add the code to a jsp-page and print out the available algorithms.


Try explicitly setting the 

Re: AW: Filehandle left open when using sendfile

2022-06-15 Thread Christopher Schultz

Thomas,

On 6/15/22 02:26, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Christopher,


-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Dienstag, 14. Juni 2022 20:26
An: users@tomcat.apache.org
Betreff: Re: Filehandle left open when using sendfile

Thomas,

On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,
we are using Tomcat 10.0.16 under windows.
For sending files to the browser, we are using sendfile by setting the

attribute "org.apache.tomcat.sendfile.filename".

Streaming an image to the browser works well in this way.
But we observed that if the user tries to delete the file afterwards, there is

still a file-handle on this file.

Which user? Some admin on the server, or the user using the browser?
(Dumb question, I know, but tb and ff had a bug for a while where
downloads would leave dangling file handles, disallowing deleting those files
after they were downloaded.)


I took a look at NioEndpoint.java -->


https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util

/net/NioEndpoint.java

At line 869 there is a stream opened:
FileInputStream fis = new FileInputStream(f);

However, there is no close in this method. Maybe this might cause the

open file-handle?

Did you read the line above that?

  @SuppressWarnings("resource") // Closed when channel is closed
  FileInputStream fis = new FileInputStream(f);

The channel itself is cleaned-up properly and, with it, the file handle.

https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bb
aa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226

(At least, I *think* this is where the cleanup happens. I'm not very well-
versed in the connection-handling code in Tomcat.)


We are using protocol="org.apache.coyote.http11.Http11NioProtocol".. I

think there are different implementations for sendfile-feature.

The open file-handle can be observer via ProcessExplorer from Microsoft.


How long did you wait for the file handle to close?

Are you able to attach a debugger and see that the object hasn't been
cleaned-up?

-chris



Thanks for taking a look at it.
Sorry, if the setup was not described in detail. Maybe you can imagine an image 
library, hosted server-side.
The user can upload pics and after upload the user can also decide to delete 
the image.


Light bulb: are you using ImageIO?

There have been some well-known leaks in there over the years. It's also 
*very* easy to leak file handles if you aren't managing your resources 
appropriately.


Are you *sure* you have clean use of resources within your own code?

If you are using *any* of Java's javax.imageio code, is it possible to 
skip that and re-try your test? Can you e.g. upload a plain text file 
(or even an image) and only stream the bytes from client -> disk without 
doing anything else?



Requests:
1) POST-Request with image upload. Server saves the image in the file system 
and returns the URL.
2) GET-Request, the browser requests the URL of the uploaded picture. Server is 
sending the file via sendfile
3) POST-Request with command to delete the picture (maybe user doesn’t like the 
pic). Tomcat tries to delete the file on the server side but fails because of 
the left handle in step 2


Are you sure it's from step #2 and not step #1?


The handle stays for several minutes for sure.

It is hard to debug because when stepping through, the file-handle is gone 
after processing the request.


That seems suspicious if you are saying that Tomcat is definitely 
leaving the file handle open.



I think there are some if-statements whether the transmission is pending or 
finished.
The mentioned line in the NIOEndpoint is not reached. So the file handle must 
be left somewhere else. My first assumption was wrong.


Does the problem go away if you disable sendfile and stream the file 
directly?


-chris

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



Re: cert/key config woes

2022-06-15 Thread Christopher Schultz

Rob,

On 6/14/22 15:38, Rob Sargent wrote:

On 6/14/22 13:06, Christopher Schultz wrote:

Thanks so much for your perseverance.


No problem. Anything to avoid doing $work.


On 6/14/22 14:43, Rob Sargent wrote:

Let's get one thing working at a time. I reviewed this thread, and I 
honestly can't figure out exactly what you are trying to do. Can you 
please clarify?


1. "I want to get Tomcat working as a server with a TLS Certificate." 
This can be self-signed, or it can be signed by a real Certificate 
Authority. The process is almost the same, except you have to send 
something to the CA.


2. "I want to get Tomcat working as a server with a TLS Certificate, 
AND I want to demand that all clients connecting also present a 
client-certificate to authenticate."


Which of the above is it?

I believe I can live with #1.  I'm using a self-signed cert for sure.


Okay, that's good because it reduces the complexity of this whole 
operation by ~50%.


Because the server-side cert is self-signed, it likely means that each 
client will have to import the server-cert into the /client/ 
trust-store. Either that, of you can "ignore warnings" but IMO that's a 
significant reduction in security. We can talk about that, later.


Your server should not have to configure a trust store, full stop.

and here we can see I don't actually use truststore so that puts 
the lie to have my claim.


You might not need it. You only need a trust store if you want option 
#2 from above.



The clients get them from command line -D properties

     defvs += F"
    -Djavax.net.ssl.keyStore=/ppr/certs/sgs10.0.2.118.p12
    -Djavax.net.ssl.keyStoreType=PKCS12
    -Djavax.net.ssl.keyStorePassword=changeit"
     defvs += F" -Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
    -Djavax.net.ssl.trustStoreType=PKCS12
    -Djavax.net.ssl.trustStorePassword=changeit"

But as I said "It's working" so I'm likely to let sleeping dogs lie.


Okay, so if your clients (connecting you your Tomcat, right?) are 
using keystores, then... it sounds like you want option #2
My embedded tomcat is mainly there to mediate between db and analysis 
clients.  I just need the traffic between the two to be encrypted.


You mention 3 parties: HTTP clients, HTTP server (Tomcat), and db. Which 
links must be encrypted? (I would answer "all links should be 
encrypted", but encrypting between app <- -> db is a whole different 
process.)



Shortest route to that is all I'm after.
10.0.2.118 is the server and that's where I make my (one and only) 
self-signed cert.  That gets added to fullca.p12 (selfie + cacerts).


What is "cacerts" here? If it's self-signed, then you only need two 
things in the keystore: the key and the cert. Java's keytool will report 
this as "one entry" in the keystore with a single alias. It will say 
it's a "private key entry" and (somewhat surprisingly) give you a 
certificate for that entry if you do "keytool -list -v". I say 
"surprisingly" because private keys are NOT certificates. But keytool 
treats them as one thing because #reasons.



It all boils down to this:

1. Every pair of entities in a TLS connection are called "peers".

2. Any peer can choose to require the other one to authenticate.

3. In practice, servers *always* authenticate to the clients by 
presenting a certificate. It's up to the client to decide if the cert 
is acceptable. (This is where self-signed versus CA-signed comes into 
play. If you control the client, don't bother paying a CA a bunch of 
money for what copy/paste can solve for you.) The client maintains a 
trust store for this purpose.


The server manages this behind the scenes using a key store. A trust 
store is not required, because this part doesn't require clients to 
authenticate to servers.


(Technically, Java calls these things KeyStores no matter what. A 
"trust store" is just a KeyStore used for trust. Don't let that 
confuse you. I will always refer to a file-containing-a-key-and-cert 
as a "key store" and a 
file-containing-a-bunch-of-certificates-to-be-trusted as a "trust store.)


4. In public, clients almost never authenticate themselves. So you 
only need to deal with the "server part". If you want the server to 
authenticate the client, then you just flip everything backwards and 
layer it on top of what you already had:


  4a. Server needs a trust tore, filled with the certs from the clients
  4b. Clients each need a key store, containing the client's key+cert

That's pretty much it.



That helps a lot.  Basically I had the responsibilities reversed.  I 
have a couple of other configuration annoyances to fix and will clean 
"stores" as well.


You should only need the embedded equivalent of this:


  

  


I would recommend setting:

- honorCipherOrder="true&quo

Re: cert/key config woes

2022-06-14 Thread Christopher Schultz

Rob,

On 6/14/22 14:43, Rob Sargent wrote:
I have my environment working again but not with supplying both keystore 
and truststore to both the server and the client.  Clearly scrogged 
somewhere


Let's get one thing working at a time. I reviewed this thread, and I 
honestly can't figure out exactly what you are trying to do. Can you 
please clarify?


1. "I want to get Tomcat working as a server with a TLS Certificate." 
This can be self-signed, or it can be signed by a real Certificate 
Authority. The process is almost the same, except you have to send 
something to the CA.


2. "I want to get Tomcat working as a server with a TLS Certificate, AND 
I want to demand that all clients connecting also present a 
client-certificate to authenticate."


Which of the above is it?


My server gets the locations from a properties file and uses

         Connector connector = new Connector();
         connector.setPort(tcport);
         connector.setSecure(true);
         addBaseConnectorConfig(connector);
         connectorSetTest(connector, "SSLEnabled", "true");
         connectorSetTest(connector, "sslProtocol", "TLS");
         connectorSetTest(connector, "keyAlias",
    System.getProperty("SGSSRVR_keystoreAlias"));
         connectorSetTest(connector, "keystorePass",
    System.getProperty("SGSSRVR_keystorePwd"));
         connectorSetTest(connector, "keystoreFile",
    keyFile.getAbsolutePath());
         connectorSetTest(connector, "keystoreType",
    System.getProperty("SGSSRVR_storeType"));


What is connectorSetTest()?

and here we can see I don't actually use truststore so that puts the 
lie to have my claim.


You might not need it. You only need a trust store if you want option #2 
from above.



The clients get them from command line -D properties

         defvs += F"
    -Djavax.net.ssl.keyStore=/ppr/certs/sgs10.0.2.118.p12
    -Djavax.net.ssl.keyStoreType=PKCS12
    -Djavax.net.ssl.keyStorePassword=changeit"
         defvs += F" -Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
    -Djavax.net.ssl.trustStoreType=PKCS12
    -Djavax.net.ssl.trustStorePassword=changeit"

But as I said "It's working" so I'm likely to let sleeping dogs lie.


Okay, so if your clients (connecting you your Tomcat, right?) are using 
keystores, then... it sounds like you want option #2


It all boils down to this:

1. Every pair of entities in a TLS connection are called "peers".

2. Any peer can choose to require the other one to authenticate.

3. In practice, servers *always* authenticate to the clients by 
presenting a certificate. It's up to the client to decide if the cert is 
acceptable. (This is where self-signed versus CA-signed comes into play. 
If you control the client, don't bother paying a CA a bunch of money for 
what copy/paste can solve for you.) The client maintains a trust store 
for this purpose.


The server manages this behind the scenes using a key store. A trust 
store is not required, because this part doesn't require clients to 
authenticate to servers.


(Technically, Java calls these things KeyStores no matter what. A "trust 
store" is just a KeyStore used for trust. Don't let that confuse you. I 
will always refer to a file-containing-a-key-and-cert as a "key store" 
and a file-containing-a-bunch-of-certificates-to-be-trusted as a "trust 
store.)


4. In public, clients almost never authenticate themselves. So you only 
need to deal with the "server part". If you want the server to 
authenticate the client, then you just flip everything backwards and 
layer it on top of what you already had:


  4a. Server needs a trust tore, filled with the certs from the clients
  4b. Clients each need a key store, containing the client's key+cert

That's pretty much it.

-chris

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



Re: Filehandle left open when using sendfile

2022-06-14 Thread Christopher Schultz

Thomas,

On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,
we are using Tomcat 10.0.16 under windows.
For sending files to the browser, we are using sendfile by setting the attribute 
"org.apache.tomcat.sendfile.filename".
Streaming an image to the browser works well in this way.
But we observed that if the user tries to delete the file afterwards, there is 
still a file-handle on this file.


Which user? Some admin on the server, or the user using the browser? 
(Dumb question, I know, but tb and ff had a bug for a while where 
downloads would leave dangling file handles, disallowing deleting those 
files after they were downloaded.)



I took a look at NioEndpoint.java --> 
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/NioEndpoint.java

At line 869 there is a stream opened:
FileInputStream fis = new FileInputStream(f);

However, there is no close in this method. Maybe this might cause the open 
file-handle?


Did you read the line above that?

@SuppressWarnings("resource") // Closed when channel is closed
FileInputStream fis = new FileInputStream(f);

The channel itself is cleaned-up properly and, with it, the file handle.

https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bbaa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226

(At least, I *think* this is where the cleanup happens. I'm not very 
well-versed in the connection-handling code in Tomcat.)



We are using protocol="org.apache.coyote.http11.Http11NioProtocol".. I think 
there are different implementations for sendfile-feature.
The open file-handle can be observer via ProcessExplorer from Microsoft.


How long did you wait for the file handle to close?

Are you able to attach a debugger and see that the object hasn't been 
cleaned-up?


-chris

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



Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

2022-06-14 Thread Christopher Schultz

Pavan,

Please reply to the list and not me personally.

On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:

                acceptCount="100"  scheme="https" secure="true" 
connectionTimeout="2"

                clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
       keystoreFile="conf/certificate" keystorePass="x" 
useBodyEncodingForURI="true"

       SSLEnabled="true"/>


That all looks pretty straightforward.

When you say it's "not working", can you be more specific? Does the 
Tomcat server start? Are there any errors or warnings in the logs?


-chris

On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Pavan,

On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
 > We have replaced JDK 1.8 with JRE 1.8.0_333.
 >
 > SSL configuration was working fine with Tomcat 6.0.45 before
replacing JDK
 > with JRE.
 >
 > Now it's not working.
 >
 > In server.xml, SSL Protocol is set to "TLS".
 >
 > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
 >
 > Are there any specific protocols / versions to be used to enable
SSL ?

Please post your  configuration. Remove any secrets that may
be in there (e.g. passwords).

-chris



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



Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

2022-06-14 Thread Christopher Schultz

Pavan,

On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:

We have replaced JDK 1.8 with JRE 1.8.0_333.

SSL configuration was working fine with Tomcat 6.0.45 before replacing JDK
with JRE.

Now it's not working.

In server.xml, SSL Protocol is set to "TLS".

Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?

Are there any specific protocols / versions to be used to enable SSL ?


Please post your  configuration. Remove any secrets that may 
be in there (e.g. passwords).


-chris

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



Re: New Install - Manager/html issue

2022-06-13 Thread Christopher Schultz

Bruce,

On 6/13/22 11:29, brucetobyga...@me.com.INVALID wrote:

Tomcat is installed in opt/tomcat and the webapps directory contains
docs  examples  host-manager  manager  ROOT
I think that's CATALINA_HOME not CATALINA_BASE. IIRC, Ubuntu installs 
Tomcat into /opt/tomcat but has separate directory structure for 
CATALINA_BASE. Normally, the examples, manager, and host-manager 
applications wouldn't be enabled by default.


Have a look at the Ubuntu package documentation for how to enable those 
applications -- and only enable the ones you actually need.


-chris


-Original Message-
From: Mark Thomas 
Sent: 13 June 2022 16:23
To: users@tomcat.apache.org
Subject: Re: New Install - Manager/html issue

On 13/06/2022 14:17, brucetobyga...@me.com.INVALID wrote:

I have just installed Apache Tomcat 10.0.22 on Ubuntu 22.04.  However,
when I click on the Manager link I get a 404 /manager/html is not
available and the description is "The origin server did not find a
current representation for the target resource or is not willing to disclose that 
one exists"

Any idea how I can resolve the issue?


How did you install Tomcat?

What is the contents of the $CATALINA_BASE/webapps directory?

Mark

-
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



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



[ANN] Apache Tomcat 8.5.81 available

2022-06-12 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.81.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.81 is a bugfix and feature release. The notable
changes compared to 8.5.79 include:

- Ensure that changes made to a request by the RemoteIPValve persist
  after the request is put into asynchronous mode.

- Correct a regression in the support added for encrypted PKCS#1
  formatted private keys in the previous release that broke support
  for unencrypted PKCS#1 formatted private keys.

- Increase the default buffer size for cluster messages from 43800
  to 65536 bytes. This is expected to improve performance for large
  messages when running on Linux based systems.

- When using TLS with non-blocking writes and the NIO connector,
  ensure that flushing the buffers attempts to empty all of the
  output buffers.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Re: LDAPS Configuration with Tomcat

2022-06-07 Thread Christopher Schultz

Rakesh,

On 6/6/22 09:54, rakesh meka wrote:

Currently we are using an internal application which is deployed on windows
server. And we use http which means we didn't configure SSL or TLS setup
with application. The current application is using LDAP for user
authentication which checks with active directory for verification .

Can any one let me know how we can configure LDAPS now ?

Should we need to configure the application with https before we enable
LDAPS ?


It doesn't matter in which order you do these.

But if you need users to authenticate with your application, then 
encrypting that communication channel should be a top priority. 
Otherwise, anyone nearby on your network can read everyone's 
credentials, regardless of whether you are using LDAP or LDAPS. Or any 
other kind of credential-checking system.



I tried changing the port to 636 but not successful. So need help if we can
directly generate the certificate and place in somewhere in Tomcat
directory ?


You need to use an ldaps:// URL, not just change the port number.

-chris

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



Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL]

2022-06-02 Thread Christopher Schultz

On 6/2/22 14:38, Beard, Shawn wrote:
> I've never done this. But I think it would go something like this:
> To make tomcat take advantages of Client Authentication, require three
> certificates. i.e A Server Certificate for Tomcat, Client Certificate
> for the browser/Apache and Certificate of the CA which will sign both
> the above mentioned certificates.

Stop. John: if you aren't using client TLS certs with your end-users, 
then this is a rathole you don't want to go down.


If you *do* need to use client-TLS-auth, then this is correct.

-chris

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



Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL

2022-06-02 Thread Christopher Schultz

Jon,

On 6/2/22 14:20, jonmcalexan...@wellsfargo.com.INVALID wrote:

I'm trying to figure out if there is a way to use certificates
between Tomcat and Apache for mutual authentication of the mod-proxy
connection to Tomcat. This would be similar as to how you can setup
the WebSphere plugin to communicate with WebSphere over a mutually
secured connection. Is this possible with Apache HTTPD and Tomcat
over mod-proxy?

Definitely.

What do you have working so far? Just httpd mod_proxy -> Tomcat where 
you only authenticate the Tomcat server --  and you now want to have 
Tomcat authenticate the client as well?


I just want to know where to pick-up in your process.

-chris

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



Re: cert/key config woes

2022-06-02 Thread Christopher Schultz

Rob,

On 6/2/22 14:19, Rob Sargent wrote:

    Caused by: java.lang.IllegalArgumentException: Alias name [sgsAgent]
    does not identify a key entry
         at

> [...]


but I believe the alias is in place, both places

    ## check, different files
    [ec2-user@ip-10-0-2-118 certs]ls -l fullca.p12 sgstrust.p12
    -rw-rw-r-- 1 ec2-user ec2-user 281500 Jun  2 17:12 fullca.p12
    -rw-rw-r-- 1 ec2-user ec2-user   2726 Jun  2 17:13 sgstrust.p12

    ## checks for alias
    [ec2-user@ip-10-0-2-118 certs]$ keytool -storetype pkcs12 -list
    -keystore sgstrust.p12 -alias sgsAgent -storepass changeit
    sgsAgent, Jun 2, 2022, PrivateKeyEntry,
    Certificate fingerprint (SHA-256):

65:F1:9C:07:37:C4:13:A8:82:D5:09:E7:51:F9:C0:E2:94:E4:41:64:F1:41:86:E6:60:5F:50:87:A8:13:74:17 



    [ec2-user@ip-10-0-2-118 certs]$ keytool -storetype pkcs12 -list
    -keystore fullca.p12 -alias sgsAgent -storepass changeit
    sgsAgent, Jun 2, 2022, trustedCertEntry,
    Certificate fingerprint (SHA-256):

65:F1:9C:07:37:C4:13:A8:82:D5:09:E7:51:F9:C0:E2:94:E4:41:64:F1:41:86:E6:60:5F:50:87:A8:13:74:17 


What does your  configuration look like (specifically, what 
keystore is it pointing to)? Remember that  ccan specify both 
keystore (for identifying itself) and truststore (for identifying 
clients, which you don't need AIUI).



To your latest


    I add my cert to truststore.


    Which one? Are you using client certs for mutual-TLS or just
    plain-old "I only need to trust the server" checking?

I add sgstrust to fullca.  I think the latter mode is fine


    If it's vanilla, then you need:

    1. Key + cert in the key store used by the Tomcat 
    2. cert in the trust store used by the client (optional if it's
    signed by a trusted CA)

    Remember if your key store from #1 has more than one cert+key in it,
    Tomcat will choose the first one (which is basically a crap-shoot,
    given the API) unless you specify the alias of the one to use. I
    think it's best to have only a single key+cert in each keystore
    (unless it's multiple flavors of the same thing, like RSA and ECDSA
    for the same server). That way you don't get confused by "too much
    stuff".

I'm starting both the server and the client with both key and trust. 
Does that bite?


I would avoid giving access to the key to anything that doesn't 
absolutely need it. Usually, only the server needs access to the key.


-chris

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



Re: cert/key config woes

2022-06-02 Thread Christopher Schultz

Rob,

On 6/2/22 13:43, Rob Sargent wrote:



I had this overall configuration working until I 'terminated' the AWS 
server instance and am trying to rebuild.


Could a lack of network connectivity between client and server 
present this same symptom?


Hmm. Your SAN looks okay to me. Are you 100% sure you have that 
certificate configured in Tomcat? ARe you using some other component 
in front of Tomcat? You should be able to connect using:


$ openssl s_client -showcerts -connect 10.0.2.118:443

This will dump the certificate actually presented by the server. You 
can copy/paste that into:


$ openssl x509 -text

and get the details to make sure the SAN appears there.

-chris

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

Thanks Chris, given your vote of confidence I realized I had not updated 
the keystore file with my recently regenerated cert.
Also forgot to mention this is tomcat 9.0.63 embedded in my app, running 
java17 (correto) at AWS


But I think I'm going backwards.

my actual java command is pretty much this:

    java  -Djavax.net.ssl.keyStore=/ppr/certs/sgstrust.p12
    -Djavax.net.ssl.keyStoreType=PKCS12 -Djavax.net.ssl.keyStorePassword=p1
    -Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
    -Djavax.net.ssl.trustStoreType=PKCS12
    -Djavax.net.ssl.trustStorePassword=p2
    --oper=1 --seg=id --json-dir=/ppr/report --acc=10.0.2.118:15002
    --dbn={dbn} --eff={dbu} -env=AWS


Does that launch your Tomcat JVM or your client? (Or both?)


I add my cert to truststore.


Which one? Are you using client certs for mutual-TLS or just plain-old 
"I only need to trust the server" checking?


If it's vanilla, then you need:

1. Key + cert in the key store used by the Tomcat 
2. cert in the trust store used by the client (optional if it's signed 
by a trusted CA)


Remember if your key store from #1 has more than one cert+key in it, 
Tomcat will choose the first one (which is basically a crap-shoot, given 
the API) unless you specify the alias of the one to use. I think it's 
best to have only a single key+cert in each keystore (unless it's 
multiple flavors of the same thing, like RSA and ECDSA for the same 
server). That way you don't get confused by "too much stuff".


 Do I need both trust and key stores on the 
commandline.  sgstrust.p12 is made by converting x509 key/cert. 
fullca.p12 has the worlds CA certs plus mine.

But now I'm hitting

    java.net.ConnectException


Probably not running?

-chris

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



Re: cert/key config woes

2022-06-02 Thread Christopher Schultz

Rob,

On 6/2/22 01:13, Rob Sargent wrote:

This part always confuses me

I supply the trust and key store files on the command line and I see the 
SAN for the tomcat server IP (in ObjectId #3). I try to connect to 
tomcat by host-IP and port.  Here's the text of the keystore sent in.


    Keystore type: PKCS12
    Keystore provider: SUN

    Your keystore contains 1 entry

    Alias name: sgsagent
    Creation date: Jun 2, 2022
    Entry type: trustedCertEntry

    Owner: EMAILADDRESS=rob.sarg...@utah.edu,
    CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
    Utah, L=Salt Lake City, ST=UT, C=US
    Issuer: EMAILADDRESS=rob.sarg...@utah.edu,
    CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
    Utah, L=Salt Lake City, ST=UT, C=US
    Serial number: 2f543ea5b1ce847034a34dfb4d26ecbdac1959d5
    Valid from: Thu Jun 02 03:12:01 UTC 2022 until: Sat Jul 02 03:12:01
    UTC 2022
    Certificate fingerprints:
      SHA1:
    61:92:93:E7:A1:05:85:ED:66:6F:BC:6C:76:7E:CA:E8:7F:A7:0D:93
      SHA256:

23:85:E4:85:08:93:B1:4C:D7:40:47:E7:EF:3F:8F:5F:FC:FA:CA:57:0F:B1:4C:A8:3F:25:AE:D7:98:0C:4B:28 


    Signature algorithm name: SHA256withRSA
    Subject Public Key Algorithm: 2048-bit RSA key
    Version: 3

    Extensions:

    #1: ObjectId: 2.5.29.35 Criticality=false
    AuthorityKeyIdentifier [
    KeyIdentifier [
    : F4 FC 13 D9 FC 1C C1 A0   DB 0A 81 28 C0 EF DC FF 
...(

    0010: 28 64 81 BE    (d..
    ]
    ]

    #2: ObjectId: 2.5.29.19 Criticality=false
    BasicConstraints:[
       CA:true
       PathLen: no limit
    ]

    #3: ObjectId: 2.5.29.17 Criticality=false
    SubjectAlternativeName [
       IPAddress: 10.0.2.118
    ]

    #4: ObjectId: 2.5.29.14 Criticality=false
    SubjectKeyIdentifier [
    KeyIdentifier [
    : F4 FC 13 D9 FC 1C C1 A0   DB 0A 81 28 C0 EF DC FF 
...(

    0010: 28 64 81 BE    (d..
    ]
    ]

but I get

    javax.net.ssl.SSLHandshakeException: No subject alternative names
    matching IP address 10.0.2.118 found
         at

java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:578) 


         at

java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123) 


         at
    edu.utah.camplab.sgs.AbstractSGSRun.canConnect(AbstractSGSRun.java:386)
         at
    edu.utah.camplab.sgs.AbstractSGSRun.init(AbstractSGSRun.java:296)
         at

edu.utah.camplab.sgs.AbstractSGSOptions.init(AbstractSGSOptions.java:37)

         at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:76)
         at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:85)
         at edu.utah.camplab.app.SGSPValue.(SGSPValue.java:68)
         at edu.utah.camplab.app.SGSPValue.main(SGSPValue.java:27)
    Caused by: javax.net.ssl.SSLHandshakeException: No subject
    alternative names matching IP address 10.0.2.118 found
    Then comes my summary log:
    03:52:04.752 [main] ERROR edu.utah.camplab.sgs.AbstractSGSRun -
    cannot get to saver, trying 10.0.2.118:15002
    Could not establish connection to 10.0.2.118:15002
    from
         if (! canConnect() ) {
       logger.error("cannot get to saver, trying {}:{}",
    getAccumulationHost(), getAccumulationPort());
       throw new RuntimeException(String.format("Could not establish
    connection to %s:%d", getAccumulationHost(), getAccumulationPort()));
         }

       protected boolean canConnect() {
         boolean retval = false;
         String weburl = String.format("https://%s:%d;,
    getAccumulationHost(), getAccumulationPort());

         try {
       HttpRequest request = HttpRequest.newBuilder()
         .header("dbrole", getProjectName())
         .header("dbname", getDbName())
         .header("dbhost", System.getProperty("SGSSRVR_databaseHost",
    "localhost"))
         .uri(URI.create(weburl+"/sgs/webmonitor"))
         .build();
       HttpResponse response = getHttpClient().send(request,
    HttpResponse.BodyHandlers.ofString());
       retval = response.statusCode() == 200;
         }
         catch (IOException  | InterruptedException ie) {
       retval = false;
       ie.printStackTrace();
         }
         return retval;
       }


I had this overall configuration working until I 'terminated' the AWS 
server instance and am trying to rebuild.


Could a lack of network connectivity between client and server present 
this same symptom?


Hmm. Your SAN looks okay to me. Are you 100% sure you have that 
certificate configured in Tomcat? ARe you using some other component in 
front of Tomcat? You should be able to connect using:


$ openssl s_client -showcerts -connect 10.0.2.118:443

This will dump the certificate actually presented by the server. You can 
copy/paste that into:


$ openssl x509 -text

and get the details to make sure the 

Re: FIPS Mode is not getting enabled in Tomcat9 using Openssl 3.0.2 post successful FIPS module installation in windows

2022-06-01 Thread Christopher Schultz

Mark,

On 6/1/22 09:49, Mark Thomas wrote:

On 20/05/2022 12:43, Mark Thomas wrote:



Tomcat Native has not been updated for OpenSSL 3.0.x and FIPS. Code 
changes in Tomcat Native are going to be required to get this to work.


After doing some work on this I have an update.

First of all, OpenSSL 3 has not yet obtained FIPS certification. You can 
use the FIPS provider but it is not (yet) certified.


To use the OpenSSL 3 FIPS provider with Tomcat you need to do all of the 
following:

- build Tomcat Native 1.2.x with OpenSSL 3.x
- configure OpenSSL to use the FIPS provider by default
   https://www.openssl.org/docs/man3.0/man7/fips_module.html


If this is anything like OpenSSL 1.x, you will need to build OpenSSL 
with FIPS enabled to begin with. It's not just a runtime setting. (I 
don't claim to understand the fine details of FIPS, but IMHO it should 
have been possible for OpenSSL to be built in a standard way with FIPS 
operational mode being simply a runtime decision, but that isn't how 
OpenSSL did things... at least not originally.)



- DO NOT configure the APRLifecycleListener to use FIPS


Oh, that's interesting :)

Is that because the provider itself is FIPS and therefore there's no 
reason to have an API to specifically-enable it? Is it possible to 
confirm from client code e.g. libtcnative that the module is indeed in 
FIPS mode?


Although you won't see any confirmation in the logs, Tomcat Native will 
be using the OpenSSL FIPS provider.


Updates are in progress so that:
- Tomcat will log a message on start when FIPS is the default provider
- setting the FIPSMode options when using OpenSSL 3 won't break things

The above will require Tomcat Native 1.2.34 onwards.


I think we might want to make a note of all this in the documentation 
for the APR lifecycle listener, including all the version information 
you have above.


-chris

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



Re: Apache Tomcat EncryptInterceptor DoS CVE-2022-29885 vulnerability question

2022-05-31 Thread Christopher Schultz

Jacob,

On 5/31/22 11:17, DeHaven, Jacob wrote:

In regards, to the Low: Apache Tomcat EncryptInterceptor DoS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29885 which is
fixed in Apache Tomcat 9.0.63, it is being reporting as a Low
vulnerability on the Apache Tomcat website but others (NIST, Tenable)
are reporting this vulnerability as High as seen below. Could someone
please elaborate on this and which one is correct? >

> NIST:
> https://nvd.nist.gov/vuln/detail/CVE-2022-29885
> Base Score: 7.5 HIGH
>
> Tenable:
> https://www.tenable.com/cve/CVE-2022-29885
> Severity: HIGH

(For completeness)
Tomcat:
https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.63
Severity: LOW

The severity of any vulnerability is a matter of subjective opinion.

Speaking for myself (a member of the Apache Tomcat Security Team, but 
not making any official statement, here), any vulnerability always must 
be considered under the following criteria:


1. Complexity (aka ease-of-attack)
2. Probability (aka likelihood of attack)
3. Impact (aka the Bad Stuff[1])

For my part, I would rate CVE-2022-29885 the following way:

1. Complexity: LOW (meaning HIGH severity)

This is an easy attack to perform if you know what you are doing.

2. Probability: LOW (meaning LOW severity)

This is a difficult attack to perform, because it requires that the 
target first be running Tomcat as a cluster (which is somewhat rare in 
and of itself), and the attacker must be able to access the target's 
network being used for that clustering. Those two prerequisites alone 
might reduce the overall severity for me to "very low".


3. Impact: MEDIUM (meaning MEDIUM severity)

This is a DOS and thus a breach of availability, not a breach of 
security or privacy.


Again, speaking for myself, I would rate this LOW due mostly to the low 
Probability rating of this vulnerability.


It's worth pointing out a few more things IMO:

1. While this is being reported as a vulnerability in the 
EncryptIntercepter, it's actually a vulnerability in the Tomcat 
clustering itself which the EncryptInterceptor fails to mitigate while 
implying that it does. (The original claim was that the 
EncryptInterceptor allowed Tomcat to be clustered over an untrusted 
network. While this is true, it only provides integrity and privacy 
guarantees while not providing protection against DOS.)


2. The "fix" was to /adjust the documentation/ to make it clear that the 
EncryptInterceptor isn't sufficient protection to run Tomcat's 
clustering over a truly untrusted network. So upgrading to the "fixed" 
version provides exactly no "protection" whatsoever from the possible 
DOS mentioned in CVE-2022-29885.


3. Any software which uses version numbers to report vulnerabilities 
instead executing actual testing for those vulnerabilities is 
necessarily going to report a lot of false positives. For example, if 
you aren't using Tomcat's clustering, then you were never in any danger 
of being susceptible to CVE-2022-29885. Likewise, if you are using 
Tomcat clustering but you are using a secured network, then you are also 
not susceptible to CVE-2022-29885.


4. It's always a good idea to be running the latest version of the 
software you rely on to meet your requirements. Unless there is a 
significant reason to stay on your older 9.0.58 version, upgrading to 
9.0.63 is just a good idea in general.


5. As you are under the umbrella of US-DHS, you must meet whatever 
expectations and requirements DHS, CISA, and any other government 
agencies which affect your security policies. I haven't met an agency 
yet that doesn't understand that vulnerabilities can be mitigated 
without upgrading to a "fixed" version: you should be able to explain 
that you don't use the vulnerable component (if it's true, of course), 
an attacker can't force the sudden use of the component (not without 
having compromised your environment already, in which case 
CVE-2022-29885 is the least of your worries), and therefore your 
"vulnerable" version is in fact /not/ vulnerable.


Hope that helps,
-chris

[1] https://en.wikipedia.org/wiki/Munchkin_(card_game)#Gameplay

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



Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

2022-05-28 Thread Christopher Schultz

Ralph,

On 5/27/22 18:31, Ralph Atallah wrote:

I suspect that if we were to take the time to set up a proxy,
according to RFC7230, we would be able to get the absolute-form to
reach the Tomcat code and in that case, based on reading the
AbostractHttp11Processor class, I suspect the allowHostHeaderMismatch
will kick in and will behave correctly.  So I doubt that there is a
bug to report at this stage, at least not from my observation.

Thanks for the confirmation.


However, I wonder what all of this means.  Could it be that the Host
header injection or Host header attack issue can only occur when
absolute-form is used, i.e. mostly when proxies are set up?  Both you
and Mark stated that with origin-form there is nothing to compare the
Host header to, which makes sense.  Any thoughts on this assessment?


Well, if the client doesn't send a fully-qualified URL in the request 
line, then there is nothing to compare the Host header to.


I wonder what you think the "Host header attack" is, and how 
cross-checking against the URL would help.


Let's say the request looks like this:

GET http://example.com/some-resource
Host: attacker.com

Okay, this looks fishy and you can protect against it by rejecting the 
request. This is what Tomcat already does.


But how about this one?

GET http://attacker.com/some-resource
Host: attacker.com

What do you want to do, there? The request came to you, but it looks 
like it should have gone to attacker.com. If you want to reject it, you 
have to take other measures (which is what Mark was trying to explain in 
his responses).


No legitimate client is going to send you garbage, so you don't have to 
worry about e.g. Google Chrome sending you a bad request.


Anyone trying to attack you isn't going to provide convenient 
cross-checking information (e.g. host-in-request and 
host-in-Host-header) for you.


And finally, if you aren't validating the Host against a list of 
pre-defined allowed-hosts, then what's the point of even worrying about 
cross-checking?


If you aren't setting-up an allow-list, then how can you prevent 
requests like this from being processed (perhaps badly) by your application:


GET /some-resource
Host: attacker.com

?

I see under separate cover you have shown how you were able to use 
Tomcat's existing virtual-hosting configuration to explicitly allow only 
certain hosts. That seems like the best way for you to avoid mischief.


The primary attack vector I can see here is an intentionally malicious 
reverse proxy which is accepting requests at attacker.com and proxying 
them to YOUR service in order to trick users into sending information to 
them instead of you. If they can do that, they are already mounting a 
MitM against you and no amount of checking host headers is going to 
solve that problem.


-chris


-Original Message-----
From: Christopher Schultz 
Sent: Friday, May 27, 2022 4:26 PM
To: users@tomcat.apache.org
Subject: Re: allowHostHeaderMismatch option only works if the Host Header has 
an http or https prefix

WARNING: This email originated from outside of CallMiner. Do not click any links or 
open any attachments unless you recognize the sender and know that the content is 
safe. Please report suspicious emails to: reportsuspiciousema...@callminer.com 
<mailto:reportsuspiciousema...@callminer.com>

Mark,

On 5/27/22 3:13 AM, Mark Thomas wrote:

On 27/05/2022 02:00, Ralph Atallah wrote:

Hi Mark,

Thanks again for the prompt response.

You wrote below:  "If the original request only has a Host header,
then allowHostHeaderMismatch="false" isn't going to do anything
because there is no mismatch.".  I am not clear on what this means.
What should the match be between?  I thought the comparison for the
match was between the URL's hostname, i.e. "example.com" in the
http://example.com/myapp URL, and the Host header value which is
"attacker.com".  If that understanding is incorrect, please point me
in the right direction of what it should be.


The check is that the host in the request URI (if present) is
consistent with the Host header. Nothing more, nothing less.

HTTP requests may or may not include the host in the request URI.

The host named in the the headers of an HTTP request is completely
independent of the host name used to establish the connection to the
web server.


The AbstractHttp11Processor class does not get to the
allowHostHeaderMismatch detection code because the uriBC (URI
ByteChunk) that it reads is expecting an absolute URL
(http://example.com/myapp), but instead, it is getting a relative one
/myapp.  The reason I say the code expects an absolute URL is because
it checks for and "http" string at the beginning.  This makes me
wonder whether there is a setting that controls that URI format,
absolute or relative.


Your understanding of the HTTP protocol is flawed. You may wish to
read RFC 7230. Specifically:

https://datatracker.ietf.org/doc/html/rfc72

Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

2022-05-27 Thread Christopher Schultz

Mark,

On 5/27/22 3:13 AM, Mark Thomas wrote:

On 27/05/2022 02:00, Ralph Atallah wrote:

Hi Mark,

Thanks again for the prompt response.

You wrote below:  "If the original request only has a Host header, 
then allowHostHeaderMismatch="false" isn't going to do anything 
because there is no mismatch.".  I am not clear on what this means.  
What should the match be between?  I thought the comparison for the 
match was between the URL's hostname, i.e. "example.com" in the 
http://example.com/myapp URL, and the Host header value which is 
"attacker.com".  If that understanding is incorrect, please point me 
in the right direction of what it should be.


The check is that the host in the request URI (if present) is consistent 
with the Host header. Nothing more, nothing less.


HTTP requests may or may not include the host in the request URI.

The host named in the the headers of an HTTP request is completely 
independent of the host name used to establish the connection to the web 
server.


The AbstractHttp11Processor class does not get to the 
allowHostHeaderMismatch detection code because the uriBC (URI 
ByteChunk) that it reads is expecting an absolute URL 
(http://example.com/myapp), but instead, it is getting a relative one 
/myapp.  The reason I say the code expects an absolute URL is because 
it checks for and "http" string at the beginning.  This makes me 
wonder whether there is a setting that controls that URI format, 
absolute or relative.


Your understanding of the HTTP protocol is flawed. You may wish to read 
RFC 7230. Specifically:


https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.1
and
https://datatracker.ietf.org/doc/html/rfc7230#section-5.3

Requests with the URI in origin-form do not include a host in the URI.

The purpose of allowHostHeaderMismatch is to ensure that when the 
request URI is in absolute-form that the request URI is consistent with 
the Host header.


Regarding the addition of a filter that you propose, we have an 
existing one in our application, but by the time it is reached, the 
URL that we see is already http://attacker.com/myapp, i.e. already 
"redirected".


There has been no redirect. The URI reported is a combination of the 
Host header and request URI received.


 Technically we could check there against a whitelist, but this would 
make the solution less out-of-the box, and more needy of user 
configuration in our app.  We prefer an out-of-the-box secure solution.


Any thoughts on the above?


What you want isn't possible.


Actually, I think what Ralph is requesting is exactly what Tomcat is 
providing in the form of allowHostHeaderMismatch (when set to false).


The only problem is that Ralph is saying it's not working because the 
URI in the request doesn't contain a hostname *at all* (because it's 
optional). So there is nothing to check. Browsers don't bother to send 
the optional protocol/hostname/port/etc and instead send the relative 
URI -- relative to the Host header (no coincidentally).


If you (Ralph) can reproduce this with wc or telnet where you can force 
the URI to be absolute *and* provide a conflicting Host header, then I 
think you have grounds for a bug report.



If you want requests to be rejected unless the Host header is on a
user defined allow list (presumably the set of DNS names defined for
the host), then you are going to have to provide a means for the user
to provide that configuration.


I don't think it being requested, here. It may be an aim of their 
application to do such things, but that wasn't a part of the initial 
request ("prevent host header injection" -- which is very strangely worded).


-chris

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



Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz

Rainer,

On 5/26/22 17:25, Rainer Jung wrote:

Hi Chris,

Am 26.05.2022 um 21:49 schrieb Christopher Schultz:

On 5/16/22 13:48, Christopher Schultz wrote:


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. 
The function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


It looks like I needed a few more things in order to get this to work:

   {
 char *timestamp = malloc(32);
 apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
 apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
 apr_time_exp_gmt(timerec, ap->r->request_time);
 apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
 /* emit a detailed log message */
 jk_log(l, JK_LOG_INFO,
    "(%s) Request to (%s %s) started at %s",
    ae->worker->name, r->method, r->req_uri, timestamp);
 free(timerec);
 free(timestamp);
   }

The compiler wouldn't let me use an automatically-allocated char[32] 
so I had to malloc it. I also had to convert from long to 
apr_time_exp_t which required another structure/malloc as well.


Finally, I had to cast the r->ws_private to apache_private_data_t* 
which required me to copy/paste the definition of 
apache_private_data_t from mod_jk.h into jk_ajp_common.c -- just as a 
test for now.


Obviously, this works only for Apache httpd.

I have it running on one of my web servers for now -- hoping to catch 
an error and see this additional logging to see if it's helpful to me. 
(LOL just segfaulted; time to go back and look.)


What would be the best way to get the "start time" of the request in a 
platform-independent way? Maybe just expand the jk_ws_service 
structure to include it?


Apart from the info chuck send via PM, I think it would be better to try 
to add a unique request ID as a correlation ID. Apache can already 
generate them using mod_unique_id and you can add them there to the 
access log.


Would you prefer to use mod_unique_id + unique-id-logging in mod_jk over 
just adding more request-level information to the mod_jk.log? I'm kind 
of okay either way, but for my current purposes it seems more convenient 
to have all relevant information in a single place (the mod_jk.log file).



Now how could we make that ID accessible from mod_jk?

We could either add it as a new item to jk_ws_service and I think it 
would be a good fit. Any server not yet providing it, eg. if we find no 
way adding it in IIS, would have a null value there (or some constant we 
init it to). We are free to add things, because we do not really provide 
a public API used elsewhere which we need to keep stable.


When we do logging in mod_jk, we use jk_log(jk_logger_t *l, ...) where 
the remaining arguments are just standard log arguments. We could add a 
new jk_request_log(jk_logger_t *l, jk_ws_service_t *s, ...) and that 
function retrieves the request ID from s and adds it to the log line.


It seems, typically where we want to log something that would benefit 
from a request ID, we have the jk_ws_service_t at hand, so could add it 
to the log call.


WDYT?


I'm okay adding either or both of these "features" to the JK portion of 
the code. If we are considering "enhancing" this kind of logging in the 
JK portion, I would recommend that we add request_start_time to the 
jk_ws_service; I don't see a good way to determine the nature of the 
host web server from within the JK code and it's better-done from the 
outside-in rather than the inside-out.


Unrelated: I believe the segfaults I'm seeing have to do with me simply 
updating the .so file on the disk before restarting the httpd process. 
As soon as I copy the .so file over the existing module binary, I start 
getting a string of segfaults in the log file. When I don't try to 
"hot-update" the module binary, I don't see any of that happening. (I 
also don't see any possible segfaults in my code at this point, either.) 
I have httpd set up to dump cores but I think my file permissions are 
wrong so I'm not actually getting anything in there (yet).


-chris

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



Re: Upgrade tomcat 7 to 10.

2022-05-26 Thread Christopher Schultz

Rodrigo,

On 5/26/22 17:16, Rodrigo Cunha wrote:

i need upgrade my tomcat server from 7 to 10. I don't saw in internet
nothing about that. Commonly i upgraded in steps, 7 to 8, 8 to 9 and 9 to
10.
Are there a problem upgrade from 7 to 10?


I suspect you should be able to upgrade your Tomcat from 7 to 10 in one 
shot, but you might want to go from 7->9 and wait a little on 10.


Why?

Tomcat 10 is significantly different because it implements a new version 
of the servlet and related specifications, including switching package 
names, etc. There *is* an automated conversion tool that can be used at 
deployment-time to convert your pre-Jakarta-EE application to a 
Jakarta-EE application, but you might not want to trust it immediately 
in production without a whole lot of testing. So I recommend Tomcat 9 at 
first.


YMMV

Something that is critically important is that, when upgrading, you 
don't even try to re-use the existing server.xml file you have for your 
Tomcat 7 installation. Instead, look at the differences between your 
current server.xml file and an unmodified one from the original 
distribution of Tomcat 7, and make some notes. Then, make similar 
changes to the original server.xml file from the new Tomcat.


-chris

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



Re: Sv: Unexpected messages in commons-daemon.log

2022-05-26 Thread Christopher Schultz

Pontus,

On 5/25/22 03:53, Pontus Ågren wrote:

There is monitoring of the service so that seems to be the cause. I
agree that logging it at TRACE level is a better idea. On INFO level
it just adds noice.
You might be "over monitoring" if you are seeing pairs of messages at 
once... except for every 5 minutes (which seems odd).


Are you maybe checking this service twice a minute instead of once per 
minute as (probably) expected?


-chris

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



Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz

Rainer,

On 5/26/22 16:46, Rainer Jung wrote:

Hi Chris,

Am 16.05.2022 um 19:48 schrieb Christopher Schultz:

I've been looking into this a little more in my production environment.

These errors are not super common, but there seems to be a steady 
trickle of errors from my two services that have human users. I see 0 
errors for my API-based services, which makes me think that I don't 
have any performance issues... I probably have human users 
disappearing for random reasons.


Could be unstable (mobile) client connections. Or people already 
clicking on the next frontend action before they received the complete 
response. But that is speculating. So it is right, you try to identify 
some individual reasons to understand more.



The errors in mod_jk.log look like this:

[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] 
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to 
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] 
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to 
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1595): service failed, worker myworker is in 
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1614): unrecoverable error 200, request 
failed. Client failed in the middle of request, we can't recover to 
another instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker


(Note that the last message "Aborting connection for worker=myworker" 
may have a bug; my actual worker name has a name containing a hyphen 
(-) and only the text before the hyphen is being emitted in that error 
message.)


Strange, never observed that, but maybe never used a hyphen. Docs say, 
hypens are allowed. Would be interesting to do a server startup with 
trace-Logging and see where things corresponding to the name start to go 
wrong. But of course not related to sporadic client failures.


Right. I may investigate that separately, as I have a setup already with 
everything in place.


Anyway, when researching these errors, it would be helpful to me to 
know which requests are failing. By looking at the access_log, I only 
see a single request logged for 04:19:15 on that server so it's 
probably the right one, but httpd says that the response code is 302 
instead of e.g. 50x for an error.


What I typically do:

- log "%P:%{tid}P" in your Apache httpd custom LogFormat used for the 
access log.


- make sure, I log in in the Apache httpd access log the request 
timestamp including milli or microseconds (not default but 
configurable). Can be done by using the %{format}t syntax in the 
LogFormat and adding "usec_frac" to the format.


- adding %D to the access log format (duration in microseconds)

- remember that Apache logs start of request as default time stamp, but 
mod_jk logs at the moment of error, so later than start of request.


Finding the right access log line for a mod_jk error log line now means:

- filter the access log according to the PID:TID logged in the mod_jk 
error log. In your case 5859:139625025315392. We know, that the requests 
handled by one thread in one process are run strictly sequentially.


- look for the last request in this filtered list, that by access log 
line timestamp started before (or unlikely exactly at) the point in time 
given by the mod_jk access log. If you find one exactly add, it might be 
also the one directly before.


- look at the request durations of these one or two requests to double 
check, whether the times fit.


If you can spare the additional log line bytes, you can additionally log 
the end of request timestamp in the apache access log (prefix "format" 
by "begin:").


Especially by adding this "enhanced logging", it was very easy to find 
the failing requests.


Fortunately for me, the JK log is "now" and the request_time is the 
start-of-request, so I can see the delay between the two. In the cases 
I've seen since I started watching the log, it's typically a very short 
tie like 1-2 sec which shouldn't be something a user gets tired waiting for.


I was more worried like "mod_jk waited 35 seconds for a response from 
upstream and the user went away" and that's not the case.


So I'm happy to find that the reason for these errors is pathological 
user behavior and not some performance problem on my end.


Thanks,
-chris

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



Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz

All,

On 5/26/22 15:49, Christopher Schultz wrote:

Rainer,

On 5/16/22 13:48, Christopher Schultz wrote:

Rainer,

I've been looking into this a little more in my production environment.

These errors are not super common, but there seems to be a steady 
trickle of errors from my two services that have human users. I see 0 
errors for my API-based services, which makes me think that I don't 
have any performance issues... I probably have human users 
disappearing for random reasons.


The errors in mod_jk.log look like this:

[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] 
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to 
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] 
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to 
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1595): service failed, worker myworker is in 
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1614): unrecoverable error 200, request 
failed. Client failed in the middle of request, we can't recover to 
another instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker


(Note that the last message "Aborting connection for worker=myworker" 
may have a bug; my actual worker name has a name containing a hyphen 
(-) and only the text before the hyphen is being emitted in that error 
message.)


Anyway, when researching these errors, it would be helpful to me to 
know which requests are failing. By looking at the access_log, I only 
see a single request logged for 04:19:15 on that server so it's 
probably the right one, but httpd says that the response code is 302 
instead of e.g. 50x for an error.


When we log these kinds of errors, it would be great to know a few 
things IMO:


1. What was the URL of the request
2. How long did the client wait for the response before we found we 
couldn't write to the stream (or, conversely, the start-timestamp of 
the request as well as the timestamp of the error, which I think is 
already in the log itself)


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. 
The function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


It looks like I needed a few more things in order to get this to work:

   {
     char *timestamp = malloc(32);
     apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
     apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
     apr_time_exp_gmt(timerec, ap->r->request_time);
     apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
     /* emit a detailed log message */
     jk_log(l, JK_LOG_INFO,
    "(%s) Request to (%s %s) started at %s",
    ae->worker->name, r->method, r->req_uri, timestamp);
     free(timerec);
     free(timestamp);
   }

The compiler wouldn't let me use an automatically-allocated char[32] so 
I had to malloc it. I also had to convert from long to apr_time_exp_t 
which required another structure/malloc as well.


Finally, I had to cast the r->ws_private to apache_private_data_t* which 
required me to copy/paste the definition of apache_private_data_t from 
mod_jk.h into jk_ajp_common.c -- just as a test for now.


Obviously, this works only for Apache httpd.

I have it running on one of my web servers for now -- hoping to catch an 
error and see this additional logging to see if it's helpful to me. (LOL 
just segfaulted; time to go back and look.)


What would be the best way to get the "start time" of the request in a 
platform-independent way? Maybe just expand the jk_ws_service structure 
to include it?


Here is my latest code which hasn't segfaulted in a while:

{
  /* emit a detailed log message */
  char timestamp[32]; // For formatted timestamp string
  apr_time_exp_t timerec; // Required for apr_strftime
  apr_size_t retsize; // Required for apr_strftime
  apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;

  apr_time_exp_gmt(, ap->r->request_time); // Convert 
request_time to apr_time_exp_t
  apr_strftime(timestamp, , 32, "%Y-%m-%d %H:%

Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz

Rainer,

On 5/16/22 13:48, Christopher Schultz wrote:

Rainer,

I've been looking into this a little more in my production environment.

These errors are not super common, but there seems to be a steady 
trickle of errors from my two services that have human users. I see 0 
errors for my API-based services, which makes me think that I don't have 
any performance issues... I probably have human users disappearing for 
random reasons.


The errors in mod_jk.log look like this:

[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] 
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to 
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] 
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to 
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1595): service failed, worker myworker is in 
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1614): unrecoverable error 200, request failed. 
Client failed in the middle of request, we can't recover to another 
instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker


(Note that the last message "Aborting connection for worker=myworker" 
may have a bug; my actual worker name has a name containing a hyphen (-) 
and only the text before the hyphen is being emitted in that error 
message.)


Anyway, when researching these errors, it would be helpful to me to know 
which requests are failing. By looking at the access_log, I only see a 
single request logged for 04:19:15 on that server so it's probably the 
right one, but httpd says that the response code is 302 instead of e.g. 
50x for an error.


When we log these kinds of errors, it would be great to know a few 
things IMO:


1. What was the URL of the request
2. How long did the client wait for the response before we found we 
couldn't write to the stream (or, conversely, the start-timestamp of the 
request as well as the timestamp of the error, which I think is already 
in the log itself)


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. The 
function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


It looks like I needed a few more things in order to get this to work:

  {
char *timestamp = malloc(32);
apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
apr_time_exp_gmt(timerec, ap->r->request_time);
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
   "(%s) Request to (%s %s) started at %s",
   ae->worker->name, r->method, r->req_uri, timestamp);
free(timerec);
free(timestamp);
  }

The compiler wouldn't let me use an automatically-allocated char[32] so 
I had to malloc it. I also had to convert from long to apr_time_exp_t 
which required another structure/malloc as well.


Finally, I had to cast the r->ws_private to apache_private_data_t* which 
required me to copy/paste the definition of apache_private_data_t from 
mod_jk.h into jk_ajp_common.c -- just as a test for now.


Obviously, this works only for Apache httpd.

I have it running on one of my web servers for now -- hoping to catch an 
error and see this additional logging to see if it's helpful to me. (LOL 
just segfaulted; time to go back and look.)


What would be the best way to get the "start time" of the request in a 
platform-independent way? Maybe just expand the jk_ws_service structure 
to include it?


-chris

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



[ANN] Apache Tomcat 8.5.79 available

2022-05-24 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.79.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.79 is a bugfix and feature release. The notable
changes compared to 8.5.78 include:

- Provide a property source that sources values from Kubernetes service
  bindings. Provided by Sumit Kulhadia and Gareth Evans.

- The root cause of the Linux kernel duplicate accept bug has been
  identified along with the version of the kernel that includes the
  fix. The error message displayed when this bug occurs has been
  updated to reflect this new information and to advise users to update
  to a version of the OS that uses kernel 5.10 or later. Thanks to
  Christopher Gual for the research into this issue.

- Update the packaged version of the Tomcat Native Library to 1.2.33 to
  pick up Windows binaries built with OpenSSL 1.1.1o.

- Add support for encrypted PKCS#1 formatted private keys when
  configuring the internal, in-memory key store.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Re: [ANN] Apache Tomcat 8.5.79 available

2022-05-23 Thread Christopher Schultz

All,

I jumped the gun on sending this announcement, so I went ahead and 
updated the web site, too. The CDN doesn't have the release artifacts, 
yet, but the ASF downloads server does.


Please be patient until the CDN updates.

Thanks,
-chris

On 5/23/22 16:56, Christopher Schultz wrote:

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.79.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.79 is a bugfix and feature release. The notable
changes compared to 8.5.78 include:

- Provide a property source that sources values from Kubernetes service
   bindings. Provided by Sumit Kulhadia and Gareth Evans.

- The root cause of the Linux kernel duplicate accept bug has been
   identified along with the version of the kernel that includes the
   fix. The error message displayed when this bug occurs has been
   updated to reflect this new information and to advise users to update
   to a version of the OS that uses kernel 5.10 or later. Thanks to
   Christopher Gual for the research into this issue.

- Update the packaged version of the Tomcat Native Library to 1.2.33 to
   pick up Windows binaries built with OpenSSL 1.1.1o.

- Add support for encrypted PKCS#1 formatted private keys when
   configuring the internal, in-memory key store.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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



[ANN] Apache Tomcat 8.5.79 available

2022-05-23 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.79.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.79 is a bugfix and feature release. The notable
changes compared to 8.5.78 include:

- Provide a property source that sources values from Kubernetes service
  bindings. Provided by Sumit Kulhadia and Gareth Evans.

- The root cause of the Linux kernel duplicate accept bug has been
  identified along with the version of the kernel that includes the
  fix. The error message displayed when this bug occurs has been
  updated to reflect this new information and to advise users to update
  to a version of the OS that uses kernel 5.10 or later. Thanks to
  Christopher Gual for the research into this issue.

- Update the packaged version of the Tomcat Native Library to 1.2.33 to
  pick up Windows binaries built with OpenSSL 1.1.1o.

- Add support for encrypted PKCS#1 formatted private keys when
  configuring the internal, in-memory key store.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Re: [ANN] ApacheCon NA 2022 in New Orleans, 3-6 Oct 2022, CFP is OPEN!

2022-05-23 Thread Christopher Schultz

Jon,

On 5/23/22 16:41, jonmcalexan...@wellsfargo.com.INVALID wrote:

Understood.

I'm willing to give it a try if you want to sign me up, but I have to
do it virtual. Traveling is not possible for me.
Oh. Sorry about that; it will need to be in-person. We don't have any 
set up to do pre-recorded or virtual presentations (that I know of) at 
the moment.


Thanks,
-chris

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



Re: [ANN] ApacheCon NA 2022 in New Orleans, 3-6 Oct 2022, CFP is OPEN!

2022-05-23 Thread Christopher Schultz

Jon,

On 5/23/22 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

I would really Love to have something, but I just don't have the time
to work on anything like this
You could just talk about something you are already doing. It doesn't 
need to be ground-breaking work. Something along the lines of "we are 
using Tomcat feature X to solve problem Y at job Z". As long as it's not 
an advertisement for your company/product.


I mean... most of the presentations given by committers are like "Here's 
how to do this fairly mundane thing like connect httpd -> Tomcat".



nor do I feel confident enough yet.


I'm sure you'd do fine. It's not a hostile crowd.


Chris keeps blowing holes in my understanding so now I think I need
to go and fine-tooth thru the documentation. I really feel I know
proper "instance" configuration, but now, not so sure. :-=) Maybe in
an upcoming year when I'm older, closer to retirement age. :-D
The proper configuration it the one that's working for you... especially 
if you understand it! If you don't understand youre configuration, you 
will be afraid to change anything for the better... or the worse. :)


If it takes you a while to figure something out, you are probably not 
alone. You could give a talk on "How I Learned to Stop Worrying and Love 
the Configuration" or whatever. Not everybody thinks the same way, and 
hearing it from you instead of (e.g.) me might be better for the audience.


-chris

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



Re: [ANN] ApacheCon NA 2022 in New Orleans, 3-6 Oct 2022, CFP CLOSES TODAY!!

2022-05-23 Thread Christopher Schultz

All,

If you were considering submitting a presentation, please do it *RIGHT NOW*.

Thank,
-chris


On 4/7/22 10:26, Christopher Schultz wrote:

All,

[Cross-posting to dev@, please reply to users@]

ApacheCon NA 2022 is back *in-person* in New Orleans, Louisiana. It will 
be held 3 - 6 October 2022 at the Canal Street Sheraton right next to 
the French Quarter.


The call-for-presentations is currently open and we are looking to fill 
a 3-day track for Tomcat, so please submit your proposals today!


https://www.apachecon.com/acna2022/
(The link at the top is a little obscure, but at the top of the page 
there is a "Call for Presentations" where you can submit a proposal).


Note that you don't have to have the presentation ready to go today in 
order to make a proposal. It's just gotta be ready around 30 seconds 
before you start to present it ;)


(There is a tradition at ApacheCon of editing ones slides during the 
previous presentation. I don't recommend it, but anyone who is 
intimidated by the process can rest assured that even repeat-presenters 
are putting things together at the last moment.)


Anyone who has never attended an ApacheCon should consider making this 
year their first: it's great fun, and you get to meet a lof of folks 
from all over the ASF, not just the Tomcat or httpd people, but folks 
working on projects you've never even heard of.


If you aren't sure if you are interested in presenting, or aren't sure
if you have the experience, knowledge, etc. to warrant a position as a
speaker, please consider the following:

1. This is a welcoming community
2. This community exists to serve YOU
3. You are a part of this community
4. Helping others within the community encourages others to do the same
5. Topics can be very wide-ranging. Here are some examples of
presentations from previous ApacheCon events:

   [From Committers / directly about Tomcat]
   - Running Apache Tomcat on GraalVM
   - Tomcat in clusters and clouds
   - Using Let's Encrypt with Tomcat
   - Securing Tomcat
   - Reverse-proxying Tomcat
   - Load balancing with Tomcat
   - Clustering with Tomcat

   [From Non-Committers or not directly about Tomcat]
   - Packaging Tomcat for Linux Distributions
   - I Love Lucee -- a Java implementation of Cold Fusion
   - Routing CDN traffic at scale using Tomcat
   - Secure Web Applications using Apache Fortress
   - Monitoring Tomcat; various tools
   - Building Reactive Applications on Tomcat
   - Troubleshooting performance using thread dumps
   - High Throughput Production Systems on Tomcat
   - Why I Love Open Source
   - Introduction to Spring Boot
   - Tomcat, TomEE, and Meecrowave
   - Apache Tomcat: Enabling Scripting Languages in JSPs

   If you are using Tomcat at $work and doing something interesting,
we'd love to hear about it.

6. You don't need to be the foremost expert in $feature to talk about it
7. We are actively looking for speakers to talk about these and other
topics:

   - Deploying Tomcat in an auto-scaling environment (e.g. AWS EBS)
   - Tomcat should really have [Feature X]
   - Whatever you think might be interesting!

Please consider speaking ESPECIALLY if you haven't done so before. If 
you are worried about whether your idea is good enough: don't. Just 
submit your idea to the CFP -- you don't have to write-up the 
presentation in order to submit an idea, just write a paragraph or two 
about what you want to do -- and the track chairpersons 
(chairpeople?[1]) will decide whether or not to include your 
presentation in the event. (And chances are good that if you submit an 
idea it will be accepted.)


Please reply to the users list with any questions you may have about
ApacheCon, the Tomcat track, or submitting a talk proposal.

Thanks,
-chris

On behalf of all ApacheCon 2022 Tomcat Track chairpersons


[1]
https://vignette.wikia.nocookie.net/rickandmorty/images/c/cd/Furniture.png/revision/latest/scale-to-width-down/1000?cb=20160910223642 



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



Re: [ANN] ApacheCon NA 2022 in New Orleans, 3-6 Oct 2022, CFP is OPEN!

2022-05-23 Thread Christopher Schultz

Coty,

On 5/23/22 15:22, Coty Sutherland wrote:

On Fri, Apr 29, 2022 at 2:53 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

Please remember that the ApacheCon North American conference is still
accepting presentations until 23 May 2022.

The Tomcat track currently has *zero* proposals, and we were hoping to
fill a 3-day track.

So please, send in your ideas for presentations!


How are we doing now? I just submitted one with the hopes of submitting a
second, but I think one is about all I can handle at the moment...


jfclere proposed 4 talks and it looks like remm added another 2. I guess 
yours is the 7th. (I can't actually see the submitter names right now). 
I haven't done any, yet (I was going to wait to see what else showed up).


The CFP is officially over today, so I'll probably drop 3a few in there, 
too.


I'm sad to see that no non-committers submitted anything. Maybe its just 
that people aren't ready to travel/conference quite yet.


-chris

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



  1   2   3   4   5   6   7   8   9   10   >