Aw: Re: Servlet-Mapping having %-sign

[Peter Rader]

> Peter,
>
> On 12/29/23 07:56, Peter Rader wrote:
> > having a URL like this:
> >
> > https://localhost:8443/index.html works perfect. This is my mapping:
> >
> > 
> > Nano-Nano-Servlet
> > /index.html
> > 
> > 
> > Nano-Nano-Servlet
> > *.ts
> > 
> >
> > Unfortunately this URI does not load (because of the %-sign):
> >
> > https://localhost:8443/@rm%2fmodel.ts
> >
> > It gives a http-status:400 having the message "Invalid URI: [noSlash]"
>
> What's the use-case for having a client use a %-encoded / in your URL?
> That kind of thing is usually evidence of a hacking attempt, which is
> why Tomcat returns a 400 response.

I generate TypeScript dynamically. In order to use it in Node: I register a 
servlet to create npm-packages at run-time. On Node-side I use this command:

1. Register servlet as npm source: 'npm config set 
@myapp:registry=https://nonofyourbusiness.mydomain.com:8443/'
2. Start the download: 'npm install @myapp/model --loglevel verbose'  (hint: 
@myapp is the tomcat)

This is the output of the second command:

npm info it worked if it ends with ok
npm verb cli [
npm verb cli   '/home/grim/.nvm/versions/node/v14.18.1/bin/node',
npm verb cli   '/home/grim/.nvm/versions/node/v14.18.1/bin/npm',
npm verb cli   'install',
npm verb cli   '@myapp/model@1.0.0',
npm verb cli   '--loglevel',
npm verb cli   'verbose'
npm verb cli ]
npm info using npm@6.14.15
npm info using node@v14.18.1
npm verb config Skipping project config: /home/grim/.npmrc. (matches userconfig)
npm verb npm-session 778f7308eede99d8
npm http fetch GET 200 
https://nonofyourbusiness.mydomain.com:8443/@myapp%2fmodel 28ms
npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 
14ms
npm timing stage:loadCurrentTree Completed in 71ms
npm timing stage:loadIdealTree:cloneCurrentTree Completed in 0ms
npm timing stage:loadIdealTree:loadShrinkwrap Completed in 3ms
npm timing stage:loadIdealTree:loadAllDepsIntoIdealTree Completed in 1ms
npm timing stage:loadIdealTree Completed in 5ms
npm timing stage:generateActionsToTake Completed in 1ms
npm verb correctMkdir /home/grim/.npm/_locks correctMkdir not in flight; 
initializing
npm verb lock using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock for 
/home/grim/node_modules/.staging
npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 
7ms
npm timing action:extract Completed in 10ms
npm timing action:finalize Completed in 1ms
npm timing action:refresh-package-json Completed in 1ms
npm info lifecycle model@1.0.0~preinstall: model@1.0.0
npm timing action:preinstall Completed in 1ms
npm info linkStuff model@1.0.0
npm timing action:build Completed in 0ms
npm info lifecycle model@1.0.0~install: model@1.0.0
npm timing action:install Completed in 1ms
npm info lifecycle model@1.0.0~postinstall: model@1.0.0
npm timing action:postinstall Completed in 0ms
npm verb unlock done using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock 
for /home/grim/node_modules/.staging
npm timing stage:executeActions Completed in 18ms
npm timing stage:rollbackFailedOptional Completed in 1ms
npm timing stage:runTopLevelLifecycles Completed in 97ms
npm WARN saveError ENOENT: no such file or directory, open 
'/home/grim/package.json'
npm info lifecycle undefined~preshrinkwrap: undefined
npm info lifecycle undefined~shrinkwrap: undefined
npm info lifecycle undefined~postshrinkwrap: undefined
npm WARN enoent ENOENT: no such file or directory, open 
'/home/grim/package.json'
npm verb enoent This is related to npm not being able to find a file.
npm verb enoent
npm WARN grim No description
npm WARN grim No repository field.
npm WARN grim No README data
npm WARN grim No license field.

npm http fetch POST 400 
https://registry.npmjs.org/-/npm/v1/security/audits/quick 266ms
+ model@1.0.0 (as @myapp/model)
added 1 package in 0.347s
npm verb exit [ 0, true ]
npm timing npm Completed in 463ms
npm info ok

--- end of console output

As you might have noticed, this time the URL responded successfully. This is 
because I modified catalina.properties 
(org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true).

>
> https://stackoverflow.com/questions/19576777/why-does-apache-tomcat-handle-encoded-slashes-2f-as-path-separators

I agree that this might become a security risk. Since the mentioned mod_jk-bug 
is not affected in this particular case, I could exoticize the tomcat-config to 
undo tomcats built-in-workaround throu the catalina.properties.

It does not feel like an elegant solution, but it works for now. If however npm 
might be the future for some developers, a redesign of tomcat may a more 
desirable solution. It might be hard to tell the npm people to change their 
"way of downloading npm-packages" because "mod_jk have a bug" might not be 
concidered as a convincing argument. :-D


>
> -chris
&g

Servlet-Mapping having %-sign

[Peter Rader]

Hey,
 
having a URL like this:
 
https://localhost:8443/index.html works perfect. This is my mapping:
 

Nano-Nano-Servlet
/index.html


Nano-Nano-Servlet
*.ts

 
Unfortunately this URI does not load (because of the %-sign):
 
https://localhost:8443/@rm%2fmodel.ts
 
It gives a http-status:400 having the message "Invalid URI: [noSlash]"

Any ideas?
 
Kind regards / Happy new year

Peter Rader

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

Re: [EXT] Datadog _ JMX Integration facing connection issues.

[Peter Kreuser]

Sai Vamsi,

> Am 13.12.2023 um 19:59 schrieb Chuck Caldarale :
> 
> 
>> On Dec 13, 2023, at 10:36, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) 
>>  wrote:
>> 
>> as you just asked .,
>> I do have a process with Catalina.
>> 
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# netstat -tulpn
>> Active Internet connections (only servers)
>> Proto Recv-Q Send-Q Local Address   Foreign Address State
>>PID/Program name
>> tcp6   0  0 :::34753:::*LISTEN   
>>1/java
>> tcp6   0  0 :::9109 :::*LISTEN   
>>1/java
>> tcp6   0  0 :::10109:::*LISTEN   
>>1/java
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ^C
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ps aux | grep 
>> catalina
>> root 744  0.0  0.0   6460   680 pts/1S+   11:47   0:00 grep 
>> --color=auto catalina
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/#
> 
> 

you have to figure out WHY tomcat is not starting! There should be log files or 
error messages on the console. It seems you have put an error somewhere in any 
of the configfiles. It's not at all a question of the ports not being 
allocated. Take a step back and make tomcat launch again. After that we figure 
out where you have to set the options...

Please detail how you start tomcat and show the output of startup (the 
beginning and last lines should be enough).

Again, don't put any java options for tomcat in any global environment options 
(JAVA_OPTS, CATALINA_OPTS) in your shell. Only in setenv.sh .

Peter

> That shows only the grep process looking for catalina, not anything using 
> catalina. If Tomcat were actually running, you’d see something like this 
> (slightly reformatted for clarity):
> 
> chuck@Chuck-MacBookPro apache-tomcat-9.0.83 > ps aux | grep catalina
> chuck16879   0.0  0.0 408626896   1376 s000  S+   12:53PM   
> 0:00.00 grep catalina
> chuck16874   0.0  0.9 415316912 153296 s000  S12:53PM   
> 0:02.66 
> /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home/bin/java
> -Djava.util.logging.config.file=/Users/chuck/Downloads/apache-tomcat-9.0.83/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
> -Dtest_port=9090
> -Dignore.endorsed.dirs=
> -classpath
> /Users/chuck/Downloads/apache-tomcat-9.0.83/bin/bootstrap.jar:/Users/chuck/Downloads/apache-tomcat-9.0.83/bin/tomcat-juli.jar
> -Dcatalina.base=/Users/chuck/Downloads/apache-tomcat-9.0.83
> -Dcatalina.home=/Users/chuck/Downloads/apache-tomcat-9.0.83
> -Djava.io.tmpdir=/Users/chuck/Downloads/apache-tomcat-9.0.83/temp 
> org.apache.catalina.startup.Bootstrap
> start
> 
> 
>  - Chuck
> 

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

Re: CredentialHandler not working for MD5

[Peter Otto]

Ok thanks.

Got it is now working.

This step was missing.



We didn’t have to do this before.

No mention of having to edit Digest inside context.xml here
https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html

Tried SHA-256, couldn’t get it to work.  But MD5 does.
Thanks again.

This e-mail and any files transmitted with it are the property of Arthrex, Inc. 
and/or its affiliates, are confidential, and are intended solely for the use of 
the individual or entity to whom this e-mail is addressed. If you are not one 
of the named recipient(s) or otherwise have reason to believe that you have 
received this message in error, please notify the sender at 239-643-5553 and 
delete this message immediately from your computer. Any other use, retention, 
dissemination forwarding, printing or copying of this e-mail is strictly 
prohibited. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, while Arthrex uses virus protection, the recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

Re: CredentialHandler not working for MD5

[Peter Otto]

  1.  Configure BASIC auth with clear-text passwords in the Realm and get
that working.
  2.  Switch to DIGEST auth with clear-text passwords in the Realm and get
that working.
  3.  Then configure DIGEST auth and digested passwords in the Realm.
Hi Chris,

Step 1 & 2 work
Step 3 will not work with the clear txt password, only the digested password, 
which means the text password in tomcat-users.xml.   In past versions of 
Tomcat, the clear text password would work.

On line # 1154 in Realmbase.java we read.


String digestValue = username + ":" + realmName + ":" +  getPassword(username);

The method getPassword(username) is using the digested password, when it should 
use  the clear text password.

Here is how I run digest in powershell.
.\digest.bat -a MD5 -i 1 -s 0 tomcat:UserDatabase:nobueno

RealmBase.java is not using the clear text password, instead it is using the 
digested password. This will return false for the manager access.

When I replace the getPassword(username) and replace it with the clear text 
password, it will then WORK.
This e-mail and any files transmitted with it are the property of Arthrex, Inc. 
and/or its affiliates, are confidential, and are intended solely for the use of 
the individual or entity to whom this e-mail is addressed. If you are not one 
of the named recipient(s) or otherwise have reason to believe that you have 
received this message in error, please notify the sender at 239-643-5553 and 
delete this message immediately from your computer. Any other use, retention, 
dissemination forwarding, printing or copying of this e-mail is strictly 
prohibited. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, while Arthrex uses virus protection, the recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

Re: CredentialHandler not working for MD5

[Peter Otto]

More info….



In the Request Header-> Authorization->Response.  Response is used as the 
clientDigest.  However this response is generated, it is incorrect.

Need to understand where Tomcat generates this Response because it is used for 
comparison of the serverDigest.  And if the server digest equals the 
clientDigest, then it works.



The way I understand it, the clientDigest comes from the client entering in the 
username/pwd on the popup box.




From: Peter Otto 
Date: Monday, November 13, 2023 at 11:05 AM
To: Tomcat Users List 
Subject: Re: CredentialHandler not working for MD5
Chris,

Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 
  8 months ago there was a change for RFC 7616.
https://urldefense.com/v3/__https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$<https://urldefense.com/v3/__https:/github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$>

To bypass the array of digest,
I commented out some code so it was forced to use MD5 only.

But In the RealmBase, I really don’t understand what getDigest is doing.
When I create a MD5 digest, I use Username:Realm:Password.
In the code it is using Nonce, nc, cnonce, gop…..




From: Christopher Schultz 
Date: Friday, November 10, 2023 at 1:44 PM
To: users@tomcat.apache.org 
Subject: Re: CredentialHandler not working for MD5
Peter,

On 11/10/23 16:30, Peter Otto wrote:
> With 9.0.82, and the latest version 10, I get the same problem.
> So I assume it stopped working since 9.0.74 all the way up to 9.0.82
>
> Removing the Realm LockOutRealm did not work either.

Thanks for double-checking both of those.

I don't see anything in the changelog that seems like it would be
related. Thing I suspect are related were in an earlier release.

Are you able to run under a debugger, and are you comfortable doing
that? It's pretty easy to set a breakpoint in the Realm and/or
CredentialHandler to see what's being done when you try to authenticate.

-chris

> From: Christopher Schultz 
> Date: Friday, November 10, 2023 at 12:35 PM
> To: users@tomcat.apache.org 
> Subject: Re: CredentialHandler not working for MD5
> Peter,
>
> On 11/10/23 13:27, Peter Otto wrote:
>> Logging into manager using MD5 works in 9.0.73 but now fails in 
>> 9.0.74->current
>> Steps to reproduce.
>>
>> Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 
>> tomcat:UserDatabase:nobueno
>>
>> tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0
>>
>>
>> Step 2. Use the digest # and place it in tomcat-users.xml
>> 
>> 
>> > roles="manager-gui,manager-script"/>
>>
>>
>> Step 3. Edit server.xml and add the CredentialHandler to use MD5
>>
>> 
>> > resourceName="UserDatabase">
>> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" 
>> algorithm="MD5" />
>> 
>> 
>>
>>
>>
>> Step 4. Edit the web.xml in manager to say
>> 
>>   DIGEST
>>   UserDatabase
>> 
>>
>> Step 5 start tomcat and try to access the manager.
>> On WIndows 2019 server/Chrome/OpenJDK11  type tomcat for the user
>> and nobueno for the password.
>>
>> This would work on versions 9.0.73 and earlier
>>
>> This stopped working from 9.0.74 and onwards.
>> The way to access the manager from 9.0.74+ is to use 
>> bb6c1c32b9b6df4f707c0e58f2c900e0 as the password.
>> In other words the text in tomcat-user.xml is the password.
>>
>> Anyone have any ideas how to fix this?  I have to use 9.0.74+ version of 
>> tomcat because of CVEs.
>
> If you temporarily remove the LockOutRealm, does the correct password work?
>
> If you upgrade to 9.0.82, does the correct password work?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> This e-mail and any files transmitted with it are the property of Arthrex, 
> Inc. and/or its affiliates, are confidential, and are intended solely for the 
> use of the individual or entity to whom this e-mail is addressed. If you are 
> not one of the named recipient(s) or otherwise have reason to believe that 
> you have received this message in error, please notify the sender at 
> 239-643-5553 and delete this message immediately from your computer. Any 
> other use, rete

Re: CredentialHandler not working for MD5

[Peter Otto]

Chris,

Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 
  8 months ago there was a change for RFC 7616.
https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java

To bypass the array of digest,
I commented out some code so it was forced to use MD5 only.

But In the RealmBase, I really don’t understand what getDigest is doing.
When I create a MD5 digest, I use Username:Realm:Password.
In the code it is using Nonce, nc, cnonce, gop…..




From: Christopher Schultz 
Date: Friday, November 10, 2023 at 1:44 PM
To: users@tomcat.apache.org 
Subject: Re: CredentialHandler not working for MD5
Peter,

On 11/10/23 16:30, Peter Otto wrote:
> With 9.0.82, and the latest version 10, I get the same problem.
> So I assume it stopped working since 9.0.74 all the way up to 9.0.82
>
> Removing the Realm LockOutRealm did not work either.

Thanks for double-checking both of those.

I don't see anything in the changelog that seems like it would be
related. Thing I suspect are related were in an earlier release.

Are you able to run under a debugger, and are you comfortable doing
that? It's pretty easy to set a breakpoint in the Realm and/or
CredentialHandler to see what's being done when you try to authenticate.

-chris

> From: Christopher Schultz 
> Date: Friday, November 10, 2023 at 12:35 PM
> To: users@tomcat.apache.org 
> Subject: Re: CredentialHandler not working for MD5
> Peter,
>
> On 11/10/23 13:27, Peter Otto wrote:
>> Logging into manager using MD5 works in 9.0.73 but now fails in 
>> 9.0.74->current
>> Steps to reproduce.
>>
>> Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 
>> tomcat:UserDatabase:nobueno
>>
>> tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0
>>
>>
>> Step 2. Use the digest # and place it in tomcat-users.xml
>> 
>> 
>> > roles="manager-gui,manager-script"/>
>>
>>
>> Step 3. Edit server.xml and add the CredentialHandler to use MD5
>>
>> 
>> > resourceName="UserDatabase">
>> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" 
>> algorithm="MD5" />
>> 
>> 
>>
>>
>>
>> Step 4. Edit the web.xml in manager to say
>> 
>>   DIGEST
>>   UserDatabase
>> 
>>
>> Step 5 start tomcat and try to access the manager.
>> On WIndows 2019 server/Chrome/OpenJDK11  type tomcat for the user
>> and nobueno for the password.
>>
>> This would work on versions 9.0.73 and earlier
>>
>> This stopped working from 9.0.74 and onwards.
>> The way to access the manager from 9.0.74+ is to use 
>> bb6c1c32b9b6df4f707c0e58f2c900e0 as the password.
>> In other words the text in tomcat-user.xml is the password.
>>
>> Anyone have any ideas how to fix this?  I have to use 9.0.74+ version of 
>> tomcat because of CVEs.
>
> If you temporarily remove the LockOutRealm, does the correct password work?
>
> If you upgrade to 9.0.82, does the correct password work?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> This e-mail and any files transmitted with it are the property of Arthrex, 
> Inc. and/or its affiliates, are confidential, and are intended solely for the 
> use of the individual or entity to whom this e-mail is addressed. If you are 
> not one of the named recipient(s) or otherwise have reason to believe that 
> you have received this message in error, please notify the sender at 
> 239-643-5553 and delete this message immediately from your computer. Any 
> other use, retention, dissemination forwarding, printing or copying of this 
> e-mail is strictly prohibited. Please note that any views or opinions 
> presented in this email are solely those of the author and do not necessarily 
> represent those of the company. Finally, while Arthrex uses virus protection, 
> the recipient should check this email and any attachments for the presence of 
> viruses. The company accepts no liability for any damage caused by any virus 
> transmitted by this email.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This e-mail and any files transmitted with it are the property of Arthrex, Inc. 
and/or its affiliates, are confidential, and are intended solely for the use of 
the individual or entity to whom this e-mail is addressed. If you are not one 
of the named recipient(s) o

Re: CredentialHandler not working for MD5

[Peter Otto]

Chris,

With 9.0.82, and the latest version 10, I get the same problem.
So I assume it stopped working since 9.0.74 all the way up to 9.0.82

Removing the Realm LockOutRealm did not work either.

Thanks


From: Christopher Schultz 
Date: Friday, November 10, 2023 at 12:35 PM
To: users@tomcat.apache.org 
Subject: Re: CredentialHandler not working for MD5
Peter,

On 11/10/23 13:27, Peter Otto wrote:
> Logging into manager using MD5 works in 9.0.73 but now fails in 
> 9.0.74->current
> Steps to reproduce.
>
> Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 
> tomcat:UserDatabase:nobueno
>
> tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0
>
>
> Step 2. Use the digest # and place it in tomcat-users.xml
> 
> 
>  roles="manager-gui,manager-script"/>
>
>
> Step 3. Edit server.xml and add the CredentialHandler to use MD5
>
> 
>  resourceName="UserDatabase">
>  className="org.apache.catalina.realm.MessageDigestCredentialHandler" 
> algorithm="MD5" />
> 
> 
>
>
>
> Step 4. Edit the web.xml in manager to say
> 
>  DIGEST
>  UserDatabase
>
>
> Step 5 start tomcat and try to access the manager.
> On WIndows 2019 server/Chrome/OpenJDK11  type tomcat for the user
> and nobueno for the password.
>
> This would work on versions 9.0.73 and earlier
>
> This stopped working from 9.0.74 and onwards.
> The way to access the manager from 9.0.74+ is to use 
> bb6c1c32b9b6df4f707c0e58f2c900e0 as the password.
> In other words the text in tomcat-user.xml is the password.
>
> Anyone have any ideas how to fix this?  I have to use 9.0.74+ version of 
> tomcat because of CVEs.

If you temporarily remove the LockOutRealm, does the correct password work?

If you upgrade to 9.0.82, does the correct password work?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This e-mail and any files transmitted with it are the property of Arthrex, Inc. 
and/or its affiliates, are confidential, and are intended solely for the use of 
the individual or entity to whom this e-mail is addressed. If you are not one 
of the named recipient(s) or otherwise have reason to believe that you have 
received this message in error, please notify the sender at 239-643-5553 and 
delete this message immediately from your computer. Any other use, retention, 
dissemination forwarding, printing or copying of this e-mail is strictly 
prohibited. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, while Arthrex uses virus protection, the recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

CredentialHandler not working for MD5

[Peter Otto]

Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current
Steps to reproduce.

Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 
tomcat:UserDatabase:nobueno

tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0


Step 2. Use the digest # and place it in tomcat-users.xml





Step 3. Edit server.xml and add the CredentialHandler to use MD5









Step 4. Edit the web.xml in manager to say

DIGEST
UserDatabase
  

Step 5 start tomcat and try to access the manager.
On WIndows 2019 server/Chrome/OpenJDK11  type tomcat for the user
and nobueno for the password.

This would work on versions 9.0.73 and earlier

This stopped working from 9.0.74 and onwards.
The way to access the manager from 9.0.74+ is to use 
bb6c1c32b9b6df4f707c0e58f2c900e0 as the password.
In other words the text in tomcat-user.xml is the password.

Anyone have any ideas how to fix this?  I have to use 9.0.74+ version of tomcat 
because of CVEs.

Thank you all
This e-mail and any files transmitted with it are the property of Arthrex, Inc. 
and/or its affiliates, are confidential, and are intended solely for the use of 
the individual or entity to whom this e-mail is addressed. If you are not one 
of the named recipient(s) or otherwise have reason to believe that you have 
received this message in error, please notify the sender at 239-643-5553 and 
delete this message immediately from your computer. Any other use, retention, 
dissemination forwarding, printing or copying of this e-mail is strictly 
prohibited. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, while Arthrex uses virus protection, the recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

Forward: Jakarta Servlet support decision (insight to a discussion in freemarker-devs)

[Peter Rader]

FYI I share this mail from the freemarker-mailsystem for your entertainment, 
enjoy.

> Gesendet: Dienstag, 07. November 2023 um 23:50 Uhr
> Von: "Daniel Dekany" 
> An: "FreeMarker developer list" 
> Subject: Jakarta Servlet support decision
>
> The package of Servlet related classes has changed because of Jakarta,
> which breaks our Servlet support (freemarker.ext.servlet), which is packged
> into freemarker.jar.
> 
> We have to choose which end result we want (ignore the "how" for now) as
> the solution, from these two (as far as I can tell):
> 
> 1. We can copy the `freemarker.ext.servlet` package into
> `freemarker.ext.jakartaservlet` (or such), and we will only have the normal
> artifact in Maven Central, which contains that, and also the older
> freemarker.ext.servlet. Explanation: As you probably know, 2.x has a single
> monolithic freemarker.jar artifact, which already contains support classes
> of various optional dependencies. We already support multiple incompatible
> Serlvet/JSP versions, and has separate version-specific classes for some.
> But, classes like freemarker.ext.servlet.FreemarkerServlet managed to stay
> common amongst Servlet API versions. For the Jakarta change not even that
> can remain common of course.
> 
> 2. We can have an additional artifact variant (let's say via Maven
> classifier "jakarta"), that still uses the `freemarker.ext.servlet`
> package, but there that links to the Jakarta Servlet classes. This artifact
> will drop support for pre-Jakarta Servlet/JSP versions.
> 
> Possibility 1 pro: We don't have to publish one more artifact. Also, then
> users don't have to fiddle with dependency management to choose the
> artifact with the "jakarta" classifier.
> 
> Possibility 1 con: Any existing dependent Java code that used
> `freemarker.ext.servlet` so far, and wants to migrate to a Jakarta Servlet
> container, has to be modified to link to `freemarker.ext.jakartaservlet`
> instead. That sounds quite bad, however, the same dependent Java code
> likely has to be modified anyway, to link to Jakarta Servlet classes.
> Except, there are tools, like
> https://github.com/apache/tomcat-jakartaee-migration, that transforms jar-s
> to depend on Jakarta Servlet API, but same tools of course won't replace
> links to freemarker.ext.servlet with freemarker.ext.jakartaservlet, so some
> pain is expected. Also, `web.xml`-s that refer to
> `freemarker.ext.servlet.FreemarkerSerlvet` also have to be modified, if
> someone uses a Jakarta container.
> 
> Opinions?
> 
> Note 1: We had two attempts so far on this issue, but certainly the actual
> solution will be a 3rd one. Anyway, the "how" is now not the point now, but> 
> here they are:
> 
> - 
> https://github.com/apache/freemarker/pull/94[https://github.com/apache/freemarker/pull/94]
> - 
> https://github.com/apache/freemarker/pull/95[https://github.com/apache/freemarker/pull/95]
> 
> Note 2: At some later(!) point, maybe in a FreeMarker 2.4.0, we can get rid
> of non-Jakarta servlet support. At the same point, we will also get rid of
> the GAE/non-GAE variety. So we could end up with just a single variant of
> the freemarker 2.x artifact, over time.
> 
>

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

Re: Admin password for Tomcat

[Peter Kreuser]

Jerry,

> Am 05.11.2023 um 02:34 schrieb Brian Wolfe :
> 
> You need to build a custom realm for that if you're using tomcat to manage
> your user sessions and not creating your own sessions for your application.
> You can extend the existing one that you're using. I assume you're using
> the JDBC Realm since you said you have an USERS table. So you could add
> another field to your table and extend the JDBC class to do an additional
> check on your admin pwd field if you don't want them to have a second
> account.
> 
> https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Standard_Realm_Implementations
> 
> You will want to look at the source of the realm implementation to see how
> you need to extend it. So you shouldn't have to do too much to get the
> functionality you're looking for.
> 
>> On Sat, Nov 4, 2023 at 8:18 PM Jerry Malcolm  wrote:
>> 
>> My support team needs to be able to log in to our site as various users
>> (on behalf of...) to be able to see exactly what they are seeing since
>> roles, access groups, history is different for different users.  I would
>> like to implement an admin password where I can log in as any userId
>> with this password.  I totally realize the security risks involved in
>> this.  But I am handling the security risks with additional
>> authorizations.

Back in the days when we had this requirement, we implemented an "admin tool" 
where we had the admin user login as themselves and then pick the user they 
wanted to see. At this time the password check was simply skipped. No fiddling 
with the password table, no security flaws as the admin tool was not available 
to the public.

>>  I simply need to make every user have two passwords...
>> their real personal password, and the admin password.  The only
>> alternative I have right now is to save off the user's password hash in
>> the USERS table, replace it with my password hash, then restore the
>> user's original password when I'm done.  I'm not thrilled with that
>> solution first because it's a pain and error prone, and also because the
>> user can no longer log in while their password is replaced with my
>> password.
>> 
>>  I figure this function is buried in the authenticator code somewhere.
>> But I'd first like to see if anybody has done anything like this
>> already.  If not, could somebody point me in the right direction to the
>> tomcat source file that I'm going to need to modify and also what's
>> involved in making authentication use my updated class instead of the
>> default.
>> 
>> Suggestions?
>> 

Would that be a solution?

Peter

>> Thx
>> 
>> Jerry
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
> --
> Thanks,
> Brian Wolfe
> https://www.linkedin.com/in/brian-wolfe-3136425a/

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

Re: HSTS on 401 / error pages

[Peter Kreuser]

d) !!!

BTW: HSTS needs to be evaluated only once and then sticks in the browser!
So unless the 401 is the first page ever, this change would not be really 
necessary.

Peter

> Am 15.09.2023 um 17:58 schrieb Thomas Hoffmann (Speed4Trade GmbH) 
> :
> 
> Hello Christ,
> 
>> -Ursprüngliche Nachricht-
>> Von: Christopher Schultz 
>> Gesendet: Freitag, 15. September 2023 17:15
>> An: users@tomcat.apache.org
>> Betreff: Re: AW: HSTS on 401 / error pages
>> 
>> Thomas,
>> 
>>> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> Hello Chris,
>>> 
>>>> -Ursprüngliche Nachricht-
>>>> Von: Christopher Schultz 
>>>> Gesendet: Donnerstag, 14. September 2023 15:26
>>>> An: users@tomcat.apache.org
>>>> Betreff: Re: HSTS on 401 / error pages
>>>> 
>>>> Thomas,
>>>> 
>>>> Please start a new thread next time.
>>> 
>>> Sorry, I thought removing all content and subject is sufficient. Maybe
>>> the message-id header is used internally(?)
>> 
>> Absolutely. That's what "reply" does on a mailing list...
>> 
>>> 
>>>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>>>> Hello everyone,
>>>>> 
>>>>> I would like to get your opinion about the HttpHeaderSecurityFilter
>>>>> in
>>>> Tomcat.
>>>>> I configured HSTS in Tomcat and it works well.
>>>>> When I do a pen-test with burpsuite it complains that HSTS header is
>>>> missing on 401 responses.
>>>>> I couldn’t find much information about whether HSTS makes sense for
>>>> error pages.
>>>>> 
>>>>> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
>>>> expects the header.
>>>>> Are there any pros and cons about sending HSTS on 401 response?
>>>> 
>>>> You should always return an HSTS header.
>>>> 
>>>> How have you configured your HttpHeaderSecurityFilter? What is
>>>> causing the
>>>> 401 response? Which application is responding with that status?
>>>> 
>>>> -chris
>>>> 
>>> 
>>> Here are the requested details:
>>> 
>>> SecurityFilter is set in the web.xml of the application:
>>> 
>>>httpHeaderSecurity
>>>> class>org.apache.catalina.filters.HttpHeaderSecurityFilter
>>>true
>>>
>>> hstsEnabled
>>> true
>>>
>>> ...
>>> 
>>> Further down in the web.xml is a constraint:
>>>
>>>  
>>>  xxx
>>>  /*
>>>  
>>> 
>>>  
>>>  yyy
>>>  
>>> 
>>>  
>>>  CONFIDENTIAL
>>>  
>>>  
>>> 
>>> 
>>> There is no frontend-server, tomcat is directly accessed from the browser.
>>> It seems that burpsuite didn’t send authentication in the first place and 
>>> this
>> resulted in 401.
>>> 
>>> If I use curl https:///  I get similar result:
>>> < HTTP/1.1 401
>>> < WWW-Authenticate: Negotiate
>>> < Content-Type: text/html;charset=utf-8 < Content-Language: de <
>>> Content-Length: 439 < Date: Thu, 14 Sep 2023 13:58:10 GMT
>>> 
>>> When providing credentials to curl, the following headers are also included:
>>> < Strict-Transport-Security: max-age=31536000;includeSubDomains
>>> < X-Frame-Options: DENY
>>> < X-Content-Type-Options: nosniff
>>> < X-XSS-Protection: 1; mode=block
>>> 
>>> I hope this information helps.
>> 
>> Authentication is checked before any filters run, because authentication is
>> performed by a Valve, all of which run before any Filters run.
>> 
>> I'm not sure there is a way around this without
>> 
>> a. Using a fronting server of some kind
>> b. Getting a change of some kind made to Tomcat c. Hacking this yourself
>> 
>> (b) is probably the best option, though I'm not sure what the best form of
>> server-support for this would be.
>> 
>> Making HttpHeaderSecurity available in a Valve-packaging would do the trick,
>> but maybe this makes sense to add at a more fundamental level to Tomcat.
>> The problem is that HSTS is only one of

Re: CIS Tomcat 8 Benchmark (v1.1.0) -- Questions

[Peter Kreuser]

Robert,

While Mark Thomas will have a more detailled answer to this...

The finding behind this test is valid (information disclosure with server 
version in responses), though the remediation listed here is from looong time 
ago, when the was no ErrorReportValve to purge the version info.

So the CIS Tomcat 8(!) Guide is pretty outdated! Probably in more than this 
spot...

Peter

> Am 05.09.2023 um 14:03 schrieb Robert Turner :
> 
> While I think I know the answer to my question, I wanted to double-check
> with the group to confirm.
> 
> I have been asked to perform the CIS Apache Tomcat 8 Benchmark (v1.1.0) on
> our production Tomcat installation, and I am looking through the questions
> / information extraction requests, and I suspect they are not really
> evaluating what they think they are, and furthermore encouraging bad
> practices.
> 
> For instance, the first entry I have in the spreadsheet I was provided is
> listed as follows:
> 
> CIS Control:
> 2.1 Alter the Advertised server.info String (Scored)
> 
> Description:
> The server.info attribute contains the name of the application service.
> This value is presented to Tomcat clients when clients connect to the
> tomcat server.
> 
> Audit Procedures:
> Perform the following to determine if the server.info value has been
> changed:
> Extract the ServerInfo.properties file and examine the server.info
> attribute.
> $ cd $CATALINA_HOME/lib
> $ jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
> $ grep server.info org/apache/catalina/util/ServerInfo.properties
> 
> 
> So, other than a few issues with the audit procedures, etc. This seems to
> be doing the following:
> 
> a) evaluating a default value which I believe can be overridden and thus
> may not actually reflect the value the server may provide to external
> clients
> b) encouraging the modification of the catalina.jar contents to correct the
> default value
> 
> There are a few similar items (for server.number, server.built) (2.2, 2.3).
> 
> 
> Thoughts / comments from "those in the know"?
> 
> Thanks,
> 
> Robert

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

RateLimitFilter

[Peter Eichenauer]

Hi,

thank you for adding the RateLimitFilter in Tomcat 9.0.76. It is working 
as expected, but I wonder if the log message during initialisation is 
correct: Actual is [{3}] per [{4}] milliseconds. [{5}].


To me it looks like that parameter {4} is printed in seconds.

For example, this is my web.xml configuration:

RateLimitFilter

org.apache.catalina.filters.RateLimitFilter

bucketDuration
10


bucketRequests
10



my log shows:
[RateLimitFilter] initialized with [10] requests per [10] seconds. 
Actual is [16] per [16] milliseconds.


Thanks again,
Peter

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

Fw: AW: Maven tomcat7:redeploy upload reset/retry

[Peter Rader]

> > Hi Folks,
> >
> > I am running a tomcat 8.5.50.
> >
> > I try to upload a webapp using maven-tomcat7-plugin.
> >
> > It worked very good for a couple of years. I did nothing new to the
> > configuration.
> >
> > Then I see broken pipes during build:
> >
> >
> >     [INFO] Deploying war to http://www.foobar.de/manager/de.foobar.xxx-
> > 1.0.0-SNAPSHOT[https://deref-
> > gmx.net/mail/client/1mSXrDjDU9k/dereferrer/?redirectUrl=http%3A%2F%2Fw
> > ww.foobar.de%2Fmanager%2Fde.foobar.xxx-1.0.0-SNAPSHOT]
> >     Uploading: 
> > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-]
> > 1.0.0-SNAPSHOT=true[https://deref-
> > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw
> > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-
> > SNAPSHOT%26update%3Dtrue]
> >     3534/82321 KB
> >     Uploading: 
> > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-]
> > 1.0.0-SNAPSHOT=true[https://deref-
> > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw
> > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-
> > SNAPSHOT%26update%3Dtrue]
> >     3504/82321 KB
> >     Uploading: 
> > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-]
> > 1.0.0-SNAPSHOT=true[https://deref-
> > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw
> > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-
> > SNAPSHOT%26update%3Dtrue]
> >     3684/82321 KB
> >     Uploading: 
> > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-]
> > 1.0.0-SNAPSHOT=true[https://deref-
> > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw
> > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-
> > SNAPSHOT%26update%3Dtrue]
> >     3474/82321 KB
> >
> > The redeployment failed. I checked the free space and there are about 4
> > gigabyte free on the device.
> >
> > I already checked the upload-size in manager/WEB-INF/web.xml I already
> > checked the ip-disclosure in manager/META-INF/context.xml I already checked
> > the connectionTimeout in the http and https connector.
> > I already checked the username and password.
> > I already checked the roles.
> >
> > It have worked successfully until a few days. I changed nothing.
> >
> > Any ideas? (I do not like to update to a new tomcat-version)
> >
> > Kind regards
> >  Peter Rader
> > -- 
> 
> Could you check the tomcat logs?
> Under normal circumstances there should be some information to track down the 
> issue.
> Check all the log files according to the timestamp and post snippets, if you 
> find something related.
> 
> Greetings,
> Thomas
> 
> 

I checked the Tomcat-logs using enabled logging I saw:

02-May-2023 11:56:44.656 FINE [http-nio-80-exec-4] 
org.apache.catalina.realm.RealmBase.hasResourcePermission Role found:  
manager-script
02-May-2023 11:56:44.657 FINE [http-nio-80-exec-4] 
org.apache.catalina.authenticator.AuthenticatorBase.invoke Successfully passed 
all security constraints
02-May-2023 11:56:44.657 FINER [http-nio-80-exec-4] 
org.apache.catalina.core.StandardWrapper.allocate   Returning non-STM instance
02-May-2023 11:56:44.657 INFO [http-nio-80-exec-4] 
org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web 
application 'de.foobar.xxx-1.0.0-SNAPSHOT'
02-May-2023 11:56:44.814 FINE 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] 
org.apache.catalina.startup.HostConfig.checkResources Checking context[] 
redeploy resource /usr/local/share/apache-tomcat-8.5.50/webapps/ROOT.war
02-May-2023 11:56:44.814 FINE 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] 
org.apache.catalina.startup.HostConfig.checkResources Checking context[] 
redeploy resource /usr/local/share/apache-tomcat-8.5.50/webapps/ROOT
(last two messages are repeated 50 times the different applications)

As you can see, the authentication completed successfully.


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

Maven tomcat7:redeploy upload reset/retry

[Peter Rader]

Hi Folks,
 
I am running a tomcat 8.5.50.
 
I try to upload a webapp using maven-tomcat7-plugin.
 
It worked very good for a couple of years. I did nothing new to the 
configuration.
 
Then I see broken pipes during build:
 

    [INFO] Deploying war to 
http://www.foobar.de/manager/de.foobar.xxx-1.0.0-SNAPSHOT[https://deref-gmx.net/mail/client/1mSXrDjDU9k/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Fde.foobar.xxx-1.0.0-SNAPSHOT]
  
    Uploading: 
http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue]
    3534/82321 KB   
    Uploading: 
http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue]
    3504/82321 KB   
    Uploading: 
http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue]
    3684/82321 KB   
    Uploading: 
http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue]
    3474/82321 KB   
 
The redeployment failed. I checked the free space and there are about 4 
gigabyte free on the device.
 
I already checked the upload-size in manager/WEB-INF/web.xml
I already checked the ip-disclosure in manager/META-INF/context.xml
I already checked the connectionTimeout in the http and https connector.
I already checked the username and password.
I already checked the roles.
 
It have worked successfully until a few days. I changed nothing.
 
Any ideas? (I do not like to update to a new tomcat-version)
 
Kind regards
 Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 6 29 33 29 6
Fax: 0049 (0)30 / 6 29 33 29 6
Handy: 0049 (0)176 / 87 521 576
Handy: 0049 (0)176 / 47 876 303

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

Re: OT: hsts in Tomcat 9.0.73

[Peter Kreuser]

Jon,



Peter Kreuser
Liebknechtstr. 83
63303 Dreieich-Sprendlingen
phone: +49 6103 9880863
fax: +49 6103 9886215
mobile: +49 172 6649346
email: pe...@kreuser.name
web: www.kreuser.name
key: http://www.kreuser.name/PGP_Public_Key.txt
smime: http://www.kreuser.name/SMIME.cer
> Am 24.04.2023 um 15:39 schrieb jonmcalexan...@wellsfargo.com.invalid:
> 
> Thank you for all the good insights Olaf. I am like you, I prefer to put a 
> reverse proxy in front of my Tomcat instances as well. Unfortunately it is 
> Qualsys that is calling this particular system out, so have to figure out how 
> best to fix it.

should it always be behind the reverse proxy and not available to the public?

Peter

> 
> Thanks again.
> 
> 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: Olaf Kock 
>> Sent: Saturday, April 22, 2023 2:14 AM
>> To: users@tomcat.apache.org
>> Subject: Re: OT: hsts in Tomcat 9.0.73
>> 
>> 
>>> Am 22.04.23 um 00:48 schrieb jonmcalexan...@wellsfargo.com.INVALID:
>>> Thanks Peter,
>>> 
>>> I still do not see the hsts header. I'm wondering if this is causing it.
>>> 
>>> SSL certificate verify result: self signed certificate in certificate chain 
>>> (19),
>> continuing anyway.
>>> 
>>> I don't know why it's complaining as the certificate for Tomcat is not a 
>>> self-
>> signed certificate.
>> 
>> That's a good guess: Anything self-signed is a problem for HSTS (though only
>> curl might see it as that, depending on the root certificate store it uses
>> compared to your browser). However, somehow I'd expect the server to be
>> ignorant to the level of trust that the client has and send the header 
>> anyway.
>> 
>> Another aspect to dig into is the explicit nonstandard port number. I didn't
>> fully parse the RFC for it, but there are several statements on explicit, 
>> implicit
>> ports and how they're mapped.
>> 
>> In the end, it might be worth hitting the Tomcat filter in a debugger, or
>> inspecting the source - to see if any conditional branches in an unexpected
>> fashion, if a different filter than the expected one is hitting, or if the 
>> URL
>> doesn't match.
>> 
>> Yet one more option: Set some nonstandard header, where no assumption
>> can be made in any server- or client-side code, and see if it gets through. 
>> This
>> way you know that you're hitting the expected filter
>> 
>> I'm typically lazy in all of this setup, as I defer HTTPS/HSTS to a reverse 
>> proxy
>> (and I'm only setting up demo systems), so I can only make wild guesses.
>> 
>> Olaf
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> ТÐÐ¥FòVç7V'67&–ÂRÖÖ–âW6W'2×Vç7V'67&–FöÖ6Bæ6†Ræ÷Фf÷"FF—F–öæÂ6öÖÖæG2ÂRÖÖ–âW6W'2Ö†VÇFöÖ6Bæ6†Ræ÷Ð
>  

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

Re: OT: hsts in Tomcat 9.0.73

[Peter Kreuser]

Any more details on the request?

Are you hitting an error 400? Like with ip address on a name based host?

That is handled prior to the filter and so you don't see the header!

Peter

> Am 20.04.2023 um 22:40 schrieb jonmcalexan...@wellsfargo.com.invalid:
> 
> Hellow again.
> 
> I hae another app team that is getting hit with a QID 11827 stating that the 
> hsts Security header is missing. We have reviewed the web.xml and the 
> appropriate section and filter are present. hstsEnabled is set to true. 
> Performing a curl aganst the site does NOT show the hsts STRICT header.
> 
> WEB.XML
> 
> -
> httpHeaderSecurity
> org.apache.catalina.filters.HttpHeaderSecurityFilter
> true
> 
> 
> -
> antiClickJackingOption
> SAMEORIGIN
> 
> 
> -
> hstsEnabled
> true
> 
> 
> 
> -
> hstsMaxAgeSeconds
> 31536000
> 
> 
> 
> -
> hstsIncludeSubDomains
> true
> 
> 
> 
> 
> -
> httpHeaderSecurity
> /*
> REQUEST
> 
> 
> 
> Thank you,
> 
> 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

Aw: Tomcat/Java app timezone radomly changes during operation.

[Peter Rader]

Hi David,

is it a moving server? We had similar issues on a airborn server crossing 
nation-borders rapidly.

10 minutes is unusual. The lowest timezone-change is 15 minutes afaik.

Kind regards

>
> Hi all,
>
> I've experienced an issue since the morning of the 21st that I'm
> hoping to get some direction on for where to look.
>
> An app uses the date/time to set a timeout for a password reset.
> This had been working fine for years and suddenly it failed. A restart of
> tomcat allowed it to work for a day, then 12 hours, then 5 hours, then 1 hr
> and now is averaging a 10 minute or so working duration between tomcat
> restarts.
>
> Changing the logging in the app showed that the issue is due to it
> sending UTC to the DB while it is broken. Restarting Tomcat results in CDT
> being sent for a while until randomly it switches again.
>
> RHEL 7.9, jvm 1.8.0_231-b11, Tomcat 9.0.29
> ntp is on, chrony is syncing, Java states correct time when queried
> however unsure if it's JDK or JRE when targeted. OS time is good.
>
> When I redeploy the app, log timestamps for the app are in UTC as well
> until restarting tomcat. During the issue the log timestamp remains in
> CDT as expected, even though values passed are UTC.
>
> I have explicitly defined the timezone in setenv.sh with no change in
> behavior.
>
> Any thoughts as what to investigate are greatly appreciated.
>
> Thanks,
> David

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

Re: Tomcat 10.1.1 error starting

[Peter Kreuser]

Jon,

 

> Am 20.10.2022 um 18:57 schrieb jonmcalexan...@wellsfargo.com.invalid:
> 
> Good morning,
> 
> I am getting the following error when trying to start a very generic setup of 
> Tomcat 10.1.1 on Windows Server 2019.
> 
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
> org/apache/catalina/startup/Bootstrap has been compiled by a more recent 
> version of the Java Runtime (class file version 55.0), this version of the 
> Java Runtime only recognizes class file versions up to 52.0
>at

Looks like you are running Tomcat on an older Java, that the app was compiled 
with...

Need to lookup the exact class versions, but like:

Compiled with jdk13 and running on java 11.

HTH

Peter

> java.lang.ClassLoader.defineClass1(Native Method)
>at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
>at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
>at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>at java.security.AccessController.doPrivileged(Native Method)
>at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>at 
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)
> 
> Is there a minimum version of Java 8 that is required?
> 
> 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

Re: Simple SSL question

[Peter Kreuser]

Jon and Chris,


> Am 11.08.2022 um 19:33 schrieb 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.
>>> 

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.
That would take away the fear to get going. In another thread I said, that it 
may be a lot of work to migrate a lot of tomcat instances. But I guess most 
people would only need a single SSLHostConfig  to add to their one connector...

Peter
>>> -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
>>>>>&g

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

[Peter Kreuser]

James,

the most recent connector attribute is "protocols". The documentation is a bit 
vague on this saying there is an overlap between the two, yet I don't know if 
the overlap is there if protocols is unset and defaults to "all"
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support

Peter

> Am 10.08.2022 um 00:15 schrieb James H. H. Lampert 
> :
> 
> I think this may have come up before, but I don't recall how it was resolved.
> 
> On customer box #1, I have:
>  address=""
>   maxThreads="400" SSLEnabled="true" scheme="https" secure="true"
>   keystoreFile="/tomcat/wttomcat.ks" keyAlias=""
> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
>   clientAuth="false" sslProtocol="TLSv1.2" /> 
> 
> and an SSLLabs scan shows it accepting only TLSv1.2, as it should.
> 
> But on customer box #2, I have:
> 
>maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>   keystoreFile="/tomcat/wttomcat.ks" keyAlias=""
>   clientAuth="false" sslProtocol="TLSv1.2" />
> 
> and an SSLLabs scan shows it accepting TLSv1.0, TLSv1.1, and TLSv1.2.
> 
> What could be wrong here? I vaguely recall seeing something like this before.
> 
> --
> JHHL
> 
> -
> 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

[Peter Chamberlain]

ngs 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 "enabled protocols" to "TLSv1, TLSv1.1,
> TLSv1.2, TLSv1.3" -- however that's done in that dinosaur of a Tomcat
> version. It might be enabledProtocols="..." if might be
> SSLProtocols="..." and it might have a lot to do with whether or not
> APR/native is being used, too.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Could this be an issue with the java jdk security disabled algorithms.
Later versions of jdk 8 disabled TLSv1 and TLSv1.1 by default, and you have
to change the jre/jdk conf/security/java.security file to fix it for older
use cases.
-- 



*Peter Chamberlain*

Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Peter Chiu]

This is what I am using. Hope this helps.

https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html

On Thu, Apr 28, 2022 at 3:11 PM Kaushal Shriyan 
wrote:

> Hi,
>
> I am running the tomcat version 9.0.56 on CentOS Linux release 7.9.2009
> (Core) and trying to configure HTTP Strict Transport Security (HSTS)
> using /opt/tomcat9/conf/web.xml
>
> # ./version.sh
> Using CATALINA_BASE:   /opt/tomcat9
> Using CATALINA_HOME:   /opt/tomcat9
> Using CATALINA_TMPDIR: /opt/tomcat9/temp
> Using JRE_HOME:
>  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-1.el7_9.x86_64
> Using CLASSPATH:
> /opt/tomcat9/bin/bootstrap.jar:/opt/tomcat9/bin/tomcat-juli.jar
> Using CATALINA_OPTS:
> Server version: Apache Tomcat/9.0.56
> Server built:   Dec 2 2021 14:30:07 UTC
> Server number:  9.0.56.0
> OS Name:Linux
> OS Version: 3.10.0-1160.62.1.el7.x86_64
> Architecture:   amd64
> JVM Version:1.8.0_322-b06
> JVM Vendor: Red Hat, Inc.
> # cat /etc/redhat-release
> CentOS Linux release 7.9.2009 (Core)
> #
>
>
> > */opt/tomcat9/conf/web.xml*
> >   httpHeaderSecurity
> >
> >
> org.apache.catalina.filters.HttpHeaderSecurityFilter
> >   true
> >   
> > hstsEnabled
> > true
> >   
> >   
> > hstsMaxAgeSeconds
> > 31536000
> >   
> >   
> > hstsIncludeSubDomains
> > true
> >   
> > 
> > 
> >   httpHeaderSecurity
> >   /*
> >   REQUEST
> > 
>
>
> When I scan the https://tomcatURL FQDN using
> https://www.ssllabs.com/ssltest/ I do not see the Strict Transport
> Security
> response header. Please guide me. Thanks in advance
>
> Best Regards,
>
> Kaushal
>

Re: [OT] Getting TLS handshake details

[Peter Kreuser]

Chris,

> Am 14.04.2022 um 23:21 schrieb Christopher Schultz 
> :
> 
> Peter,
> 
>> On 4/14/22 03:45, Peter Kreuser wrote:
>> Chris,
>>>> Am 13.04.2022 um 21:37 schrieb Christopher Schultz 
>>>> :
>>> All,
>>> I asked this question a few years ago on SO and I didn't really get an 
>>> answer:
>>> https://stackoverflow.com/questions/39374024/determine-diffie-hellman-parameters-length-for-a-tls-handshake-in-java
>>> Does anyone know if it's possible to get the DHE key-exchange parameters 
>>> during the TLS handshake using just SSLSocket on the client end? I'm trying 
>>> to detect when the server is using "weak" DH key lengths like <= 1024 bits.
>>> (I'm also curious as to why my ssltest tool[1] is unable to connect to a 
>>> server which is allowing ADH-AES128-GCM-SHA256 aka 
>>> TLS_DH_anon_WITH_AES_128_GCM_SHA256 ; I suspect it has something to do with 
>>> my JVMs unwillingness to use 1024-bit DHE for the handshake, and I can't 
>>> figure out how to turn it off. SSLLabs and sslscan both report this cipher 
>>> suite as being "enabled" on the server, but my tool reports that the 
>>> handshake failed, which usually implies that the cipher suite is disabled.)
>> Is your question how to detect this in code? Or specifically in Java?
> 
> Specifically in Java, and without any cooperation from the server e.g. 
> returning the details in some kind of HTTP header. I expect to perform a TLS 
> handshake only and then terminate the socket connection.
> 
>> Anyways Do you know testssl.sh?
> 
> I think that just executes openssl in a loop, no?

Not quite. It sets openssl params for specific tls testcases and verifies 
output from the tls response or certs.
Plus it has test case for known dhparams.

However that info may not be accessible from java, as Thomas said.

Peter
>> If I want to know how to handle a specific tls problem I check in
>> Dirk's code and start from there...
> -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: [OT] Getting TLS handshake details

[Peter Kreuser]

Chris,

> Am 13.04.2022 um 21:37 schrieb Christopher Schultz 
> :
> 
> All,
> 
> I asked this question a few years ago on SO and I didn't really get an answer:
> https://stackoverflow.com/questions/39374024/determine-diffie-hellman-parameters-length-for-a-tls-handshake-in-java
> 
> Does anyone know if it's possible to get the DHE key-exchange parameters 
> during the TLS handshake using just SSLSocket on the client end? I'm trying 
> to detect when the server is using "weak" DH key lengths like <= 1024 bits.
> 
> (I'm also curious as to why my ssltest tool[1] is unable to connect to a 
> server which is allowing ADH-AES128-GCM-SHA256 aka 
> TLS_DH_anon_WITH_AES_128_GCM_SHA256 ; I suspect it has something to do with 
> my JVMs unwillingness to use 1024-bit DHE for the handshake, and I can't 
> figure out how to turn it off. SSLLabs and sslscan both report this cipher 
> suite as being "enabled" on the server, but my tool reports that the 
> handshake failed, which usually implies that the cipher suite is disabled.)
> 
Is your question how to detect this in code? Or specifically in Java? 

Anyways Do you know testssl.sh? If I want to know how to handle a specific tls 
problem I check in Dirk's code and start from there...

Peter

> Thanks,
> -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

Aw: PostConstruct annotation in a filter since version 9.0.60

[Peter Rader]

PostConstruct is for dependency-injection. A vanilla tomcat does no dependency 
injection. Can you confirm you have a vanilla tomcat?
 
Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 6 29 33 29 6
Fax: 0049 (0)30 / 6 29 33 29 6
Handy: 0049 (0)176 / 87 521 576
Handy: 0049 (0)176 / 47 876 303
 
 

Gesendet: Freitag, 01. April 2022 um 23:02 Uhr
Von: "Cherio" 
An: users@tomcat.apache.org
Betreff: PostConstruct annotation in a filter since version 9.0.60
I observed an announced change in behavior in version 9.0.60 (and later).

My application has a Spring class loaded as a javax.servlet.Filter. It has
a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59
the annotation was handled by Spring. Starting with Tomcat 9.0.60 behavior
changed. Now Tomcat attempts to take action on that method. The attempt
fails with "java.lang.IllegalArgumentException: Invalid
javax.annotation.PostConstruct annotation" exception and that results in
the whole application failing to start.

I use PostConstruct in other Spring modules but it looks like Tomcat cares
only about classes it deals with directly.

I do not see this change documented anywhere so I assume this may be a
regression or an undocumented bug fix or feature.

Does anyone have more information about this?
Thanks!

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

Re: Apex SSO

[Peter Chiu]

Hi Chris,

To implement APEX SSO, that requires NO change to tomcat. That is why I
tried not to post here.

Here is the blog for starters. https://fuzziebrain.com/content/id/1908/

If tomcat is behind a proxy (apache or nginx), we might need to change a
setting in server.xml to return the real hostname.

Hope this helps.

On Fri, Mar 25, 2022 at 8:54 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Peter,
>
> On 3/24/22 14:54, Peter Chiu wrote:
> > I will email you directly. For the group knowledge, there is nothing
> > special you need to do on Tomcat if it is not behind a proxy.
>
> Please post to the mailing list. It's not at all clear to me how you'd
> get Oracle APEX to deliver authentication information to Tomcat.
>
> Presumably, that's what Rupali is trying to accomplish and it would be
> helpful for the whole community to post back.
>
> -chris
>
> > On Thu, Mar 24, 2022 at 1:51 PM rupali singh 
> > wrote:
> >
> >> Hi Peter,
> >>
> >> Are u using apache web server with tomcat or its only tomcat  .
> >> if possible can you please share steps for azure AD with me on
> >> rupali.r.si...@gmail.com
> >>
> >>
> >>
> >> On Thu, 24 Mar 2022 at 21:21, Peter Chiu  wrote:
> >>
> >>> I have a working APEX SSO against Azure AD or On-Permise AD.
> >>>
> >>> On Thu, Mar 24, 2022 at 1:13 PM rupali singh  >
> >>> wrote:
> >>>
> >>>> HI Team,
> >>>>
> >>>> We are using apex 21.1 with tomcat 9.54.
> >>>> we want to implement SSO for application deployed in Apex  with IDCS
> >>>> reference URL :
> >>>>
> >>>>
> >>>
> >>
> https://www.ateam-oracle.com/post/integrating-apex-with-oracle-identity-cloud-service
> >>>>
> >>>> but apex is not at all redirecting to IDCS URL and as per Oracle issue
> >> is
> >>>> with tomcat .
> >>>>
> >>>> anyone successfully implemented APEX SSO( webserver : apache tomcat)
> >>> with
> >>>> Oracle IDCS
> >>>> or  APEX SSO( webserver : apache tomcat)  with Microsoft Azure AD.
> >>>> can you please assist us with steps.
> >>>>
> >>>> --
> >>>> Thanks and Regards,
> >>>> Rupali
> >>>>
> >>>
> >>
> >>
> >> --
> >> Thanks and Regards,
> >> Rupali
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: tomcat 9.50 - rewrite rule question

[Peter Chiu]

Application builder->Your application->Shared Components->Application
Definition Attributes->Properties->Friendly URLs

On Thu, Mar 24, 2022 at 3:25 PM rupali singh 
wrote:

> Hi,
>
> How we can enable friendly url in apex?
>
>
>
> On Fri, Mar 25, 2022, 12:48 AM Peter Chiu  wrote:
>
> > Have you consider doing the following
> > 1. custom URL/domain, and
> > 2. enable Friendly URLs in APEX
> >
> > On Thu, Mar 24, 2022 at 3:09 PM Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> > >
> > > Am 24.03.22 um 19:23 schrieb rupali singh:
> > >
> > > hi,
> > >
> > > yes context name is apex.
> > >
> > > Good to know.
> > >
> > >  https://xyz.ae/apex/f?p=1001 <https://xyz.com/apex/f?p=1001> <
> > https://xyz.com/apex/f?p=1001>   tohttps://xyz.ae/apex/myapp <
> > https://xyz.com/aorx/myapp> <https://xyz.com/aorx/myapp>
> > >
> > > we dont want to change xyz.ae that will name remain as it is , we want
> > to
> > > change f?p=1001 <https://xyz.com/apex/f?p=1001> <
> > https://xyz.com/apex/f?p=1001> to myapp
> > >
> > > Sorry, I don't understand, what you meant by the above.
> > >
> > > I suspect, that you wanted to show, what the user enters into the
> browser
> > > and where the application listens. But it doesn't really makes sense to
> > me.
> > >
> > > Reading your first mail again, I think, that you have a loadbalancer
> that
> > > listens on xyz.ae and that proxies to xyz.com (you mentioned port
> 8080,
> > > which is left out in all your examples). Is that right?
> > >
> > > Apart from that, I wanted to know, what you tried on a technical level.
> > > Have you tried the curl command that I gave as an example?
> > >
> > > Felix
> > >
> > > On Wed, 23 Mar 2022 at 19:23, Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> > >
> > >
> > > Am 23. März 2022 12:14:25 MEZ schrieb rupali singh <
> > rupali.r.si...@gmail.com>:
> > >
> > > Hi Chris,
> > >
> > > I already tried with fully qualified name but its not working
> > >
> > > Can you be more specific, what you tried?
> > >
> > > Is Chris right and your context name is apex?
> > >
> > > Felix
> > >
> > > On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> > >
> > >
> > > All,
> > >
> > > On 3/21/22 10:19, Felix Schumacher wrote:
> > >
> > > Am 21.03.22 um 06:39 schrieb rupali singh:
> > >
> > > Hi Felix,
> > >
> > > location of context.xml file is
> > >
> > >   cat context.xml| grep RewriteValve
> > >   > >
> > > className="org.apache.catalina.valves.rewrite.RewriteValve"
> > >
> > > />
> > >
> > >   pwd
> > > /opt/tomcat/apache-tomcat-9.0.54/instance/conf
> > >
> > > That context.xml is thought to be a default template for all installed
> > > webapps. It will work, but remember, that every installed webapp will
> > > get its own copy of a rewrite valve.
> > >
> > > +1
> > >
> > > This is probably the problem.
> > >
> > >
> > > more
> > >
> > >
> > >
> >
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
> > >
> > > RewriteCond %{QUERY_STRING} p=10001
> > > RewriteRule ^/apex/f$ /apex/myapp [R,L]
> > >
> > > I think you want:
> > >
> > > RewriteCond %{QUERY_STRING} p=10001
> > > RewriteRule ^/f$ /myapp [R,L]
> > >
> > > The prefix /apex is already a part of the context-path and should be
> > > removed from the URL patterns being matched. If you want to redirect to
> > > another web application, you need a fully-qualified redirect like this:
> > >
> > > RewriteCond %{QUERY_STRING} p=10001
> > > RewriteRule ^/f$ https://www.google.com/ [R,L]
> > >
> > > -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: Fwd: tomcat 9.50 - rewrite rule question

[Peter Chiu]

Have you consider doing the following
1. custom URL/domain, and
2. enable Friendly URLs in APEX

On Thu, Mar 24, 2022 at 3:09 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 24.03.22 um 19:23 schrieb rupali singh:
>
> hi,
>
> yes context name is apex.
>
> Good to know.
>
>  https://xyz.ae/apex/f?p=1001  
>    tohttps://xyz.ae/apex/myapp 
>  
>
> we dont want to change xyz.ae that will name remain as it is , we want to
> change f?p=1001  
>  to myapp
>
> Sorry, I don't understand, what you meant by the above.
>
> I suspect, that you wanted to show, what the user enters into the browser
> and where the application listens. But it doesn't really makes sense to me.
>
> Reading your first mail again, I think, that you have a loadbalancer that
> listens on xyz.ae and that proxies to xyz.com (you mentioned port 8080,
> which is left out in all your examples). Is that right?
>
> Apart from that, I wanted to know, what you tried on a technical level.
> Have you tried the curl command that I gave as an example?
>
> Felix
>
> On Wed, 23 Mar 2022 at 19:23, Felix Schumacher 
>  wrote:
>
>
> Am 23. März 2022 12:14:25 MEZ schrieb rupali singh :
>
> Hi Chris,
>
> I already tried with fully qualified name but its not working
>
> Can you be more specific, what you tried?
>
> Is Chris right and your context name is apex?
>
> Felix
>
> On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz 
>  wrote:
>
>
> All,
>
> On 3/21/22 10:19, Felix Schumacher wrote:
>
> Am 21.03.22 um 06:39 schrieb rupali singh:
>
> Hi Felix,
>
> location of context.xml file is
>
>   cat context.xml| grep RewriteValve
>  
> className="org.apache.catalina.valves.rewrite.RewriteValve"
>
> />
>
>   pwd
> /opt/tomcat/apache-tomcat-9.0.54/instance/conf
>
> That context.xml is thought to be a default template for all installed
> webapps. It will work, but remember, that every installed webapp will
> get its own copy of a rewrite valve.
>
> +1
>
> This is probably the problem.
>
>
> more
>
>
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/apex/f$ /apex/myapp [R,L]
>
> I think you want:
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/f$ /myapp [R,L]
>
> The prefix /apex is already a part of the context-path and should be
> removed from the URL patterns being matched. If you want to redirect to
> another web application, you need a fully-qualified redirect like this:
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/f$ https://www.google.com/ [R,L]
>
> -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: Apex SSO

[Peter Chiu]

I will email you directly. For the group knowledge, there is nothing
special you need to do on Tomcat if it is not behind a proxy.

On Thu, Mar 24, 2022 at 1:51 PM rupali singh 
wrote:

> Hi Peter,
>
> Are u using apache web server with tomcat or its only tomcat  .
> if possible can you please share steps for azure AD with me on
> rupali.r.si...@gmail.com
>
>
>
> On Thu, 24 Mar 2022 at 21:21, Peter Chiu  wrote:
>
> > I have a working APEX SSO against Azure AD or On-Permise AD.
> >
> > On Thu, Mar 24, 2022 at 1:13 PM rupali singh 
> > wrote:
> >
> > > HI Team,
> > >
> > > We are using apex 21.1 with tomcat 9.54.
> > > we want to implement SSO for application deployed in Apex  with IDCS
> > > reference URL :
> > >
> > >
> >
> https://www.ateam-oracle.com/post/integrating-apex-with-oracle-identity-cloud-service
> > >
> > > but apex is not at all redirecting to IDCS URL and as per Oracle issue
> is
> > > with tomcat .
> > >
> > > anyone successfully implemented APEX SSO( webserver : apache tomcat)
> > with
> > > Oracle IDCS
> > > or  APEX SSO( webserver : apache tomcat)  with Microsoft Azure AD.
> > > can you please assist us with steps.
> > >
> > > --
> > > Thanks and Regards,
> > > Rupali
> > >
> >
>
>
> --
> Thanks and Regards,
> Rupali
>

Re: Apex SSO

[Peter Chiu]

I have a working APEX SSO against Azure AD or On-Permise AD.

On Thu, Mar 24, 2022 at 1:13 PM rupali singh 
wrote:

> HI Team,
>
> We are using apex 21.1 with tomcat 9.54.
> we want to implement SSO for application deployed in Apex  with IDCS
> reference URL :
>
> https://www.ateam-oracle.com/post/integrating-apex-with-oracle-identity-cloud-service
>
> but apex is not at all redirecting to IDCS URL and as per Oracle issue is
> with tomcat .
>
> anyone successfully implemented APEX SSO( webserver : apache tomcat)  with
> Oracle IDCS
> or  APEX SSO( webserver : apache tomcat)  with Microsoft Azure AD.
> can you please assist us with steps.
>
> --
> Thanks and Regards,
> Rupali
>

PGP signature on the latest Tomcat release

[Gershkovich, Peter]

Hi everyone,
I am trying to verify the PGP signature on the latest Tomcat 9 release (9.0.56) 
but unable to obtain it from a suggested key server (see command logs below).
Could you please clarify where to obtain and how to verify the authenticity of 
that particular signature.
Thanks in advance!
Peter


gpg --verify apache-tomcat-9.0.56.tar.gz.asc.txt apache-tomcat-9.0.56.tar.gz
gpg: Signature made Thu Dec  2 09:31:59 2021 EST using RSA key ID 359E722B
gpg: requesting key 359E722B from hkps server 
hkps.pool.sks-keyservers.net<http://hkps.pool.sks-keyservers.net>
gpgkeys: HTTP fetch error 6: Couldn't resolve host 
'hkps.pool.sks-keyservers.net<http://hkps.pool.sks-keyservers.net>'
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: keyserver helper internal error
gpg: keyserver communications error: General error
gpg: Can't check signature: No public key



gpg --keyserver pgpkeys.mit.edu<http://pgpkeys.mit.edu> --recv-key 359E722B
gpg: requesting key 359E722B from hkp server 
pgpkeys.mit.edu<http://pgpkeys.mit.edu>
gpgkeys: key 359E722B can't be retrieved
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: keyserver helper general error
gpg: keyserver communications error: Invalid public key algorithm
gpg: keyserver receive failed: Invalid public key algorithm

Thanks,
Peter

Aw: Tomcat - Deployment

[Peter Rader]

Dear Admin Priyanka,

unfortunately the source-code your developers wrote might be invalid. The error 
might occour in a Thread calling the productExclusionRegistryDao-bean (Maybe 
the ProductExclusionRegistryDao.java source-file) in the method used to 
initialize the application.

In order to solve the bug your developers are in charge IMO. Please provide the 
stacktrace to your developers in order to solve the problem.
 
Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 6 29 33 29 6
Fax: 0049 (0)30 / 6 29 33 29 6
Handy: 0049 (0)176 / 87 521 576
Handy: 0049 (0)176 / 47 876 303
 
 

Gesendet: Sonntag, 07. November 2021 um 16:04 Uhr
Von: "Kumawat, Priyanka" 
An: "Tomcat Users List" 
Betreff: Tomcat - Deployment
Hi Team ,

I have did a Tomcat application deployment on Production region and copied the 
WAR file to the webapps location of tomcat , we normally do this change monthly 
, tested on Stage env after successful it will go to the production env.

But This time we have encountered an issue- after the deployment completes - 
The logs was giving the below error -

The client reports there is no issue with the WAR file as it was deployed 
successfully for lower env - stage , they have asked to deploy one more time on 
prod , this time it worked successful. I need your help to determine wat went 
wrong during the first implementation while the same steps were performed 
during both the times.

2021-11-07 05:05:58,277 ERROR org.springframework.web.context.ContextLoader:350 
- Context initialization failed
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'fleetTireFinderRestController': Unsatisfied dependency 
expressed through field 'fleetOrderService'; nested exception is 
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'fleetOrderServiceImpl': Unsatisfied dependency 
expressed through field 'catalogHelper'; nested exception is 
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'catalogHelperDao': Unsatisfied dependency expressed 
through field 'productValidationDao'; nested exception is 
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'productValidationDao': Unsatisfied dependency 
expressed through field 'tireFinder'; nested exception is 
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'tireFinderDao': Unsatisfied dependency expressed 
through field 'prodExclusions'; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'productExclusionRegistryDao': Invocation of init method failed; 
nested exception is org.springframework.jdbc.UncategorizedSQLException: 
StatementCallback; uncategorized SQLException for SQL [select * from 
excl_dc_ph]; SQL state [null]; error code [-4470]; 
[jcc][t4][10120][10898][4.9.78] Invalid operation: result set is closed. 
ERRORCODE=-4470, SQLSTATE=null; nested exception is 
com.ibm.db2.jcc.am.SqlException: [jcc][t4][10120][10898][4.9.78] Invalid 
operation: result set is closed. ERRORCODE=-4470, SQLSTATE=null
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: 
Error creating bean with name 'fleetOrderServiceImpl': Unsatisfied dependency 
expressed through field 'catalogHelper'; nested exception is 
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'catalogHelperDao': Unsatisfied dependency expressed 
through field 'productValidationDao'; nested exception is 
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'productValidationDao': Unsatisfied dependency 
expressed through field 'tireFinder'; nested exception is 
org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
creating bean with name 'tireFinderDao': Unsatisfied dependency expressed 
through field 'prodExclusions'; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'productExclusionRegistryDao': Invocation of init method failed; 
nested exception is org.springframework.jdbc.UncategorizedSQLException: 
StatementCallback; uncategorized SQLException for SQL [select * from 
excl_dc_ph]; SQL state [null]; error code [-4470]; 
[jcc][t4][10120][10898][4.9.78] Invalid operation: result set is closed. 
ERRORCODE=-4470, SQLSTATE=null; nested exception is 
com.ibm.db2.jcc.am.SqlException: [jcc][t4][10120][10898][4.9.78] Invalid 
operation: result set is closed. ERRORCODE=-4470, SQLSTATE=null


Thanks & Regards,

Priyanka Kumawat | Middleware Admin
T +91.7879364483
EMail - priyanka.kuma...@dxc.com<mailto:priyanka.kuma...@dxc.com>
DL - 
ams-leveraged-webadmin-offsh...@dxc.com<mailto:ams-leveraged-webadmin-offsh...@d

Aw: Re: tomcat hangs

[Peter Rader]

Chris,

> Gesendet: Donnerstag, 09. September 2021 um 22:15 Uhr
> Von: "Christopher Schultz" 
> An: users@tomcat.apache.org
> Betreff: Re: Aw: tomcat hangs
> Peter,
>
> On 9/9/21 08:21, Peter Rader wrote:
> > I might noticed a simmilar issue: I ran the JVM in a linux OS on a VM
> > (in virtualbox btw). The jdk for some reason request a random number.
> > The JDK asks the LinuxOS for a new random number (maybe in the hope
> > to use a hardware-based TRNG). Since this linux in virtualbox is
> > not-so low-level the random number is generated due to RAM
> > squarenumbers, because no memory is changed - no new random number
> > has been generated and we get a OS-based softlock.
>
> WHAT?
>
> -chris

YES, id reported this many years ago 
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4952383

There is a workaround (from comments): set java.security.egd=file:/dev/urandom

Regards

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

Aw: tomcat hangs

[Peter Rader]

I might noticed a simmilar issue: I ran the JVM in a linux OS on a VM (in 
virtualbox btw). The jdk for some reason request a random number. The JDK asks 
the LinuxOS for a new random number (maybe in the hope to use a hardware-based 
TRNG). Since this linux in virtualbox is not-so low-level the random number is 
generated due to RAM squarenumbers, because no memory is changed - no new 
random number has been generated and we get a OS-based softlock.

Regards


> HiI use apache tomcat 8.0.32 and oracle-jdk-8u66 and redhat 6.After working 
> with the system for a few hours
> and the load on the system increases, suddenly the tomcat hangs and no logs 
> are printed and it is not possible
> to connect via jvisualvm and I can not get any dump and I have to reload 
> Tomcat.I have increased maxthreads
> and use the HttpProtocol protocol.Please suggest a way to fix the my tomact.

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

Re: Apache Tomcat 9 | Tomcat starting issue

[Peter Chamberlain]

On Sun, 22 Aug 2021 at 08:55, Piyush Sharma  wrote:
>
> On Fri, Aug 20, 2021 at 10:40 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Piyush,
> >
> > On 8/20/21 06:36, Piyush Sharma wrote:
> > >>
> > >> Hello,
> > >>
> > >> I am using Apache Tomcat 9.0.46 version on docker container.
> > >>
> > >> There is a problem, where the base path was wrongly set by automation
> > >> script due to which it starts for few seconds, listen port 8080 and then
> > >> stop, due to that container exit after sometime.
> > >>
> > >
> > > Now how can we debug such issue, which shows any error / problem in
> > tomcat
> > >> configuration.
> > >>
> > >> I tried with "jpda start" or "debug" options, but that didn't help me.
> > Is
> > >> there any option to debug tomcat related issues or problems.
> > >>
> > >> "catalina.sh configtest" will show any error in xml or properties but
> > will
> > >> not help to debug tomcat startup problem.
> > >>
> > >> *Note:* I am just deploying with the helloworld war file. nothing much
> > in
> > >> code as of now.
> >
> > Maybe just fix your automation script to use the right path?
> >
> > It's hard to understand what the problem is given the information you
> > have presented.
> >
> > -chris
> >
> >
> Thanks Chris
>
> I have removed automation and harded everything and created a new docker
> image.
> Now when I try to start the container, it starts for a few seconds and
> stops (port 8080 listens for a while). Nothing in logs.
>
> $ catalina.sh run  (tried with "jpda start" or "debug" options as well)
> $ ps aux |grep java --> show the process for few seconds
> $ netstat -ntpl |grep 8080 --> shows the port for few seconds
>
> I am wondering if I can debug such issues, when it starts for a few seconds
> and then stops. Is there any memory , config file or any other issues?
>
> Any debug option whether tomcat
>
>
> Thanks
> Piyush

Could it be a clash of port or similar for the shutdown port, or maybe
another port, eg, in server.xml:
Server port="8005"

Best regards, Peter

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

Re: Connector Port Issue

[Peter Kreuser]

Chris,

> Am 05.08.2021 um 18:32 schrieb Rob Sargent :
> 
> 
>>Caused by: java.lang.IllegalArgumentException: No SSLHostConfig 
>> element was found with the hostName [_default_] to match the 
>> defaultSSLHostConfigName for the connector [https-jsse-nio-9443]
>> 
> 

The ssl-Options are not attributes on the connector, but the SSLHostConfig

http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#Common_Attributes

http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support

Peter

> Isn’t that the real issue?
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: Understanding issues with connection refused when redirecting internally

[Peter Chamberlain]

On Mon, 12 Apr 2021, 09:07 Mark Thomas,  wrote:

> On 11/04/2021 11:03, Peter Chamberlain wrote:
>
> 
>
> > I've been investigating this some more, as I'm not convinced nio2 isn't
> > behaving strangely in this case. I think there may of been some sort of
> > reversion as it is much less likely to refuse connections for nio2 in
> > tomcat 9.0.13 when compared to 9.0.14. I'm wondering if it has something
> to
> > do with:
> >
> >   Avoid using a dedicated thread for accept on the NIO2
> connector,
> > it is always less efficient. (remm)
> >
> > And if it is hitting some sort of accept thread starvation case when it
> is
> > fully loaded. In tomcat 9.0.13 I can hit a maxTheads=200 nio2 connector
> > with 5000 jmeter threads and not experience a connection refused, but in
> > 9.0.14 I can't reach 1000 without refused connections. It doesn't seem to
> > be related to forwards or redirects either. If I just sleep for 1500
> > milliseconds for every servlet run and not redirect or forward and it
> > behaves the same.
> > We've been using nio2 in our tomcats exclusively for some time, as we hit
> > an issue with nio in the past (can't remember what it was, it is likely
> > fixed by now I would think), so I guess we're more likely to notice this
> > sort of thing.
>
> I think you are asking the wrong question(s). 200 threads with a 1500ms
> wait means I would expect Tomcat to be processing ~133 requests per
> second. (Assuming you have at least 200 client threads as well). Higher
> numbers of client threads, the timeouts configured on the client, the
> timeouts configured on Tomcat, the accept count etc shouldn't change the
> requests per second results. What will change is the failure scenarios
> you observe - and I think that is what you are seeing here between
> 9.0.13 and 9.0.14. 9.0.13 might be accepting more connections but that
> doesn't mean those connections are being processed faster. Depending on
> timeouts, they might (eventually) get processed or they might timeout.
>
> You might want to try the following:
> - Limit the number of loops to, say, 10 so you get 50,000 requests. Look
> at the response time stats. What is the average? What is the min/max?
> - Repeat the test. Do the results remain consistent?
> - Repeat the test with more loops. Do the results remain consistent?
> - Repeat the test with fewer client threads. At what point do you start
> to get consistent results?
>
> It may well be that changes to Tomcat over time have changed the way
> Tomcat behaves under various (overloaded network) failure scenarios.
>
> My reading of the change that you reference above does mean that Tomcat
> will only accept a new connection over NIO2 when it has a processing
> thread available to process it. That will change the way Tomcat behaves
> when presented with a large spike of new connections. (Significantly)
> increasing the acceptCount (a.k.a. backlog) to more than the number
> connections expected in a single "spike" in 9.0.14 should give 9.0.13
> like behaviour.
>
> HTH,
>
> Mark
>

I understand what you are saying. I'm only actually hitting it with 1000
requests total, and approx 300 are failing with connection refused. This
isn't jus the first run either, so it isn't a jvm warm up issue. I'm
overloading the number of threads (200). But it doesn't really handle that
overloading in the way that might be expected (just delaying processing,
its failing some inside 7 seconds,  even with high accept count, max
connections, and connection timeouts). Essentially we're looking at cases
where we are overloaded for short periods, and trying to cope with that
without a bad customer response. This is for a link server of sorts, so the
result at present is people clicking links get failures, rather than
delays. Obviously we can increase number of threads to mitigate this to
some degree (although that increases resources used),  we're looking at
improving the performance too, and we can spread the load over more servers
if necessary. I'm still concerned this is likely to happen for this
application, so have recommended we switch back to nio instead, as it seems
to cope better with it. There is a difficult balance here with sufficient
performance against coping with ddos attempts, so I understand its not
really a simple area. Just thought you should know that 9.0.14 made it much
worse compared to 9.0.13, in case this query comes up again.
Obviously waiting for a large period of time for link clicks to work is
also undesirable, we are really just looking at worse case scenarios here.

Best regards, Peter.


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

Re: Understanding issues with connection refused when redirecting internally

[Peter Chamberlain]

On Fri, 9 Apr 2021 at 18:12, Peter Chamberlain 
wrote:

>
>
> On Fri, 9 Apr 2021, 14:10 Christopher Schultz, <
> ch...@christopherschultz.net> wrote:
>
>> Peter,
>>
>> On 4/9/21 06:53, Peter Chamberlain wrote:
>> > Hello,
>> > I've been trying to understand the behaviour of tomcat when handling
>> > internal redirects. I'm testing using tomcat 9.0.38. I'm testing using
>> > jdk8 1.8.0_265. My main test cases have been 2 forwards to the same
>> > servlet, and then a response. Or 2 redirects to the same servlet and
>> > then a response. Servlet as follows:
>> >
>> > @WebServlet(loadOnStartup = 1, value = "/")
>> > public class ConnectorLimitServlet extends HttpServlet {
>> >
>> >@Override
>> >protected void doGet(HttpServletRequest req, HttpServletResponse
>> > resp) throws IOException, ServletException {
>> >  int number = Integer.parseInt(req.getParameter("number"));
>> >  // Fake some work done at each stage of processing
>> >  try { Thread.sleep(500); } catch (InterruptedException e) {}
>> >  resp.setContentType("text/plain");
>> >  if (number <= 1) {
>> >resp.getWriter().write("Finished " + req.getServletPath());
>> >return;
>> >  }
>> >  switch (req.getServletPath()) {
>> >case "/redirect":
>> >  resp.sendRedirect(new URL(req.getScheme() + "://" +
>> > req.getServerName() + ":" + req.getServerPort() +
>> >  req.getRequestURI() + "?number=" + (number -
>> 1)).toString());
>> >  return;
>> >case "/forward":
>> >  final String forwardAddress = "/forward?number=" + (number -
>> 1);
>> >
>> getServletContext().getRequestDispatcher(forwardAddress).forward(req,
>> > resp);
>> >  }
>> >}
>> > }
>> >
>> >
>> > It seems that under high load, 1000 threads in jmeter, Tomcat will
>> > refuse some of the connections for nio2 connections but not for nio,
>> > further it seems that these failures happen considerably earlier than
>> > the configuration page would suggest would be the case. The
>> > configuration suggests that if acceptCount is high enough for the
>> > number of connections then they will be queued prior to reaching the
>> > processing threads, so a small number of processing threads can exist
>> > with a queue of connection feeding them, it seems like until
>> > connectionTimeout is reached connections shouldn't be refused, but
>> > that is not what occurs. In fact acceptCount seems to have very little
>> > effect.
>>
>> Are you testing on localhost, or over a real network connection? If a
>> real network, what kind of network? How many JMeter instances vs Tomcat
>> instances?
>>
>>
> Localhost on Windows,  although similar has been seen across the network
> on Linux,  this was an attempt to replicate a live issue in a minimal code
> approach.
>
> > In short, my questions are:
>> > Why is the nio2 connector type worse at this than nio type?
>>
>> Let's table that for now.
>>
>> > Why are connections refused before acceptCount is reached, or
>> > connectionTimeout is reached?
>>
>> How are you measuring the size of the OS's TCP connection queue? What
>> makes you think that the OS has allocated exactly acceptCount entries in
>> the TCP connection queue? What makes you think acceptCount has been
>> reached? Or not yet reached?
>>
>> What do you think connectionTimeout does, and when do you think it
>> applies?
>>
>>
>>
> I was attempting to use netstat for the queue. Tbh, I found it almost
> impossible so was trying to gauge it mostly from jmeter results. I found
> that it was important to leave a gap between tests as otherwise it was more
> likely to fail.
>
> I was just reading the configuration,  and it sounded like acceptCount
> connections would be queued, after maxThreads, until connectionTimeout
> expired, but it seems connections were refused before then. From Marks
> response it sounds like acceptCount is more of a hint than a precise value,
> and may not be used at all. And also there are likely to be other factors
> outside of these settings that have impacts on these sorts of cases.
>
> > I'm guessing that each forward or redirect effectively counts as an
>> > extra connection, as removing the re

Re: Understanding issues with connection refused when redirecting internally

[Peter Chamberlain]

On Fri, 9 Apr 2021, 14:10 Christopher Schultz, 
wrote:

> Peter,
>
> On 4/9/21 06:53, Peter Chamberlain wrote:
> > Hello,
> > I've been trying to understand the behaviour of tomcat when handling
> > internal redirects. I'm testing using tomcat 9.0.38. I'm testing using
> > jdk8 1.8.0_265. My main test cases have been 2 forwards to the same
> > servlet, and then a response. Or 2 redirects to the same servlet and
> > then a response. Servlet as follows:
> >
> > @WebServlet(loadOnStartup = 1, value = "/")
> > public class ConnectorLimitServlet extends HttpServlet {
> >
> >@Override
> >protected void doGet(HttpServletRequest req, HttpServletResponse
> > resp) throws IOException, ServletException {
> >  int number = Integer.parseInt(req.getParameter("number"));
> >  // Fake some work done at each stage of processing
> >  try { Thread.sleep(500); } catch (InterruptedException e) {}
> >  resp.setContentType("text/plain");
> >  if (number <= 1) {
> >resp.getWriter().write("Finished " + req.getServletPath());
> >return;
> >  }
> >  switch (req.getServletPath()) {
> >case "/redirect":
> >  resp.sendRedirect(new URL(req.getScheme() + "://" +
> > req.getServerName() + ":" + req.getServerPort() +
> >  req.getRequestURI() + "?number=" + (number -
> 1)).toString());
> >  return;
> >case "/forward":
> >  final String forwardAddress = "/forward?number=" + (number - 1);
> >
> getServletContext().getRequestDispatcher(forwardAddress).forward(req,
> > resp);
> >  }
> >}
> > }
> >
> >
> > It seems that under high load, 1000 threads in jmeter, Tomcat will
> > refuse some of the connections for nio2 connections but not for nio,
> > further it seems that these failures happen considerably earlier than
> > the configuration page would suggest would be the case. The
> > configuration suggests that if acceptCount is high enough for the
> > number of connections then they will be queued prior to reaching the
> > processing threads, so a small number of processing threads can exist
> > with a queue of connection feeding them, it seems like until
> > connectionTimeout is reached connections shouldn't be refused, but
> > that is not what occurs. In fact acceptCount seems to have very little
> > effect.
>
> Are you testing on localhost, or over a real network connection? If a
> real network, what kind of network? How many JMeter instances vs Tomcat
> instances?
>
>
Localhost on Windows,  although similar has been seen across the network on
Linux,  this was an attempt to replicate a live issue in a minimal code
approach.

> In short, my questions are:
> > Why is the nio2 connector type worse at this than nio type?
>
> Let's table that for now.
>
> > Why are connections refused before acceptCount is reached, or
> > connectionTimeout is reached?
>
> How are you measuring the size of the OS's TCP connection queue? What
> makes you think that the OS has allocated exactly acceptCount entries in
> the TCP connection queue? What makes you think acceptCount has been
> reached? Or not yet reached?
>
> What do you think connectionTimeout does, and when do you think it applies?
>
>
>
I was attempting to use netstat for the queue. Tbh, I found it almost
impossible so was trying to gauge it mostly from jmeter results. I found
that it was important to leave a gap between tests as otherwise it was more
likely to fail.

I was just reading the configuration,  and it sounded like acceptCount
connections would be queued, after maxThreads, until connectionTimeout
expired, but it seems connections were refused before then. From Marks
response it sounds like acceptCount is more of a hint than a precise value,
and may not be used at all. And also there are likely to be other factors
outside of these settings that have impacts on these sorts of cases.

> I'm guessing that each forward or redirect effectively counts as an
> > extra connection, as removing the redirects and multipling the number
> > of jmeter threads suggests that is the case, am I correct here?
>
> A redirect will cause one connection to be terminated (at least
> logically) and a new connection established. Assuming you are using
> KeepAlives from JMeter, the same underlying TCP connection will likely
> be used for the first and second requests. acceptCount probably doesn't
> apply, since the connection has definitely been established.
>
> For a "forward", the con

Re: Understanding issues with connection refused when redirecting internally

[Peter Chamberlain]

On Fri, 9 Apr 2021, 14:29 Mark Thomas,  wrote:

> On 09/04/2021 11:53, Peter Chamberlain wrote:
> > Hello,
> > I've been trying to understand the behaviour of tomcat when handling
> > internal redirects. I'm testing using tomcat 9.0.38. I'm testing using
> > jdk8 1.8.0_265. My main test cases have been 2 forwards to the same
> > servlet, and then a response. Or 2 redirects to the same servlet and
> > then a response.
>
> The forward case looks like a single HTTP request to both Tomcat and the
> client.
>
> The redirect case looks like 3 separate HTTP requests to both Tomcat and
> the client. The first two receive a 302 response (no body) and finally a
> 200 response with a body. Depending on how the client and Tomcat are
> configured these requests may occur on a single network connection (HTTP
> keep-alive is enabled) or may require a separate connection for each
> request (HTTP keep-alive is disabled).
>
> Once you get into the situation where the network layer is over-loaded,
> behaviour is very much system dependent. It will vary between operating
> systems and between major Java versions.
>
> Note that the OS treats any accept count setting more as a guideline
> than a hard rule and may ignore it completely. Under heavy load you also
> often see other effects (such as port exhaustion impacting the results).
>
> If the backlog is considered to be full, any subsequent connection
> attempts will will refused immediately.
>
> Connection timeout is measured from when the server first tries to read
> the request. From that point the client has connectionTimeout to send
> the first byte.
>
> NIO uses a Poller/Selector approach whereas NIO2 uses completion
> handlers. In many ways there isn't that much difference between them. I
> suspect that NIO will perform better on some systems and NIO2 on others.
>
> When I have looked at this sort of thing in the past, the results have
> nearly always been skewed by other factors. Only by significantly
> reducing the number of client threads and Tomcat threads (less than 10
> each) was I able to start to see the sort of behaviour expected around
> dropped connections, backlog etc and even then it took a fair amount of
> analysis to confirm that what I was observing was as expected.
>
> Mark
>

Okay, that's very helpful. I did find it very difficult to get repeatable
results, so I suspect other layers are causing the issues I've noticed. So
long as I'm not misunderstanding the configuration options, or missing
anything that's fine.

Thanks alot,

Peter

>
>   Servlet as follows:
> >
> > @WebServlet(loadOnStartup = 1, value = "/")
> > public class ConnectorLimitServlet extends HttpServlet {
> >
> >@Override
> >protected void doGet(HttpServletRequest req, HttpServletResponse
> > resp) throws IOException, ServletException {
> >  int number = Integer.parseInt(req.getParameter("number"));
> >  // Fake some work done at each stage of processing
> >  try { Thread.sleep(500); } catch (InterruptedException e) {}
> >  resp.setContentType("text/plain");
> >  if (number <= 1) {
> >resp.getWriter().write("Finished " + req.getServletPath());
> >return;
> >  }
> >  switch (req.getServletPath()) {
> >case "/redirect":
> >  resp.sendRedirect(new URL(req.getScheme() + "://" +
> > req.getServerName() + ":" + req.getServerPort() +
> >  req.getRequestURI() + "?number=" + (number -
> 1)).toString());
> >  return;
> >case "/forward":
> >  final String forwardAddress = "/forward?number=" + (number - 1);
> >
> getServletContext().getRequestDispatcher(forwardAddress).forward(req,
> > resp);
> >  }
> >}
> > }
> >
> >
> > It seems that under high load, 1000 threads in jmeter, Tomcat will
> > refuse some of the connections for nio2 connections but not for nio,
> > further it seems that these failures happen considerably earlier than
> > the configuration page would suggest would be the case. The
> > configuration suggests that if acceptCount is high enough for the
> > number of connections then they will be queued prior to reaching the
> > processing threads, so a small number of processing threads can exist
> > with a queue of connection feeding them, it seems like until
> > connectionTimeout is reached connections shouldn't be refused, but
> > that is not what occurs. In fact acceptCount seems to have very little
> > effect.
> > In short, my questions are:
> > Why

Understanding issues with connection refused when redirecting internally

[Peter Chamberlain]

Hello,
I've been trying to understand the behaviour of tomcat when handling
internal redirects. I'm testing using tomcat 9.0.38. I'm testing using
jdk8 1.8.0_265. My main test cases have been 2 forwards to the same
servlet, and then a response. Or 2 redirects to the same servlet and
then a response. Servlet as follows:

@WebServlet(loadOnStartup = 1, value = "/")
public class ConnectorLimitServlet extends HttpServlet {

  @Override
  protected void doGet(HttpServletRequest req, HttpServletResponse
resp) throws IOException, ServletException {
int number = Integer.parseInt(req.getParameter("number"));
// Fake some work done at each stage of processing
try { Thread.sleep(500); } catch (InterruptedException e) {}
resp.setContentType("text/plain");
if (number <= 1) {
  resp.getWriter().write("Finished " + req.getServletPath());
  return;
}
switch (req.getServletPath()) {
  case "/redirect":
resp.sendRedirect(new URL(req.getScheme() + "://" +
req.getServerName() + ":" + req.getServerPort() +
req.getRequestURI() + "?number=" + (number - 1)).toString());
return;
  case "/forward":
final String forwardAddress = "/forward?number=" + (number - 1);
getServletContext().getRequestDispatcher(forwardAddress).forward(req,
resp);
}
  }
}


It seems that under high load, 1000 threads in jmeter, Tomcat will
refuse some of the connections for nio2 connections but not for nio,
further it seems that these failures happen considerably earlier than
the configuration page would suggest would be the case. The
configuration suggests that if acceptCount is high enough for the
number of connections then they will be queued prior to reaching the
processing threads, so a small number of processing threads can exist
with a queue of connection feeding them, it seems like until
connectionTimeout is reached connections shouldn't be refused, but
that is not what occurs. In fact acceptCount seems to have very little
effect.
In short, my questions are:
Why is the nio2 connector type worse at this than nio type?
Why are connections refused before acceptCount is reached, or
connectionTimeout is reached?
I'm guessing that each forward or redirect effectively counts as an
extra connection, as removing the redirects and multipling the number
of jmeter threads suggests that is the case, am I correct here?

Also, I feel like it would help if there were better documentation
around the differences between nio2 and nio, as, for example, the
connector comparison part makes them sound almost the same.

Apologies if this has been covered elsewhere before, I have been
searching but haven't found anything particularly clear covering this.
Best regards, Peter

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

Re: [OT] programming style or mental process ?

[Peter Kreuser]

All,

> Am 05.04.2021 um 14:38 schrieb Christopher Schultz 
> :
> 
> André,
> 
>> On 4/4/21 06:23, André Warnier (tomcat/perl) wrote:
>> Hi.
>> I have a question which may be totally off-topic for this list, but this has 
>> been puzzling me for a while and I figure that someone here may be able to 
>> provide some clue as to the answer, or at least some interesting ponts of 
>> view.
>> In various places (including on this list), I have seen multiple occurrences 
>> of a certain way to write a test, namely :
>>  if (null == request.getCharacterEncoding()) {
>> as opposed to
>>  if (request.getCharacterEncoding() == null) {
>> Granted, the two are equivalent in the end.
>> But it would seem to me, maybe naively, that the second form better 
>> corresponds to some "semantic logic", by which one wants to know if a 
>> certain a-priori unknown piece of data (here the value obtained by 
>> retrieving the character encoding of the current request) is defined (not 
>> null) or not (null).
>> Said another way : we don't want to know if "null" is equal to anything; we 
>> want to know if request.getCharacterEncoding() is null or not.
>> Or in yet another way : the focus (or the "subject" of the test) here is on 
>> "request.getCharacterEncoding()" (which we don't know), and not on "null" 
>> (which we know already).
>> Or, more literarily, given that the syntax of most (all?) programming 
>> languages is based on English (if, then, else, new, for, while, until, exit, 
>> continue, etc.), we (*) do normally ask "is your coffee cold ?" and not "is 
>> cold your coffee ?".
> 
> On the other hand, in English, coffee which is not hot is called "cold 
> coffee" but in e.g. Spanish, it's "coffee cold".
> 
>> So why do (some) people write it the other way ?
> 
> I personally put the null first because of my background in C. C compilers 
> (especially older ones) would happily compile this code without batting an 
> eyelash:
> 
>  char *s;
> 
>  s = call_some_function();
> 
>  if(s = null) {
>// do some stuff
>  }
> 
> Guess what? "Do some stuff" is always executed, and s is always null.
> 
> If you switch the operands, the compiler will fail because you can't assign a 
> value to null:
> 
>  if(null = s ) {
>// Compiler will refuse to compile
>  }
> 

Isn‘t it true that only one bit difference would result in false - so result 
would not have to be completely tested?

Peter 


> So it's a defensive programming technique for me.
> 
>> Is it purely a question of individual programming style ?
> 
> Perhaps at this stage in history, it is only "style". But it does have a 
> practical
> 
>> Is there some (temporary ?) fashion aspect involved ?
>> Do the people who write this either way really think in a different way ?
>> Or is there really something "technical" behind this, which makes one or the 
>> other way be slightly more efficient (whether to compile, or optimise, or 
>> run) ?
>> (*) excepting Yoda of course
> 
> -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

IDNs emoji replaced by punycode - how to remain with emoji?

[Peter Rader]

Hi,
 
I try to support a emoji in a IDN. This is the head of my engine-config:
 

   
    
  
  
 
Both, HTTP and HTTPS connector have the UTF8 encoding:
 

  
 
    
    
    
    
    
 
 
Unfortunately the browser-url redirect to the punycode xn--x7h.example.com in 
Chrome, Edge and Firefox (did not test more).
 
How to remain with emoji IDN in the browser URL?
 
Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 6 29 33 29 6
Fax: 0049 (0)30 / 6 29 33 29 6
Handy: 0049 (0)176 / 8 7521576

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

Re: Question about TLS/SSL setup and SSLHostConfig or not

[Peter Kreuser]

Alex,

> Am 02.03.2021 um 23:19 schrieb Alex :
> 
> Hi.
> 
>> On 02.03.21 23:14, John Larsen wrote:
>> I usually let the apache webserver or nginx handle the SSL while proxying
>> to the tomcat.


Unless you need some really fancy rewriting or caching, Tomcat is absolutely 
capable to handle this. Even static files are OK nowadays.


>> To use tomcat's built in server you'll need to import the
>> SSL certificate into the keystore via your jdk.

That’s not the case anymore. Tomcat 8.5.x perfectly speaks PEM-files and 
openssl config. (See below)

Even dynamic reloading of SSL configs can be achieved with the jmxproxy.

> 
> Fully agree, but sometimes it is requierd that the HAProxy/nginx talk TLS to
> the backend, in this case tomcat.
> 
>> John Larsen
>>> On Tue, Mar 2, 2021 at 3:06 PM Alex  wrote:
>>> Hi.
>>> 
>>> I try to make a "good" tomcat config and read the docs.
>>> 
>>> Now in the Connector doc is the following statement.
>>> 
>>> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support
>>> http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support
>>> 
>>> Each secure connector must define at least one SSLHostConfig.
>>> 
>>> But when I look into the SSL/TLS Configuration How-To is the snipplet
>>> without SSLHostConfig. What's now the "best" way to setup TLS/SSL
>>> with tomcat. I would prefer to put SSLHostConfig but I'm not sure if
>>> it's the way how the developer think to setup the TLS in tomcat?
>>> 
>>> I use JSSE as implementation.
>>> 
>>> http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html
>>> http://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
>>> 
>>> ```
>>> 
>>> >> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> port="8443" maxThreads="200"
>>> scheme="https" secure="true" SSLEnabled="true"
>>> keystoreFile="${user.home}/.keystore" keystorePass="changeit"
>>> clientAuth="false" sslProtocol="TLS"/>
>>> ```
>>> 

You should move this to SSLHostConfig.


  


HTH

Peter

>>> What's your suggestion and opinion to configure the tomcat in a
>>> proper way to use TLS also for the future versions.
>>> 
>>> Regards
>>> Alex
>>> 
>>> -
>>> 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: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing

[Peter Kreuser]

James,

> Am 07.01.2021 um 00:34 schrieb James H. H. Lampert :
> 
> We just had our first Tomcat 8.5 installation on a customer's AS/400.
> 
> The customer apparently has his own CA (they're a big company), and when I 
> installed SSL in their Tomcat, and tested it with a browser, it complained, 
> something to the general effect of "weak signature algorithm."
> 
I guess they never upgraded their CA and still sign the certs with SHA1 or even 
MD5.

They should change that for sure!

Peter

> While it's not really my problem (and is only connected to Tomcat by virtue 
> of it happening with a Tomcat server), I'm curious about what's up with it, 
> if anybody here is able and willing to explain it.
> 
> Of course, a customer that's big enough to run a private CA in production is 
> already doing things beyond my pay grade.
> 
> --
> JHHL
> 
> -
> 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: Deploying war, Negative Date exception

[Peter Henderson]

On Mon, 12 Oct 2020 at 14:50, Mark Thomas  wrote:

> On 12/10/2020 13:53, Mark Thomas wrote:
> > On 12/10/2020 12:49, Mark Thomas wrote:
> >> On 12/10/2020 12:19, Peter Henderson wrote:
> >>> Hello fellow tomcat users.
> >>>
> >>> My environment.
> >>> Tomcat: 9.0.39
> >>> Java: openjdk 11.0.8 2020-07-14
> >>> OS: Ubuntu 18.04.5 LTS
> >>>
> >>> Source code [0]
> >>>
> >>> When deploying this war [1], by copying it into the webapps directory,
> >>> I get this exception. [2]
> >>> java.lang.IllegalArgumentException: Negative time
> >>>
> >>>
> >>> I only started seeing this exception when I upgraded my projects build
> tool
> >>> version
> >>> from
> >>> sbt.version=1.3.10
> >>> to
> >>> sbt.version=1.4.0
> >>>
> >>>
> >>> Is this a tomcat bug, a build tool bug or most likely something I'm
> doing
> >>> wrong?
> >>
> >> Looks like an issue with the dates of files in the WAR.
> >>
> >> If you look at the dates of the files in the WAR nearly all of them are
> >> in the future (07 Feb 2106, 06:28).
> >>
> >> It looks like something is overflowing but a Java long shouldn't do
> that.
> >>
> >> Need to dig into exactly what is going on as this looks like it should
> >> work - even if the WAR contains files created almost a century in the
> >> future.
> >
> > Hmm. I see the 2106 date on the file system and with Java 8 but with
> > Java 11 I see 1969-dec-31 23:00 which gives -360 which triggers the
> > exception.
> >
> > The root cause appears to be in the JRE at this point. Whether it is in
> > the JRE used to create the WAR or the JRE reading the WAR is TBD.
> >
> > I think I am going to have to look at the raw bytes and the zip file
> > spec to figure out where the root cause is.
>
> That was fun.
>
> Per the zip spec, the last modified time on those files is:
>
> 1969-Dec-31 23:00:00 UTC
>
> i.e. 1 hour before the Epoch at 1970-Jan-01 00:00:00 UTC
>
> It is stored as a signed 32-bit int (F1F0) which is -3600 (zip
> timestamps are in seconds since the Epoch).
>
> Java 8 reads this incorrectly as an unsigned int (4294963696) which,
> when taken as seconds since Epoch, gives 2016-Feb-07 05:28:16 UTC.
>
> (Incidently the archiver that ships with Ubuntu appears to make the same
> error)
>
> Java 11 reads this correctly but Java does not let you set times before
> the Epoch so the exception is triggered.
>
> The short version is that the modification times of the files in the WAR
> are being set to "1969-Dec-31 23:00:00 UTC" which Java doesn't like.
>
> Tomcat could handle this more gracefully but the end result will be the
> same - the WAR isn't going to deploy. I'm not convinced it is worth
> doing anything here.
>
> It looks like the fix will be somewhere in the build system used to
> create the WAR.
>

Thanks for digging into this.

For anyone else who runs into this.

When upgrading to sbt >= 1.4.0
An environment variable needs to be set
SOURCE_DATE_EPOCH
[0]

I suspect the bug is in [1] with the orElse(0L) start of epoch looks
familiar.


[0] https://reproducible-builds.org/docs/source-date-epoch/
[1]
https://github.com/sbt/sbt/pull/5344/commits/1d0a41520071c2fcf694d6b68e4b5e7721f7c321

Peter.






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

-- 
Peter Henderson

Director
Starjar Ltd.
www.starjar.com
0330 088 1662

Deploying war, Negative Date exception

[Peter Henderson]

Hello fellow tomcat users.

My environment.
Tomcat: 9.0.39
Java: openjdk 11.0.8 2020-07-14
OS: Ubuntu 18.04.5 LTS

Source code [0]

When deploying this war [1], by copying it into the webapps directory,
I get this exception. [2]
java.lang.IllegalArgumentException: Negative time


I only started seeing this exception when I upgraded my projects build tool
version
from
sbt.version=1.3.10
to
sbt.version=1.4.0


Is this a tomcat bug, a build tool bug or most likely something I'm doing
wrong?

Thanks
Peter.


[0]
https://github.com/bollinger/NegativeDate

[1]
https://github.com/bollinger/NegativeDate/blob/master/Negative.war

[2]
2020-10-12 11:41:35.932 SEVERE oacs.HostConfig Error deploying web
application archive [/home/peter/apache-tomcat-9.0.39/webapps/Negative.war]
java.lang.IllegalStateException: Error starting child
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:706)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:978)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1848)
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.deployWARs(HostConfig.java:773)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1620)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:305)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1151)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1353)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1335)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.catalina.LifecycleException: Failed to start
component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Negative]]
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.ContainerBase.addChildInternal(ContainerBase.java:717)
... 24 more
Caused by: java.lang.IllegalArgumentException: Negative time
at java.base/java.io.File.setLastModified(File.java:1441)
at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:169)
at
org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:820)
at
org.apache.catalina.startup.ContextConfig.beforeStart(ContextConfig.java:958)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:305)
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.start(LifecycleBase.java:182)
... 25 more

-- 
Peter Henderson

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Peter Kreuser]

Mark,

Sorry for Top-posting.

I’m still wondering what is causing this Qualys finding.

I remember times when you got only garbage when you connected with http to 
https. Probably Qualys was fine with that.

Now you get a nice 400 message that helps the user understand his mistake and 
Qualys jumps on that!
From my point of view we should not change that behavior as it will not change 
the users settings or mistyping.

I wonder how Nginx or httpd are reacting to this finding - if Qualys reacts in 
the same way?
Basically the scanner already has the information that this is an SSL port!
To me a bug in the scanner plugin!

My 2ct.

Peter

> Am 27.08.2020 um 09:47 schrieb Mark Thomas :
> 
> On 27/08/2020 06:31, Terence M. Bandoian wrote:
>> On 8/26/2020 11:27 PM, Pratik Shrestha wrote:
> 
> 
> 
>>> For me, there are two options for the fix which I am not able  to make
>>> them
>>> work.
>>> 
>>> 1. Either show 'ERR_EMPTY_RESP' like old Tomcat version 7 used to
>>> show. As
>>> far as I know, with Tomcat 7 giving that error, Qualys did not use to
>>> show
>>> this vulnerability.
>>> 2. *Best is to do a redirect* when Tomcat sees error 400 to https URL.
>>> Like
>>> in Apache, we can add below.
>>>'ErrorDocument 400 "*https*://xxx.xxx.xxx.xxx"
>>> But as understood, redirect only works with error 3XX and ErrorDocument
>>> feature is not there in Tomcat yet.
> 
> 
> 
>> With HTTPD rewrite, whether or not the request is encrypted or sent to
>> the correct port can be detected and the request redirected as
>> appropriate. Maybe the same can be done with the rewrite valve used with
>> Tomcat.
> 
> This isn't currently possible with Tomcat because of detection of plain
> text HTTP when TLS should be used (and the generation of the associated
> response) is much, much earlier in the processing chain than the rewrite
> valve.
> 
> 
> 
>>>>> On 8/26/20 13:59, Mark Thomas wrote:
>>>>>> On 26/08/2020 17:50, Christopher Schultz wrote:
> 
> 
> 
>>>>>>> I'm interested in having Tomcat be able to pass these (admittedly
>>>>>>> stupid) security requirements,
>>>>>> I have no interest in adding bloat to Tomcat so it can pass so called
>>>>>> security requirements that have no relevance to actual security. Those
>>>>>> sort of changes are the sort that get me starting to think about using
>>>>>> a veto.
>> Understood. But what does the OP have in terms of options at this point?
>> 
>> 1. Ignore the complaint (probably not possible) 2. Request a waiver for
>> this issue (probably not possible, or at least would require 10 years of
>> red tape) 3. Front the server with httpd + "ErrorDocument 400" (which
>> ... I
>> think will *also* reply with a plaintext response, right?) 4. Switch to
>> Jetty>
>> I'm trying to avoid "the easiest thing" which is probably to switch to
>> Jetty. I know our "customers" don't pay for Tomcat, but losing a
>> "customer"
>> sucks.
> 
> One of the things I love about working Tomcat is when this sort of
> security nonsense comes along, I can a) call it out and b) veto (if I
> have to) the implementation without someone higher up the organisational
> hierarchy able to play the "I don't care if it is nonsense, our
> customers want it so you have to implement it" card.
> 
> My objection to implementing or changing features in response to
> "security nonsense" is that it perpetuates the problem. If people who
> know this is "security nonsense" just accept it rather than arguing
> against it, that nonsense eventually becomes "security fact". I think
> the world could do with a little more security fact and a little less
> security nonsense.
> 
> That said, I'm not against changing this feature where that change
> offers real benefits to users.
> 
>> How about being able to specify the response text, possibly blank?
> 
> While I remember, there was the issue raised that the response wasn't
> UTF-8 and we changed hard-coded response to UTF-8 rather than provide an
> option.
> 
> My concern with anything along the lines of making it configurable is
> that because this response is generated outside of the normal HTTP
> processing infrastructure you can quickly get into the situation where
> you end up replicating functionality we already have elsewhere.
> 
>> I think "ErrorDocument 400" with nothing else might mean the same
>> thing as
>>

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Peter Kreuser]

Pratik,

> Am 25.08.2020 um 12:14 schrieb Pratik Shrestha :
> 
> Hi all,
> 
> Tomcat version: 9.0.37
> 
> Our website is running on Tomcat. We did Qualys vulnerability scan on our
> site. Scan shows below vulnerability.
> 
> Insecure transport
> Group: Information Disclosure
> CWE CWE-319
> OWASP A3 Sensitive Data Exposure
> WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
> 
> Please note
> 1. HTTP port is not enabled.


Which port does it complain on? Maybe it’s not Tomcat, but another service?


> 2. We have only opened HTTPS port 8443. But when we connect this HTTPS port
> with HTTP (http://www.oursite.com:8443/), we get an error "Bad Request. This
> combination of host and port requires TLS."
> 3. Due to the above error message, we get this vulnerability error from
> Qualys.
> 4. We have already enabled HSTS.
> 5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But it
> never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It just
> finds someone is accessing HTTPS port with HTTP protocol and then just
> throws error 400 'Bad Request'
> 6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP' which
> should still be okay.
> 
> We already tried to find the fix for this issue on the web but in vain.
> 
> Kindly help if anyone has found a way to fix it.
> 
> Regards,
> Pratik

Peter


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

Re: Request for Help

[Peter Rader]

Hello Mohan,
 
please tell if you are using
1. the JSP technology inside the application
2. what JDK version on server-side
 
Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 6 29 33 29 6
Fax: 0049 (0)30 / 6 29 33 29 6
Handy: 0049 (0)176 / 8 7521576
 
 

Gesendet: Mittwoch, 29. Juli 2020 um 06:33 Uhr
Von: "Mohan T" 
An: "Tomcat Users List" 
Betreff: Request for Help
Dear All,



In one of the environments we are using apache-tomcat-8.5.35.



On server start we are getting this exception

org.apache.catalina.core 28-Jul-2020 13:46:13.407 SEVERE 
[localhost-startStop-1] org.apache.catalina.core.StandardContext.loadOnStartup 
Servlet [RVW_Banner] in web application [/security] threw load() exception
java.lang.NoSuchMethodError:org.eclipse.jdt.internal.compiler.Compiler.(Lorg/eclipse/jdt/internal/compiler/env/INameEnvironment;Lorg/eclipse/jdt/internal/compiler/IErrorHandlingPolicy;Lorg/eclipse/jdt/internal/compiler/impl/CompilerOptions;Lorg/eclipse/jdt/internal/compiler/ICompilerRequestor;Lorg/eclipse/jdt/internal/compiler/IProblemFactory;)V
at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:480)

Any inputs to overcome this could help us in this.

Thanks

Mohan



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.

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

Re: Error in stopping application tomcat !!

[Peter Kreuser]

Kushagra,


> Am 25.07.2020 um 08:12 schrieb Kushagra Bindal :
> 
> One more related changes :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63041

None of the bugzilla entries relate to changes in  newer versions.

It won‘t be as easy as to search for „ „shutdown“ in either bugzilla or the 
release notes!

> Please suggest the probable fix to make this smooth.
> 

For now it maybe as simple as sending SIGKILL to the java process.

Apparently some resources in your app don‘t want to terminate.

My 2ct.

Peter

>> On Sat, Jul 25, 2020 at 11:03 AM Kushagra Bindal 
>> wrote:
>> Thanks Martin,
>> By looking at the change log I found few relevant items.
>> 1. https://bz.apache.org/bugzilla/show_bug.cgi?id=55969
>> 2. https://bz.apache.org/bugzilla/show_bug.cgi?id=62515
>> 3. https://bz.apache.org/bugzilla/show_bug.cgi?id=48655
>> 4. https://bz.apache.org/bugzilla/show_bug.cgi?id=63210
>> If possible, please help in understanding the behavior and possible way to
>> handle this.
>> Thanks in advance for helping me so far.
>> On Fri, Jul 24, 2020 at 1:08 AM Martin Grigorov 
>> wrote:
>>> On Thu, Jul 23, 2020, 15:52 Kushagra Bindal 
>>> wrote:
>>>> Thanks Martin.
>>>> But with the old version i.e. 8.5.24 it is working smoothly. So, what
>>> could
>>>> be the problem? Or some specific property/configuration changes that
>>> need
>>>> to be made around this?
>>> You will have to consult with the changelogs for all the versions in
>>> between.
>>>> On Thu, Jul 23, 2020 at 6:00 PM Martin Grigorov 
>>>> wrote:
>>>>> On Thu, Jul 23, 2020 at 3:10 PM Kushagra Bindal <
>>>> bindal.kusha...@gmail.com
>>>>> wrote:
>>>>>> Hi Martin,
>>>>>> Due to our environment I was not able to use pastebin service. I
>>> have
>>>>>> taken different Thread dump during shutdown and attaching the same
>>> with
>>>>>> this email.
>>>>>> Please review the same and let me know, what is the probable root
>>> cause
>>>>> of
>>>>>> the problem and what could be the fix of the same.
>>>>> You have many AMQP (RabbitMQ) listener threads which are not daemons.
>>>>> It seems your application does not notify Spring Framework that it
>>> needs
>>>> to
>>>>> destroy its application context or the beans with
>>>>> type
>>> org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer
>>>>> are not notified to stop for some other
>>>>> reason.
>>>>>> On Thu, Jul 23, 2020 at 3:22 PM Martin Grigorov <
>>> mgrigo...@apache.org>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>> On Thu, Jul 23, 2020 at 6:35 AM Kushagra Bindal <
>>>>>>> bindal.kusha...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Hi Martin,
>>>>>>>> These are the only two behaviors right now which I am getting on
>>> a
>>>>>>>> regular basis.
>>>>>>>> 1. During startup of the application and then shutdown
>>>>>>>> 2. Running application and then shutdown.
>>>>>>>> Please let me know if anything specific is further needed from my
>>>> end
>>>>>>> which
>>>>>>>> I can provide to have a better clarity.
>>>>>>>> I have shared the server.xml and command which we are using in
>>>>> stopping
>>>>>>> the
>>>>>>>> tomcat.
>>>>>>>> On Thu, Jul 23, 2020 at 2:49 AM Martin Grigorov <
>>>> mgrigo...@apache.org
>>>>>>>> wrote:
>>>>>>>>> On Wed, Jul 22, 2020, 15:55 Kushagra Bindal <
>>>>>>> bindal.kusha...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Hi Christopher,
>>>>>>>>>> Did you get a chance to look into this?
>>>>>>>>>> Please help us in resolving this issue.
>>>>>>>>>> On Sat, Jul 18, 2020 at 11:26 AM Kushagra Bindal <
>>>>>>>>>> bindal.kusha...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>> Additionally when trying to stop running application, we
>>&

Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)

[Peter Kreuser]

Mark, James

> Am 09.04.2020 um 22:14 schrieb Mark Eggers :
> 
> James,
> 
>> On 4/9/2020 12:11 PM, James H. H. Lampert wrote:
>>> On 4/6/20 2:13 PM, Mark Eggers wrote:
>>> # Secure your proxy - localhost for now - this is IMPORTANT
>>> 
>>>Require ip 127
>>> 
>> 

Isn‘t this for CONNECT Requests?
The Backend proxying happens with GET POST PUT to httpd and then apache opens 
the connect to backend.
No Proxying in the sense of the PROXY directive...

>> Dear Mr. Eggers:
>> 
>> It seems I was right about how what you said about this, and what the
>> docs say about it, appeared to contradict each other: with that in the
>> VirtualHost with the ProxyPass and ProxyPassReverse directives, it
>> blocked all outside access through the proxy.
>> 
>> Once I commented out those lines, I got proxied straight to the default
>> ROOT context.
>> 
>> Then, when I reactivated the valve in the manager app, I found that I
>> was still able to get into it via the proxy, but not directly.
>> 
>> I've now put this in
>>> https://qux.baz.com/manager;>
>>>  Require ip xx.yy.zz.qq
>>> 
>>> https://corge.bax.com/manager;>
>>>  Require ip xx.yy.zz.qq
>>> 
>> 

It should be sufficient to just do a Location directive and then Require.


  Require 


Maybe also LocationMatch.

>> where xx.yy.zz.qq is my office IP address. I could get in just fine.
>> Then I changed the IP address to something different, restarted my
>> browser, and I could still get in. I also tried it with "/*" on the ends
>> of the URLs, and with "/html" on the ends, and with "/html/*" on the
>> ends. I also went back to the original "*" on one of them, and it went
>> back to locking me out of everything. Something doesn't seem right here.
>> 
> 
> I'll play with this a little later.

Me too. 
> 
> Please note that when you change Apache HTTPD configurations you must
> restart Apache HTTPD.
> 

An apachectl graceful reloads the config without downtime.

> This is one of the reasons why I prefer mod_jk. I can change the mapped
> URLs on the fly without having to restart Apache HTTPD (albeit with some
> small hit to performance).
> 
> The way that I have things set up for a client is to have a machine with
> two interfaces and use an  directive in server.xml.
> 
> I then run an additional HTTP/1.1 connector and bind it to the internal
> interface only. The internal interface is protected by VPN with a two
> factor authentication.
> 
Interesting idea.


> I could further protect the sensitive applications by using the remote
> address filter and restricting access to the management and build
> systems subnets.
> 
> To access the manager application, you have to connect to the VPN, and
> then browse to the following:
> 
> http://internal.dns.domain.com:port/manager/html
> 
> This will will bring up a manager interface that is appropriate for:
> 
> https://external.dns..domain.com
> 
> and all the applications running there. This is mostly used by the
> client's internal Jenkins build system to publish applications to the
> appropriate Tomcat server. It can also be used by a JMX application for
> Tomcat monitoring.
> 
> My urimapping.properties file contains lines like:
> 
> !/manager|/*=worker_name
> !/jmxmonitor|/*=worker_name
> 
> This blocks proxying the manager and JMX applications by mod_jk.
> 
> This has been running in production since I set it up, and has survived
> both random script kiddie attacks and security audits by the client's
> customers.
> 
> You could look at mimicking this behavior with mod_proxy by using an
> exclamation mark (not tested).
> 
> Something like the following:
> 
> ProxyPass /manager !
> ProxyPass /jmxmonitor !
> 
> per the documentation here:
> 
> https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass
> 
> Apparently, the documentation would recommend something like the following:
> 
> 
>ProxyPass "!"
> 
> 
>ProxyPass "!"
> 
> 
> I think that the above is probably easier to read and more specific.
> Place the directives in the appropriate virtual host.
> 
> You could also be more expressive with LocationMatch and regular
> expressions.
> 
> Once this is done you could access the manager application directly by
> using the appropriate port and configuring AWS's firewall rules to allow
> your office IP address through the port.
> 
> Again, I have not tried this since I use mod_jk.  Again, please remember
> to restart Apache HTTPD after any configuration changes.
> 
> 
> . . . just my two cents
> /mde/

Peter
> 


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

Aw: Re: Re: /META-INF/resources/ and Chrome's DevTools

[Peter Rader]

Ah ok, 
 
I use maven, only tomcat 7 and 6 is available. PreResources are only available 
in tomcat8 so I decide against tomcat in higher versions than 7.
 
Kind regards

>  Gesendet: Montag, 06. April 2020 um 16:34 Uhr
>  Von: "Mark Thomas" 
>  An: users@tomcat.apache.org
>  Betreff: Re: Aw: Re: /META-INF/resources/ and Chrome's DevTools
>  On 06/04/2020 09:16, Peter Rader wrote:
>  > Hello Konstantin Kolinko,
>  >
>  > I tried to use the PreResource but it does not work.
>  >
>  > 2020-04-06 10:13:05 WARNUNG org.apache.tomcat.util.digester.Digester 
> endElement No rules found matching 'Context/Resources/PreResources'.
>  >
>  > This is my context.xml
>  >
>  > 
>  >   > type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
>  > url=""
>  > username="xxx" password="xxx" maxTotal="50"
>  > maxIdle="50" maxWait="10">
>  > 
>  >   > className="org.apache.catalina.webresources.FileResourceSet"
>  > base="C:\Users\Guest\git\x\src\main\resources\META-INF\resources"
>  > internalPath="index.html" />
> 
>  That doesn't look quite right. I'd expect it to look something like:
> 
>    className="org.apache.catalina.webresources.FileResourceSet"
>  base="C:\Users\Guest\git\x\src\main\resources\META-INF\resources"
>  />
>
>  To map the contents of the "...\META-INF\resources" directory into the
>  root of the web application.
> 
>  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

Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)

[Peter Kreuser]

James,

> Am 06.04.2020 um 21:53 schrieb James H. H. Lampert :
> 
> Here is the situation:
> 
> We have an existing Amazon EC2 instance, running Amazon Linux 2, with an 
> Apache httpd server already running our web sites (for argument's sake, 
> "foo.com," "bar.com," and "baz.com."), and already getting its certs from 
> Let's Encrypt, using "foo.com" as the CN, with "www.foo.com," "bar.com," 
> "www.bar.com," "baz.com," and "www.baz.com" as SANs. And it seems to be 
> working quite nicely.
> 
> Now, we want to add a Tomcat server, which would then serve several webapp 
> contexts at "qux.baz.com," and maybe also "corge.baz.com," running behind the 
> httpd server (which is something I've never done before; I've always set up 
> Tomcat directly facing the outside world, so with this, I frankly haven't a 
> clue what I'm doing).
> 

Don‘t be scared!

> First of all, which is currently considered the easier/better way to get 
> Tomcat running behind httpd, given the above scenario? "mod_proxy," or 
> "mod_jk?" Or is there something else I haven't heard of?
> 


> Second of all, I found this step-by-step procedure.
> 
>> https://preview.tinyurl.com/vwnutqj
> 
> Is it any good?
> 
Sounds reasonable.

Are you going to host tomcat on the same „server“ or are you proxying to a 
different instance? Then mod_proxy and ssl (!) should be the way to go. If you 
are on the same instance, you may want to see if mod_jk is an option.

> Third, am I correct in assuming that all we need to do in order for the 
> existing Let's Encrypt setup to cover the new "qux" and "corge" subdomains is 
> to add them to the SANs already listed?
> 

That and the additional Serveralias‘ or VirtualHosts that proxy the tomcat 
requests.

> Finally, are there any "gotchas" I need to be concerned with?
> 

Any headers that are necessary for your tomcat application need to be sent or 
maybe rewritten.

You may need to set the correct attributes on your connector, so the URLs are 
correctly rewritten (port 8080/8443 in tomcat should be https 443 to the 
outside! Cookies may need the correct path and secure flag.)

That may be a second round of tweaking. First get to serve the pages on the 
right Uri.

Let us know how you get along and we can add to the config if necessary.

Peter

> --
> James H. H. Lampert
> Touchtone Corporation
> 
> -
> 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

Aw: Re: /META-INF/resources/ and Chrome's DevTools

[Peter Rader]

Hello Konstantin Kolinko,

I tried to use the PreResource but it does not work. 

2020-04-06 10:13:05 WARNUNG org.apache.tomcat.util.digester.Digester endElement 
  No rules found matching 'Context/Resources/PreResources'.

This is my context.xml









Any idea?



>
> Gesendet: Montag, 16. März 2020 um 01:01 Uhr
> Von: "Konstantin Kolinko" 
> An: "Tomcat Users List" 
> Betreff: Re: /META-INF/resources/ and Chrome's DevTools
> ??, 15 ???. 2020 ?. ? 13:47, Peter Rader :
> >
> > I have my default.js in a frontend.jar's /META-INF/resources/js/ according 
> > to the specs (last paragraph of point 10.10 in 
> > https://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf
> >  ) it is served successfully. This works great!
>
> 1. If you unpack the file into a directory in your web application
> (into its /js/ directory),
> it will take precedence over the version packed in the framework jar.
>
>
> 2. It is possible to map files from elsewhere on your hard drive into
> your web application.
> It can be done with "" element in the
> META-INF/context.xml file of your web application.
>
> For reference:
> http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html[http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html]
>
>
> 3. If your Tomcat runs on the same computer. you can run the web
> application from an expanded directory, without packing it as a war
> file.
>
> 1) Copy your META-INF/context.xml file as
> $CATALINA_BASE/conf/Catalina/localhost/yourwebappname.xml
>
> 2) Add docBase attribute to the  element in it.
>
> See
> http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context[http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context]
>
>
> Best regards,
> Konstantin Kolinko




Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 20 9930560
Fax: 0049 (0)30 / 20 9930561
Handy: 0049 (0)176 / 8 7521576

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

Aw: Re: /META-INF/resources/ and Chrome's DevTools

[Peter Rader]

> >
> > I have my default.js in a frontend.jar's /META-INF/resources/js/ according 
> > to the specs (last paragraph of point 10.10 in 
> > https://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf
> >  ) it is served successfully. This works great!
>
> 1. If you unpack the file into a directory in your web application
> (into its /js/ directory),
> it will take precedence over the version packed in the framework jar.

Ok this will work but I run the app using

  mvn tomcat:run

Any behavioural modification to this process will order modifications to the 
pom.xml. Since this leads to be more project-specific code under 
version-control to support I like to avoid this.

>
>
> 2. It is possible to map files from elsewhere on your hard drive into
> your web application.
> It can be done with "" element in the
> META-INF/context.xml file of your web application.
>
> For reference:
> http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html[http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html]
>

This might do the trick! Ill try that out. If that is confirmed to be working I 
can get rid of https://github.com./enexusde/devtools-tomcat-bypass .

>
> 3. If your Tomcat runs on the same computer. you can run the web
> application from an expanded directory, without packing it as a war
> file.
>
> 1) Copy your META-INF/context.xml file as
> $CATALINA_BASE/conf/Catalina/localhost/yourwebappname.xml
>
> 2) Add docBase attribute to the  element in it.
>
> See
> http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context[http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context]
>

Since beside the frontend.jar I have other jars who serve static resources. 
This means I must have multiple docBases what is not possible AFAIK.

>
> Best regards,
> Konstantin Kolinko

Kind regards

Peter Rader

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

Aw: /META-INF/resources/ and Chrome's DevTools

[Peter Rader]

I wrote a little WebFilter for this task.

https://github.com/enexusde/devtools-tomcat-bypass

Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 20 9930560
Fax: 0049 (0)30 / 20 9930561
Handy: 0049 (0)176 / 8 7521576

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

/META-INF/resources/ and Chrome's DevTools

[Peter Rader]

I have my default.js in a frontend.jar's /META-INF/resources/js/ according to 
the specs (last paragraph of point 10.10 in 
https://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf
 ) it is served successfully. This works great!

Chrome load this default.js during surfing on localhost. Using DevTools I can 
map this in-browser-default.js to a local directory. This allowes chrome to 
synchronize the local source-version of the default.js with the in-browser 
loaded default.js.

This way I have a source-cascade.
1. The default.js is Packed into the frontend.jar.
2. The frontend.jar is Packed into the application.war.
3. The application.war is served via Tomcat.

The Problem:

If I reload the website Chrome DevTools drops all changes I made to the Tomcat 
served version. 
So if I change a single byte in the default.js I have to:
1. Pack the jar
2. Pack the war
3. Redeploy the war.

This process takes a length of about 5 minutes. It is reloading the application 
and package the jars/wars for the sake of 1 byte change.

The Question:

Can I map a single resource to a file dynamically without reloading the 
application.


Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 20 9930560
Fax: 0049 (0)30 / 20 9930561
Handy: 0049 (0)176 / 8 7521576

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

Aw: Installing a program designed for Tomcat 5.5 on Tomcat 9

[Peter Rader]

> I am currently trying to install a program designed to operate on Win XP 32
> and earlier on to a Win 10 environment. The program extracts to the Shared
> and Webapps folders of Tomcat 5.5 and uses a SQL database. After converting
> the database and installing it on SQL 2017 I added the JDBC connector and
> downloaded and installed tomcat 9 only to find there is no shared folder to
> extract the shared files to. Any suggestions?

Hm, shared ... do you mean the endorsed folder? From old apps I remember that 
some jdbc-jars have to be placed in tomcat's endorsed folder.

I am pretty sure that you could use the JVM/JDK's endorsed folder. They usually 
have their place in \lib\endorsed .

Kind regards

Peter Rader

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

Re: mvn redeploy - double redeployment problem (within 0.2 seconds)

[Peter Rader]

> Does it ever work?

Yes, I deployed and redeployed much larger WARs (i.e. 107MiB) many times to the 
same instance.

> 
> The Tomcat manager has a default limit of 50MiB for uploads. Your WAR
> file it larger than that, so it might be failing.

Some weeks ago I changed this default limit to "about" 500MiB - as I always do 
(!!). To give you the 100% prove I send you the max-file-size-config:

   
  524288
  524288
  0



> 
> The /second/ upload in your log file might be because the deployer
> re-tries when the first attempt fails. 

Hm, if the plugin retries to upload I expect some logging output. Even if there 
is no debug-output for the retry, I could try to debug it locally.

> It's so fast because Tomcat
> rejects the request immediately after looking at the Content-Length,
> instead of allowing 71MiB of stream over the network before rejecting
> the request.

This can not be true, how would you tell the existance of this line in the log?:

   02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] 
org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web 
application 'XXX'

If - and only if - a WAR is rejected because of its size, the Manager would 
never ever write "Hey dude, I am deploying your web application XXX!". Right?

Anyway I found it by myself.

> On 2/2/20 4:48 PM, Peter Rader wrote:
> > The old version of the application had a daemon that have not yet
> > finished his execution.
>
> Tomcat cannot detect this situation, so it's unlikely to be the direct
> problem. 

I see.

> How did you come to your conclusion?

I noticed two hints that guides me to this idea:

1. I configured a user having the role manager-gui and tried to stop the 
web-application using the manager-web-interface (/manager/html/list). Stop 
command was not successfull, a error message occoured above the 
application-table.
2. I could send the SHUTDOWN signal successfully, all looks like a clear 
shutdown (the connectors successfully shutting down, CDI shutdown, 
EntityManager closed, port 80+443 becomes free, sessions passivated) but the 
java-process remains running for no reason and must be killed manually.
3. Last but not least, the original problem: The webapp fails to redeploy using 
mvn tomcat:redeploy.

> 
> - -chris

--
Peter

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

Aw: Re: SOLVED - Re: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)

[Peter Rader]

> Please post updates to the original thread.

This is the original thread.

> As suggested in the original thread, it was a permissions issue ...
> permission denied because the port was already in use : )

Why do you think it is a permission issue? I already disproved that! How can 
you break it down to port-already-in-use? I found the answer and it was faar 
away from any permission issue!

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

SOLVED - Re: Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)

[Peter Rader]

The old version of the application had a daemon that have not yet finished his 
execution.

Unfortuantely there is no further logging why the old version not stoped yet.

I expected to have the "mvn redeploy" waiting forever for this deamon-locked 
problem. What I can not do is write a bug report because the bug was inside my 
app. But what I might do is to add a feature-request. Not sure where, and not 
sure for what component, maven-tomcat-plugin maybe...

Thanks.

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

Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)

[Peter Rader]

Thank you for your reply.

> Always look for the last "Caused by" in a stack trace for root cause. An
> "IOException: Error writing to server" is indicative of a permissions
> issue - I would start there, possibly the user account running the process.

As pointed out in No. 3 the log said that the permission has been granted 
successfully.

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

mvn redeploy - double redeployment problem (within 0.2 seconds)

[Peter Rader]

oke (TomcatManager.java:604)
at org.codehaus.mojo.tomcat.TomcatManager.deployImpl 
(TomcatManager.java:662)
at org.codehaus.mojo.tomcat.TomcatManager.deploy (TomcatManager.java:295)
at org.codehaus.mojo.tomcat.AbstractDeployWarMojo.deployWar 
(AbstractDeployWarMojo.java:85)
at org.codehaus.mojo.tomcat.AbstractDeployMojo.invokeManager 
(AbstractDeployMojo.java:85)
at org.codehaus.mojo.tomcat.AbstractCatalinaMojo.execute 
(AbstractCatalinaMojo.java:141)
at org.codehaus.mojo.tomcat.AbstractWarCatalinaMojo.execute 
(AbstractWarCatalinaMojo.java:70)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)

1. Access log shows the PUT command:
02-Feb-2020 16:57:06.429 FINE [http-nio-80-exec-5] 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [PUT 
/manager/text/deploy?path=xxx==true HTTP/1.1

2. Target-Tomcat's logging identifies the upload-user in this line:
02-Feb-2020 16:57:06.433 FINE [http-nio-80-exec-5] 
org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking 
constraint 'SecurityConstraint[Text Manager interface (for scripts)]' against 
PUT /text/deploy --> true

3. The user is authenticated in this log-line:
02-Feb-2020 16:57:06.446 FINE [http-nio-80-exec-5] 
org.apache.catalina.realm.CombinedRealm.authenticate Authenticated user [XXX] 
with realm [org.apache.catalina.realm.UserDatabaseRealm]

4. Tomcat is starting deployment:
02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] 
org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web 
application 'XXX'

5. Tomcat points out the deployment command:
02-Feb-2020 16:57:06.610 FINE [http-nio-80-exec-6] 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [PUT 
/manager/text/deploy?path=XXX==true HTTP/1.1

6. Tomcat show the deployment-request size of ~71 MB
Content-Length: 74784695



Then the socket is closed:
02-Feb-2020 16:57:06.603 FINE [http-nio-80-exec-5] 
org.apache.tomcat.util.net.NioEndpoint.close Socket: 
[org.apache.tomcat.util.net.NioChannel@33ae9b28:java.nio.channels.SocketChannel[closed]]
 closed

7. Access log shows the PUT command (AGAIN!!!):
02-Feb-2020 16:57:06.610 FINE [http-nio-80-exec-6] 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [PUT 
/manager/text/deploy?path=xxx==true HTTP/1.1

Please notice the two deployment threads: -6 and -5

Any ideas?

Kind regards

Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 20 9930560
Fax: 0049 (0)30 / 20 9930561
Handy: 0049 (0)176 / 8 7521576

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

Re: [OT] Install Comodo SSL in Tomcat

[Peter Kreuser]

Chris,

> Am 28.01.2020 um 18:02 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
>> On 1/28/20 11:30 AM, Peter Kreuser wrote:
>> Peter Kreuser
>>> Am 28.01.2020 um 16:34 schrieb Christopher Schultz
>>> :
>>> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> Peter,
>>> 
>>>>>>> On 1/27/20 3:35 PM, logo wrote:
>>>> Could you try openssl pkcs12 -export -in my.crt -inkey my.key
>>>> -name tomcat -certfile my.ca-bundle -out my.jks  <<—  the
>>>> output of pkcs12 is already a jks!!!  and -name tomcat is the
>>>> alias
>>> 
>>> openssl cannot generate JKS files (fortunately!). If there is a
>>> format worse than PKCS12, it's JKS. pkcs12 creates PKCS12 files.
>> Oh I remember that... Dang. Never mind JKS,
>> 
>>> Java can read PKCS12 files and they are even deprecating JKS and
>>> JCEKS in favor of PKCS12, so you don't even have to use keytool
>>> anymore.
>> 
>> That was my point. With the openssl oneliner, tomcat/java would be
>> able to read the created p12 file. So name it appropriately my.p12
>> and Léonard should be fine, right?
> 
> You have to say certificateKeystoreType="PKCS12" (for ,
> or keystoreType="PKCS12" for ) as well in your config.

You don‘t need that in the new SSLHostConfig, right? I don‘t have that 
attribute and it works... ???

Peter

> - -chris
> 
>>> -BEGIN PGP SIGNATURE- Comment: Using GnuPG with
>>> Thunderbird - https://www.enigmail.net/
>>> 
>>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wVGYACgkQHPApP6U8 
>>> pFhaXw//dJcRnA6Q8HUWWgubTA6jlPu85e4LoOxk4qExgCD9P5z3YnqS1Y6YqsmP 
>>> yrTykv/A2vA84ZgAetDU1IASQ08MYXsl4poSFMMOdLRPKEd1MlBzWo+yfR0+e79M 
>>> fWaZ6TbSioXTktWyLZspAaAM5ElFsvgRpktY6pY1+R042BoIj/NwQOsN7OiWWPE+ 
>>> sJVFRODD9cZ45MvuRdCli07hDqBmFrpOCdYYz2FIp2ANdce2N4W8GF64AgnQ5K6T 
>>> 6ofA5HeLjWLmJgrrPuO09lNF2DROufBICz6sDP81UdrfLYEYQO2csFQx+8VSArFy 
>>> Ph3iEp17HR/hkf3ztRe+5frXQxba9vKHyzVrT3nDjMCvVTUUN41kOd41PkAmyqAx 
>>> Jy6hAwRRiXP5a47g7RXfNF5wDzY7taKVwVblRLa8qrzi3ub3VYmpdIH29g0b3W8F 
>>> YbTMTQLUyzDog4yPyTcGwDqkBw8B9Z9dOg+ak005mrjsGBBx/FDpSvgQo0kOvmrG 
>>> YvrUvShrnBpPM3BC27Y46WnqwrJMGbrk2FeHtlvrlND+QFZ50IiTf/VPBGisN8+h 
>>> pjUcC1UfvTWgH6YpBtdjSJkAjJZAQWchGG1WflR4St1aIyML95yDkZQcbrLHzgN/ 
>>> hgzocAzSWakkYppdwzgfuIdwpOsjzh1ld5fuoo0ibwhpBQdmMew= =NdCj 
>>> -END PGP SIGNATURE-
>>> 
>>> -
>>> 
>>> 
> 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
>> 
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4waQgACgkQHPApP6U8
> pFg1BhAAl9GJyuglklWROZOWmor0dOQoFtPsPqDi/4FvGiU9QbbodNJv2FEfa+To
> XU3VpD9AfUasuRcNcvvWaYCg+wsbeglYvp94RtO++mQsT7uMqJ1efynWJ+YH/Hbd
> aTgD9GFIzQjBWpo/5OU9ws2kxGlKKRM+z8haQ0MklRY6R84IZKN7IW7B0Xm4uuWn
> +qfBapA0j8SJQ6RQiA5paujFTmx3WYW1rVMSZR7lXcxwLs1lrvaRWvWN4gUMhqA+
> QHf9LZATcA4FDj5vkWetMN4pbC266rTdKMl4Uss0WeED6u2CmX/tCfWA3hqc1tL5
> 2WyZTnnuT8n5SIXRFaqlqMP29PHXE9vTjvZ/ydsUNB72vOh6C3ucFShs98mu5rNW
> WtC0k1Z7pBwh9pIkeFUY1d/p2AkWxHG4lfTN9fiE60nXn317xGhKQzYx46DSbibq
> qum/RVt98uzM2pft9a76n+xhA+YBb0Poq+4XpIWb6wIVrJ6GV8AAwX1s3vDXMjvR
> IC8MsR1nI3YD69slKH6q1zzQsAuh6+qGbNG3DnQYP+WsTwuD0LlGcjkGwPyUMceo
> A7BioOSzdVtiwMjtsYAGux/9auc3403vPb3GPXOXBvjP23x7eGW4PZhTlT7k2DRg
> P5WpfVUPyZ0tJU41xA+eEQ/iBMg0Qn8sOAYy+FQf8obhrUgybpw=
> =Z1+f
> -END PGP SIGNATURE-
> 
> -
> 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] Install Comodo SSL in Tomcat

[Peter Kreuser]

Chris,



Peter Kreuser
> Am 28.01.2020 um 16:34 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
>>>>> On 1/27/20 3:35 PM, logo wrote:
>> Could you try
>> openssl pkcs12 -export -in my.crt -inkey my.key -name tomcat
>> -certfile my.ca-bundle -out my.jks  <<—  the output of pkcs12 is
>> already a jks!!!  and -name tomcat is the alias
> 
> openssl cannot generate JKS files (fortunately!). If there is a format
> worse than PKCS12, it's JKS. pkcs12 creates PKCS12 files.
Oh I remember that... Dang. Never mind JKS,

> Java can read PKCS12 files and they are even deprecating JKS and JCEKS
> in favor of PKCS12, so you don't even have to use keytool anymore.

That was my point. With the openssl oneliner, tomcat/java would be able to read 
the created p12 file.
So name it appropriately my.p12 and Léonard should be fine, right?

Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wVGYACgkQHPApP6U8
> pFhaXw//dJcRnA6Q8HUWWgubTA6jlPu85e4LoOxk4qExgCD9P5z3YnqS1Y6YqsmP
> yrTykv/A2vA84ZgAetDU1IASQ08MYXsl4poSFMMOdLRPKEd1MlBzWo+yfR0+e79M
> fWaZ6TbSioXTktWyLZspAaAM5ElFsvgRpktY6pY1+R042BoIj/NwQOsN7OiWWPE+
> sJVFRODD9cZ45MvuRdCli07hDqBmFrpOCdYYz2FIp2ANdce2N4W8GF64AgnQ5K6T
> 6ofA5HeLjWLmJgrrPuO09lNF2DROufBICz6sDP81UdrfLYEYQO2csFQx+8VSArFy
> Ph3iEp17HR/hkf3ztRe+5frXQxba9vKHyzVrT3nDjMCvVTUUN41kOd41PkAmyqAx
> Jy6hAwRRiXP5a47g7RXfNF5wDzY7taKVwVblRLa8qrzi3ub3VYmpdIH29g0b3W8F
> YbTMTQLUyzDog4yPyTcGwDqkBw8B9Z9dOg+ak005mrjsGBBx/FDpSvgQo0kOvmrG
> YvrUvShrnBpPM3BC27Y46WnqwrJMGbrk2FeHtlvrlND+QFZ50IiTf/VPBGisN8+h
> pjUcC1UfvTWgH6YpBtdjSJkAjJZAQWchGG1WflR4St1aIyML95yDkZQcbrLHzgN/
> hgzocAzSWakkYppdwzgfuIdwpOsjzh1ld5fuoo0ibwhpBQdmMew=
> =NdCj
> -END PGP SIGNATURE-
> 
> -
> 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

Antwort: Tomcat 7: Access Valve pattern cipher, SSL Protocol

[Peter Köhler]

Hi Palod,

i think you can do it with:

JAVA_OPTS="$JAVA_OPTS  -Djavax.net.debug=ssl,handshake"

Regards

peter



Von:"Palod, Manish" 
An: "users@tomcat.apache.org" 
Datum:  16.01.2020 15:58
Betreff:Tomcat 7:  Access Valve pattern  cipher, SSL Protocol



Hi All,

I am using tomcat 7 and for audit purpose, want to see cipher and SSL 
protocol used in the request.

How should I mention these attributes in the Access Valve pattern to get 
these info in the logs.

Regards
Manish

Fw: Antwort: Tomcat9, JSP, CSS and JS not loading in Firefox

[Peter Köhler]

- Weitergeleitet von Peter Köhler/BN/DWD am 15.01.2020 15:50 -

Von:Peter Köhler 
An: "Tomcat Users List" 
Datum:  15.01.2020 15:49
Betreff:Antwort: Tomcat9, JSP, CSS and JS not loading in Firefox



Von:Léa Massiot 
An: users@tomcat.apache.org
Datum:  15.01.2020 15:40
Betreff:Tomcat9, JSP, CSS and JS not loading in Firefox



Hello,

My question is about loading a JSP page in Firefox (or Google Chrome) and
not having the CSS loaded and the JS operational.

I am using Tomcat v9.0 and Eclipse Java EE IDE v.2019-12 (4.14.0).
When I'm developing using Eclipse IDE, I usually:
- select a JSP in the "WebContent" directory in the Eclipse workspace, 
- right-click, 
- select "Debug/Run As -> Debug/Run on Server"
and the Webapp starts debugging/running.

With the URL "http ://localhost//.jsp", the page gets
displayed correctly in the Web browser that Eclipse "embeds" (maybe I.E., 
I
don't know).
In Internet Explorer, the page is displayed correctly too.

Now, if I copy this same URL "http ://localhost//.jsp" 
in
Firefox or Google Chrome, it's like the CSS is not applied to the page, 
and
the Javascript code doesn't run when it should.

Note that I didn't use to have that problem before I upgraded Eclipse and
Tomcat (I used Tomcat v.8 before).

Below is the beginning of the JSP page:

--
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http ://java.sun.com/jsp/jstl/core"%>



  





 


  ${initParam['S_IF_MSG_TITLE_WELCOME']}



  
--

Also in Firefox, I pressed Ctrl + Shift + k and saw the error message:
--
The stylesheet http ://localhost/fr/css/fo.css was not loaded because its
MIME type, “text/html”, is not “text/css”.
--

and the warning:
--
The script from “http ://localhost/fr/js/fo.js” was loaded even though its
MIME type (“text/html”) is not a valid JavaScript MIME type.
--

Can you help me solve that problem? 

Best regards.
--
Léa

P.S. I added a space after each occurrence of the pattern "http" in this
message.



--
Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html

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



Dear Lea,

maybe 
https://stackoverflow.com/questions/48248832/stylesheet-not-loaded-because-of-mime-type
 

helps.

Regards

Peter

Antwort: Tomcat9, JSP, CSS and JS not loading in Firefox

[Peter Köhler]

Von:Léa Massiot 
An: users@tomcat.apache.org
Datum:  15.01.2020 15:40
Betreff:Tomcat9, JSP, CSS and JS not loading in Firefox



Hello,

My question is about loading a JSP page in Firefox (or Google Chrome) and
not having the CSS loaded and the JS operational.

I am using Tomcat v9.0 and Eclipse Java EE IDE v.2019-12 (4.14.0).
When I'm developing using Eclipse IDE, I usually:
- select a JSP in the "WebContent" directory in the Eclipse workspace, 
- right-click, 
- select "Debug/Run As -> Debug/Run on Server"
and the Webapp starts debugging/running.

With the URL "http ://localhost//.jsp", the page gets
displayed correctly in the Web browser that Eclipse "embeds" (maybe I.E., 
I
don't know).
In Internet Explorer, the page is displayed correctly too.

Now, if I copy this same URL "http ://localhost//.jsp" 
in
Firefox or Google Chrome, it's like the CSS is not applied to the page, 
and
the Javascript code doesn't run when it should.

Note that I didn't use to have that problem before I upgraded Eclipse and
Tomcat (I used Tomcat v.8 before).

Below is the beginning of the JSP page:

--
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http ://java.sun.com/jsp/jstl/core"%>



  





 


  ${initParam['S_IF_MSG_TITLE_WELCOME']}



  
--

Also in Firefox, I pressed Ctrl + Shift + k and saw the error message:
--
The stylesheet http ://localhost/fr/css/fo.css was not loaded because its
MIME type, “text/html”, is not “text/css”.
--

and the warning:
--
The script from “http ://localhost/fr/js/fo.js” was loaded even though its
MIME type (“text/html”) is not a valid JavaScript MIME type.
--

Can you help me solve that problem? 

Best regards.
--
Léa

P.S. I added a space after each occurrence of the pattern "http" in this
message.



--
Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html

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



Dear Lea,

maybe   
https://stackoverflow.com/questions/48248832/stylesheet-not-loaded-because-of-mime-type
 
helps.

Regards

Peter

Tomcat9.0.16 on RHEL 7: ssl and javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

[Peter Köhler]

Dear Sirs,

i have a  alfresco 6 on tomcat 9.0.16 and java  1.8.0_212-b04 on a RHEL 7 
environment.

The  ssl connector inside server.xml is:



I have a  tomcat-users.xml  with an entry like:




The solr client runs on a VM with the name lmssolr12-dev . It sends a  ssl 
Certificat with an certificate common name ‘Alfresco Repository’  to the 
alfresco server


which is defined inside tomcat-users.xml .


But java in the version 1.8 don t care about the tomcat ssl configuration 
and gives me the ERROR:

Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not 
authenticated

Caused by: javax.net.ssl.SSLException: hostname in certificate didn't 
match:  != 


The java configuration inside catalina.sh is:

  JAVA_OPTS="$JAVA_OPTS -Dsun.security.ssl.allowUnsafeRenegotiation=true 
-Djavax.net.ssl.keyStore=/web/data/alfresco/keystore/ssl.keystore 
-Djavax.net.ssl.keyStorePassword=kT9X6oe68t 
-Djavax.net.ssl.keyStoreType=JCEKS 
-Djavax.net.ssl.trustStore=/web/data/alfresco/keystore/ssl.truststore 
-Djavax.net.ssl.trustStorePassword=kT9X6oe68t 
-Djavax.net.ssl.trustStoreType=JCEKS -Djavax.net.debug=ssl,handshake 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources"


I have thought that clientAuth="want"  andsslProtocol="TLS"  allow 
X509 authentification  over tomcat-users.xml .


What  can i do to solve that problem?

Thanks

Peter

Re: TC8 -> TC9 KeyAlias SSL not supported?

[Peter Kreuser]

Peter,

> Am 13.01.2020 um 16:49 schrieb Peter Rader :
> 
> 
>> Peter,
>> Can you find what you are looking for here?
>> 
>> > 
>> ?
> 
> No! There is no such node or any similar content. And there simply can not be 
> such a node because all the connector-xml-nodes are self-closing as you might 
> have already noticed. AFAIK I should not create this SSLHostConfig because it 
> is created automatically somehow according to the deprecated xml-node 
> "keyAlias" (see: 
> https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2_(deprecated)
>  )!

Sure it can... look closely. We‘re talking about



   

Best regards
Peter
> -
> 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: Re: TC8 -> TC9 KeyAlias SSL not supported?

[Peter Rader]

> Peter,
>
> Can you find what you are looking for here?
>
> 
>  
>
> ?

No! There is no such node or any similar content. And there simply can not be 
such a node because all the connector-xml-nodes are self-closing as you might 
have already noticed. AFAIK I should not create this SSLHostConfig because it 
is created automatically somehow according to the deprecated xml-node 
"keyAlias" (see: 
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

Aw: Re: TC8 -> TC9 KeyAlias SSL not supported?

[Peter Rader]

> > I recently moved from T8 to T9 to use PKI.
>
> Exact versions?

T8 = 8.5.50.0 on amazon-corretto-8.232.09.1-linux-x64
T9 = 9.0.30.0 on amazon-corretto-8.232.09.1-linux-x64

>
> > My keystore contains multiple CAs.
> >  
> > I had to modify the ssl-connector from 
> >   org.apache.coyote.http11.Http11Protocol
> > to 
> >   org.apache.coyote.http11.Http11NioProtocol
>
> Full Connector configurations (with sensitive data masked)?

TC8=


TC9=


Masks: 
- XXX keystore CA
-  keystore or truststore
- X password for keystore/truststore

>
> Mark

Peter

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

TC8 -> TC9 KeyAlias SSL not supported?

[Peter Rader]

I recently moved from T8 to T9 to use PKI.
 
My keystore contains multiple CAs.
 
I had to modify the ssl-connector from 
  org.apache.coyote.http11.Http11Protocol
to 
  org.apache.coyote.http11.Http11NioProtocol
 
Unfortunately the attribute "keyAlias" seems to not be supported in the NIO 
anymore. 
 
SSL is not valid anymore because the wrong keyAlias is choosen.
 
Any ideas how to select the correct key?

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

Re: [OT] Re: Maven Warning. Ubuntu Users

[Peter Kreuser]

Zahid,

you‘re talking to one of the most respected members of the community like this?

STFU or leave.

This calls for an ban!

Peter

> Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
> 
> 
>> 
>> A version of what?
> MAVEN
> MAVEN
> MAVEN
> 
> In light of this video https://youtu.be/idViw4anA6E
> Of http.
> 
> You and your let's encrypt must be the longest troll on this line.
> 
> Take your wares and peddle them somewhere else carpet beggar.
> 
> 
> 
> 
>> On Wed, 8 Jan 2020, 01:12 Christopher Schultz, 
>> wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Zahid,
>> 
>>> On 1/6/20 3:13 PM, Zahid Rahman wrote:
>>> That must be the reason why Apache Netbeans is using a version from
>>> 2015
>> 
>> A version of what?
>> 
>>> and Apache Struts is recommending to use jdk 8.
>> Apache Struts 2.5.x supports Java 7 and later. I see no official
>> documentation recommending a specific Java version over any others.
>> 
>>> Because there is somebody like you keeps telling people it is off
>>> topic and Giant IT companies are not releasing jdk further than JDK
>>> 8.
>> 
>> Maybe just not for free.
>> 
>> https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads
>> - -5672538.html
>> https://www.azul.com/category/java13/
>> 
>> Admittedly, Oracle's JDK/JRE is based upon
>> https://openjdk.java.net/projects/jdk/13/ so maybe that doesn't count
>> as a separate release.
>> 
>> But no, IBM doesn't appear to have a new version beyond Java 11.
>> 
>>> The issue is a miserable and disgraceful failure in coordination by
>>> Apache Foundation.
>> 
>> So you found a problem with a package provided by Ubuntu/Debian, and
>> your solution was to install the official Maven package from the
>> Apache Software Foundation. And your conclusion is that the ASF is the
>> miserable and disgraceful party, here?
>> 
>> I'm so confused.
>> 
>> It's worth pointing-out that there is no enforced coordination between
>> ASF projects. Some of them work together in almost lock-step, like APR
>> and httpd. Others are completely de-coupled. Some ignore each other
>> (e.g. Apache Maven and Apache Tomcat). It's up to the individual
>> projects to determine if/how they will work together.
>> 
>> You may wish to read a little more about the ASF before you make
>> blanket statements about it.
>> https://community.apache.org/projectIndependence.html
>> 
>> If you are dissatisfied with the ASF communities (or maybe just a few
>> in particular), may I suggest that you take one of these two courses
>> of action:
>> 
>> 1. Volunteer to improve the situation. Usually in the form of
>> patches/PRs to that project.
>> 
>> 2. Take your complaints elsewhere.
>> 
>> - -chris
>> 
>>>> On Mon, 6 Jan 2020, 19:45 Mark Thomas,  wrote:
>>> 
>>>> On 06/01/2020 18:37, Zahid Rahman wrote:
>>>>> To all ubuntu Maven  users.
>>>> 
>>>> This is off-topic for this mailing list.
>>>> 
>>>> Please keep posts on this list on topic.
>>>> 
>>>> Thanks,
>>>> 
>>>> Mark
>>>> 
>>>> 
>>>>> 
>>>>> Do NOT  install maven using sudo apt install maven
>>>>> 
>>>>> Install by  direct download  only  from
>>>>> https://maven.apache.org/download.cgi
>>>>> 
>>>>> BECAUSE:
>>>>> 
>>>>> "I seem to remember they [ubuntu] have their own build of Maven
>>>>> which differs from the Apache source.
>>>>> 
>>>>> ( https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1754602
>>>>> suggests it's a known bug in their packaging/build? )
>>>>> 
>>>>> If you download Maven from http://maven.apache.org/download.cgi
>>>>> and
>>>> follow
>>>>> the instructions in http://maven.apache.org/install.html then
>>>>> you
>>>> shouldn't
>>>>> see those warnings. " ‐---
>>>>> 
>>>>> The Java 11 warning mentions that
>>>>> "/usr/share/maven/lib/guice.jar" has a class named
>>>>> "com.google.inject.internal.cglib.core.$ReflectUtils$1"
>>>>> 
>>>>> This looks suspect because the official Maven distri

Re: Ignore duplicate HTTP headers in Tomcat 8.5.50-0+deb9u1

[Peter Kreuser]

Mark,

maybe this getting offtopic.

> Am 07.01.2020 um 18:58 schrieb Mark Thomas :
> 
> On 07/01/2020 16:22, Christopher Schultz wrote:
> 
> 
> 
>> Since the Host header seems to be special in this regard (i.e. there
>> is no prohibition against multiple Accept headers), might we be
>> willing to interpret the spec in a slightly less strict manner?
>> 
>> "
>> A server MUST respond with a 400 (Bad Request) status code to any
>> HTTP/1.1 request message that lacks a Host header field and to any
>> request message that contains more than one Host header field [[WITH A
>> CONFLICTING VALUE]]] or a Host header field with an invalid field-value.
>> "
>> 
>> So a request with:
>> 
>> Host: foo.bar.com
>> Host: foo.bar.com
>> 
>> Would be okay, while:
>> 
>> Host: foo.bar.com
>> Host: bar.foo.com
>> 
>> Would return a 400 response?
> 
> Not sure.
> 
> The usual concern with multiple headers is that a reverse proxy uses
> one, the back-end uses another and you get unexpected behaviour that may
> result in some sort of information leak - i.e. a vulnerability. That
> shouldn't apply here since the values are the same.
> 
> Experience suggests that being more relaxed about parsing an HTTP
> request that the specification requires is likely to result - at some
> point in the future - with a vulnerability report.
> 

> In this instance I can image some other server somehow merging the two
> header values and - essentially - treating it as a different value to
> Tomcat. That could lead to a similar information disclosure as above.
> 

I didn’t think that far! However, if they are the same and tomcat would also 
have to respond to the given host, that would be extremely unlikely...


> The usual counter argument is that there is no vulnerability if the
> other server is spec compliant. But the same is true if Tomcat is spec
> compliant.
> 
> I certainly wouldn't support this behaviour by default.
> 

Agreed.

> Making the behaviour configurable is possible so it could be enabled
> when necessary and safe to do so (i.e. clients connecting directly to
> Tomcat). That then gets you to the question how complex would this be to
> implement and is that complexity justified by the benefit it brings?
> 
Just thinking how to handle “n” Host headers at various locations in the 
request... 8-0

> At this point, I'm not sure.
> 
> So far we are looking at a feature required by a single user to handle
> clearly non-spec compliant clients. I lean more towards a custom
> protocol / processor implementation when a single user is affected.
> 
That’s true.

Could this be a documented “extra”? Like a drop-in Jar?

Peter

> 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

Re: Ignore duplicate HTTP headers in Tomcat 8.5.50-0+deb9u1

[Peter Kreuser]

Chris (and Mark),



> Am 07.01.2020 um 17:22 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Mark,
> 
>> On 1/7/20 4:36 AM, Mark Thomas wrote:
>>> On 07/01/2020 07:10, Dennis Rech wrote:
>>> POST /foo HTTP/1.1 Host: foo.com POST /foo HTTP/1.1 Host:
>>> foo.com Content-[stuff] [...]
>> 
>> First two lines are OK.
>> 
>> The third line is going to be treated as an HTTP header. It is
>> invalid and Tomcat will reject it with a 400 response but you can
>> tell Tomcat to just ignore the invalid header with
>> rejectIllegalHeaderName="false" on the Connector.
>> 
>> The problem is going to be the second Host header.
>> 
>> RFC 7230 states:
>> 
>>  A server MUST respond with a 400 (Bad Request) status code
>> to any HTTP/1.1 request message that lacks a Host header field and
>> to any request message that contains more than one Host header
>> field or a Host header field with an invalid field-value. 
>> 
>> Any spec compliant server is almost certainly going to reject that 
>> request. I guess a server might provide a hook for request
>> modification prior to rejection to allow the "fixing" of known
>> invalid requests but I'm not aware of any that do - at least not
>> without going down the writing a custom module route.
>> 
>> If we made Http11Processor.prepareRequest() protected then it would
>> be fairly simple to write a custom Processor that: - extended
>> Http11Processor - overrode prepareRequest() to a) remove the
>> duplicate Host header b) call super.prepareRequest()
>> 
>> I could provide one for you if you weren't comfortable doing that 
>> yourself). However, even if we made the change now (which I'm happy
>> to do if you think it would be useful) it will take a while to
>> filter through to the Debian distribution.
>> 
>> There are several variations on this theme. One could write a
>> custom Processor for 8.5.50 that did the same thing - it would just
>> be rather more involved as one would have to copy rather more code
>> from Http11Processor.
> 
> Since the Host header seems to be special in this regard (i.e. there
> is no prohibition against multiple Accept headers), might we be
> willing to interpret the spec in a slightly less strict manner?
> 
> "
> A server MUST respond with a 400 (Bad Request) status code to any
> HTTP/1.1 request message that lacks a Host header field and to any
> request message that contains more than one Host header field [[WITH A
> CONFLICTING VALUE]]] or a Host header field with an invalid field-value.
> "

That would be a good idea - maybe only in conjunction with setting 
rejectIllegalHeaderName=false

If that makes the implementation easier???


> 
> So a request with:
> 
> Host: foo.bar.com
> Host: foo.bar.com
> 
> Would be okay, while:
> 
> Host: foo.bar.com
> Host: bar.foo.com
> 
> Would return a 400 response?
> 

That would be a messed up request and worth a 400!

Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4UsEEACgkQHPApP6U8
> pFjprxAAi60mVwH+LHo2HSCl+hwIhIyG2B9Dg2LjIJ8JPMA/WxaiDOOJCS+yMTbV
> rVfdPrlT0B6Zd8ceTjz4ooZa79SwPFfCiFM97q1H/JwwsqVxaBEFEx6PgvnJzUUF
> ZuJJEtQHijQgZo0gXv2plkqHTBrG5NMPNqQYEJ8aZqdjtSvtNkP2E03agVC/8SqW
> mNyERNFcyOP3hUlNHSghPXl81ckSabqa83rLrwFCZQGJ2U71EnnietYxXT5Dz6Kx
> W03z8HY2mClTETmZB/WvkCmG0F1AXQ8Xr2E4fJ2+meyNHgTZ2XjfYsKtZNKTQmiC
> zlDgweuXuQ1r6DorLB4MUCm7HMffeDTwKEHBaYkIt7reHN8yGfT8sq1F8A0ZDKHi
> y9Ugt0KwePPOGFK8mfST7lBWojPJL1wbyBVAYh+FL5f1hMScOdHRxbU9uz2p9NSB
> RMubUWNCD1p8+sI8bLjQ//vU/iCLcWg7RStr/FSfXZEqjJv6EZ4OaNafahTcxvey
> 37Qz/eVTJQGeYa0+1rBvttVZJB6xrJwcscC3dgskTJ8VXJuAnwK0WdmMRzD7XLos
> HP13SOoLXUgek07XH61OPq5dnbpUwq996GqpSLldLUJlCnbMi1vxkAmGe006zVXH
> GWPoV1d4r7p0JjkyBlGQYUwiltuDFyNOx9uRS5FTaapaarhY6G0=
> =Z571
> -END PGP SIGNATURE-
> 
> -
> 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: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?

[Peter Kreuser]

James,

> Am 07.01.2020 um 03:11 schrieb James H. H. Lampert :
> 
> Dear Mr. Schultz, et al.:
> 
> The manager password on this Tomcat server has an embedded curly brace, and 
> an embedded question mark.
> 
> If I do this (the names have been changed to protect the innocent, and the 
> -k!)
> 
>> curl -k 
>> "https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs;
> 
> I get curl: (3) [globbing] unmatched brace in column xx
> 
> If I change the curly brace to "%7B," I get:
> 
>> curl -k 
>> "https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs;
> 
> I get curl: (3) Port number ended with 'n'
> 
> And if I put the user-ID and password in with a -u clause on curl, rather 
> than in the URL itself, I get "Unauthorized."
> 
> What is wrong here? Are there characters it simply can't tolerate in 
> passwords, even if URL-escaped?

I‘d prefer them in -u.

for separation of concerns, add a separate user with a longer one and shell 
friendly password only with the role below...

> Or do I need to give the manager user an additional role? Currently, I have:
> 

manager-jmx 
(and maybe for other script-actions manager-script)

Peter

> --
> JHHL
> 
> -
> 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: Breakthrough, Re: Let's Encrypt with Tomcat?

[Peter Kreuser]

James,



>> Am 06.01.2020 um 22:28 schrieb James H. H. Lampert 
>> :
>> 
>> I think I found something, with the help of "MLu" on ServerFault:
>> 
>> He advised me to try "iptables -L" and "iptables-save" again, only this time 
>> "sudo" them.
>> 
>> When I did "iptables -L" under root privileges, I still only got column 
>> headings, but when I did "iptables-save" under root privileges, I hit what 
>> appears to be paydirt:
>> # Generated by iptables-save v1.4.18 on Mon Jan  6 21:17:22 2020
>> *filter
>> :INPUT ACCEPT [5018099:5766179544]
>> :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [400:2863742410]
>> COMMIT
>> # Completed on Mon Jan  6 21:17:22 2020
>> # Generated by iptables-save v1.4.18 on Mon Jan  6 21:17:22 2020
>> *nat
>> :PREROUTING ACCEPT [41828:2351495]
>> :INPUT ACCEPT [76356:4167904]
>> :OUTPUT ACCEPT [254990:18418937]
>> :POSTROUTING ACCEPT [254990:18418937]
>> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
>> COMMIT
>> # Completed on Mon Jan  6 21:17:22 2020
> 
> Other than the one obvious line near the bottom,
>> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
> I'm not entirely sure what all of this means, nor do I remember what I did to 
> set it up.

Heureka! 

So you may add the like for Port 80 and you are set for LE!

Peter

> --
> JHHL
> 
> -
> 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: Let's Encrypt with Tomcat?

[Peter Kreuser]

Chris & James,

Sorry for topposting.

Is Tomcat really the SSL endpoint that takes the cert? Then it wouldn’t matter 
if there is a loadbalancer or the like.
Maybe it’s just authbind or iptables natting? that would be a common way to 
have a non-root service to listen externally on 443.
If not and there is a proxy like apache or nginx, the way to handle certbot 
would be completely different, right?
Like James said before he uses the cert also on apache! But how do you separate 
443 for the services you have on apache and tomcat?

However, we still need the port 80 endpoint to deploy the acme-challenge to! No 
way around that without DNS-01 or TLS-ALPN-01, which are only complicating the 
process!

if httpd is serving your hostname on port 80 and you are able to write to 
httpd-webroot, point certbot’s —webroot to that directory.

if httpd is not on port 80, you could do the same that you did for 443 
forwarding to redirect 80 to tomcat port 8080.

IIKS, hope I was not too confusing???

Peter



Peter Kreuser
> Am 30.12.2019 um 20:01 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> James,
> 
> On 12/27/19 17:07, James H. H. Lampert wrote:
>>>> As it happens, one way or another (and I'm not entirely sure
>>>> *which* way; I'd have to look at my notes), we *do* have
>>>> Tomcat listening directly on 443 (but not 80; nothing there is
>>>> currently listening on 80) on that particular EC2 instance (and
>>>> I'm pretty sure we have HTTPD running on a *different* port,
>>>> for the SVN and Trac sharing the box).
>> Hmm. It seems I was mistaken about two things: (1) that the Tomcat
>> server under discussion is listening *directly* on 443, and (2)
>> that I could find my notes on how I set the box up.
>> What I can find is the server.xml file, and the active connector
>> definition:
>> > protocol="org.apache.coyote.http11.Http11NioProtocol" . . .
>> clientAuth="false" sslProtocol="TLS" />
>> The thing that catches my eye is port="8443" proxyPort="443"
>> I hope that indicates how it is I'm getting this to look like port
>> 443 to the outside world, because I honestly can't remember what I
>> did (even though it looks like it's only been six months since I
>> did it).
> 
> This means that you are listening on port 443, but when Tomcat builds
> URLs for redirection, etc. the port 443 will be used (and, actually,
> as likely secure="true", then the port will be omitted because the
> default port for https is 443 of course).
> 
> There is no proxying going on in Tomcat; this configuration is named
> for the use-case: you must have a reverse-proxy somewhere which is
> terminating TLS (and likely re-establishing a separate secure link
> with Tomcat, since sslProtocol="TLS" in your config). It's probably a
> load-balancer which is essentially synonymous with a reverse-proxy in
> this context. It's possible to have one without the other, but they
> are often performing both functions.
> 
> netstat on *NIX should give you the IP(s) of the clients, so you can
> probably pretty easily see the IP address of the reverse proxy.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4KSWsACgkQHPApP6U8
> pFhgpA/+PVIwacQPcjbaHMPwEz+JfVMzZubjzQDxM6u0gSRTpH3z8PRHPvm/DPZN
> FJhNHEZhpbdXVA5ypsg5LIHShqIOh716Rp/mIObIWn2Z+NK2x5uLytBhIOt6w1fZ
> Qsqy4f+jFUesRp3Y5/wWu6plIvB5y3c+RzGVt7Q4fX5XKTMKuP5DueHC57qaY6LL
> V28qwyRQCBPMJV89pb3rKICzQEf8uSCVFjV/xKU7/0IamHKh3MfVXrUikFJB8/ex
> CiHLsmc2FGSxERHvHOPxnKaGA/EFa3Lu3p0VrdSbczsmtS/cCmlrBUz0pmcqQLQ/
> wm0OOfQ2aTvU42E0E3bgc014dOsrC2zugrjGNrZTQqyCXbBN065iZoi9RT3Hl8vN
> lAfS83rF0E4eTNlB2E3qRZTFVGPSaNS5MPnl4RXC8F9c2/vukIY0Xb9DWi4Hf6f+
> 8tSZHer24uD8nR928p78mbiqoI1NMZaM9CwIN0XhJzjb2XzhZF9pgfmjAvbdV8vo
> AtWauUHw1BictxXdVtmZ2xY3dYsK0RDPqX/K9u053rPOfweYTCCVn5lcRUzhITmr
> sf8pP/8vRiXQAIyH0JjvCXJIUIIJGo7xofJQcs2RPA8qt+aukQC3OpB7UdpKOHv0
> P/7zx+mWDyCH5A9fIfT16H6kgRfxoyUi19X6pFMPuzXNpiZP2zU=
> =9vaq
> -END PGP SIGNATURE-
> 
> -
> 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: Let's Encrypt with Tomcat?

[Peter Kreuser]

James,

> Am 28.12.2019 um 00:33 schrieb James H. H. Lampert :
> 
> 



>>> 
>>> Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt" and 
>>> ".key" files directly, instead of the Java Keystore file?

Correct!

> If so, then that could potentially simplify things: if I have HTTPD listen on 
> 80, and Tomcat sharing the same actual certificate and private key *files* 
> that HTTPD uses, then the only other thing I have to automate would be a cron 
> job to either restart Tomcat, or just do a programmatic "re-read TLS 
> configuration," whenever the regular Let's Encrypt job for HTTPD completes.
> 
> Does any of this make any sense at all, or am I sucking antimatter?
> 
> --
> James H. H. Lampert
> 
> -
> 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: Let's Encrypt with Tomcat?

[Peter Kreuser]

Chris,



Peter Kreuser
> Am 27.12.2019 um 21:14 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
>> 
> but the idea is that certbot has "plug-ins" and we'd need to
> supply a "tomcat" plug-in that did things like this. I'm not sure
> where the best place to keep configuration would be. Someone who
> understands certbot (or autobot, etc.) would be a better resource than m
> e.
> 
>>> Or did you think about a bin/version.sh type script? That would
>>> get a +1 from me.
> 
> What do you mean?

Like you said something like tomcatctl graceful that you could just simply call 
from $CATALINA_BASE/bin. Maybe another option to catalina.sh that just calls 
the internals of tomcat.

Restarting the whole tomcat with big webapps is simply not an option.


> 
>>> What I don't like is, that one needs to add credentials in
>>> tomcat-users.xml and expose the manager-interface.
> You can use other authentication mechanisms... it's just that usually
> nobody bothers since it's easy to configure tomcat-users.xml. Exposing
> the manager interface is a bit of pain, but it can be scripted. Our
> deployments install a proper tomcat-users.xml file and enable the
> manager, locked-down to localhost connections.
The way it is right now works. But it’s simply not for the regular admin. The 
frequent questions about the initial setup of the manager app and the clumsy 
jmx activation show that - in my opinion. (We’re not even talking about auth or 
ssl for jmx)!

Peter
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GZh8ACgkQHPApP6U8
> pFjw8hAAqpsfbF/25K9A8l6ZFLoLrO+9C7z+86i1KLI/91VMylTxe/9Im8+Id/jG
> 4AOXOov5m8SvzBQIDnjnSbUrVAvZ9J36pzlH4FoAxDQoZY3DWmyGPPa7S56OKG0g
> Ha3rS5QziBjV9XbSuCL+6hbt4VBLVY0aRT9dvkDahiN42j2cczc2AOi1GxSf1WbY
> iIYO8c1yfJvF/4wo7lBE6WpLRJb3RVI9psRuDm/yaMGY/nBzzNbYvhgB+pM/m0dw
> Ls+w2HC6X8dq+0jV33FH1MdEY6yroH2gapclLcaeJ1yB2uke2cvGo0/vi3MdzOYK
> CndNSfQrXTeyawWcgj4DjQZy9koBeXfdDXC18cFOKLvceMmV6UG8jwSBSVDjhYml
> Ut9W7+GPYn8fBej9I/PaLRB3VAS47pRjY6MjA+AEMZxdowyOiNpc6E5snP4N+J9u
> s3wTL9gfPGIOrrIilSPD9eIIHGExZ5na3FxuVV1grGSOMAq8EoJRn9iCBjyrYwuF
> JsKXtvG2e91r/pvSL/zTDufoZysVvf4aUrgnxA9kY8lp+3O6+3U/5FTLWWtc7Fcj
> ljjb87yda57Zvb/KU95GBakDt8+3fbMMyhHeUAANWrSMPIN5astpacBdDRD5F1KH
> HNW5QTmxG56D0yaM3/pKPpoFBMqojtCen6MO8ZVkSN9Qv4H3NKo=
> =SHiE
> -END PGP SIGNATURE-
> 
> -
> 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: UPDATED: JMX reloadSslHostConfigs fails with javax.management.RuntimeOperationsException

[Peter Kreuser]

Mark,



Peter Kreuser
>> Am 16.12.2019 um 16:05 schrieb Mark Thomas :
>> 
>> On 16/12/2019 12:55, Mark Thomas wrote:
>>> On 15/12/2019 09:33, logo wrote:
>> 
>>> Mark can you confirm that this is a bug?
>> Confirmed.
>> I'm looking at options to fix this now.
> 
> Fixed in:
> - master for 9.0.31 onwards
> - 8.5.x for 8.5.51 onwards
> 
> Thanks for reporting this and for the analysis.
> 
> Mark

That was quick! Thanks for your ongoing support!

Peter

> -
> 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: remote jmx monitoring through ssh tunnel

[Peter Kreuser]

Chris‘,

> Am 10.12.2019 um 18:59 schrieb Chris Cheshire :
> 
> On Tue, Dec 10, 2019 at 11:58 AM Chris Cheshire  wrote:
>> 
>>> On Tue, Dec 10, 2019 at 9:42 AM Christopher Schultz
>>>  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> Chris,
>>> 
>>> On 12/9/19 17:10, Chris Cheshire wrote:
>>>> In CATALINA_BASE/bin/setenv.sh I have the following :
>>>> 
>>>> CATALINA_OPTS="-Dcom.sun.management.jmxremote
>>>> -Dcom.sun.management.jmxremote.ssl=false
>>>> -Dcom.sun.management.jmxremote.authenticate=false"
>>> 
>>> Okay.
>>> 
>>>> In CATALINA_BASE/conf/server.xml I have a listener configured :
>>>> 
>>>> >>> className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
>>>> rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
>>>> useLocalPorts="true" />
>>>> 
>>>> 
>>>> Upon startup I see in logs : INFO [main]
>>>> org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer
>>>> The JMX Remote Listener has configured the registry on port
>>>> [10001] and the server on port [10002] for the [Platform] server
>>>> 
>>>> 

I didn‘t read it anywhere. Did you add the catalina-jmx.jar to the classpath?

Peter

>>>> $ netstat -an | grep 10001 tcp4   0  0  127.0.0.1.10001
>>>> *.*LISTEN tcp6   0  0  ::1.10001
>>>> *.*LISTEN
>>>> 
>>>> On my local machine I have a tunnel set up as follows : ssh -N
>>>> -L10001:localhost:10001 -L10002:localhost:10002 user@remotehost
>>>> 
>>>> (where user is the user tomcat is running under)
>>>> 
>>>> When I try to add a remote JMX connection in VisualVM on my client
>>>> machine to localhost:10001 I get an error dialog after a brief
>>>> delay with the message "Cannot connect to localhost:10001 using
>>>> service:jmx:rmi:///jndi/rmi://localhost:10001/jmxrmi". If I change
>>>> it to port 10002 I get the same error. On the server at this time
>>>> : $ netstat -an | grep 10001 tcp4   0  0  127.0.0.1.10001
>>>> *.*LISTEN tcp6   0  0  ::1.10001
>>>> *.*LISTEN tcp4   0  0  127.0.0.1.62637
>>>> 127.0.0.1.10001TIME_WAIT
>>>> 
>>>> 
>>>> If I try to use jconsole connecting to port 10001 I get the error
>>>> "Connection failed: non-JRMP server at remote endpoint". Connecting
>>>> to port 10002 I get the error "Connection failed: no such object
>>>> in table"
>>> 
>>> You should be using the port defined by rmiRegistryPortPlatform, so
>>> 10001 is the correct port to use.
>>> 
>>>> I've been through the tomcat configuration documentation a couple
>>>> times but I can't see what else I need to configure.
>>> 
>>> What you have looks good to me without reproducing it myself. Can you do
>>> :
>>> 
>>> $ netstat -an | grep 1000[0-9]
>>> 
>>> ?
>>> 
>>> Just to be sure about both ports?
>>> 
>> 
>> $ netstat -an | grep 1000[0-9]
>> tcp6   0  0 :::10001:::*LISTEN
>> tcp6   0  0 :::10002:::*LISTEN
>> 
>> 
>> H. Tomcat is only listening on ipv6 ports, but my tunnel is using
>> ipv4. After digging around [1], I added this to CATALINA_OPTS in
>> setenv.sh
>> 
>> -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true
>> 
>> $ netstat -an | grep 1000[0-9]
>> tcp0  0 0.0.0.0:10001   0.0.0.0:*   LISTEN
>> tcp0  0 0.0.0.0:10002   0.0.0.0:*   LISTEN
>> 
>> When I try to connect with jconsole I get the same error (non-JRMP
>> server at remote endpoint), with the server showing
>> 
>> tcp0  0 0.0.0.0:10001   0.0.0.0:*   LISTEN
>> tcp0  0 0.0.0.0:10002   0.0.0.0:*   LISTEN
>> tcp0  0 127.0.0.1:10001 127.0.0.1:43803 TIME_WAIT
>> tcp0  0 127.0.0.1:10001 127.0.0.1:43815 TIME_WAIT
>> 
>> 
>> I have also updated sshd_config with
&

Re: Global Error Handling

[Peter Kreuser]



Mark,



Peter Kreuser
>>> Am 03.12.2019 um 14:31 schrieb Mark Thomas :
>> On 03/12/2019 12:50, logo wrote:
>> Sumit,
>> Am 2019-12-03 13:11, schrieb Sumit Bhardwaj:
>>> Hi Experts,
>>> We have a requirement from a customer, where in case of 404, where
>>> someone
>>> is putting an invalid url, instead of showing the default error, we
>>> should
>>> be showing a custom message.
>>> Is this possible?
>>> I have searched and found couple of solutions similar to
>>> https://stackoverflow.com/questions/27859626/tomcat-server-change-default-http-404
>>> but these did not work, these work at the app level, but not globally on
>>> tomcat level.
>> this can also be configured on the global web.xml.
> 
> No, it can't. conf/web.xml provides defaults for web applications, not
> global settings.
> 
>> An alternative way
>> would be a CustomErrorReportValve that can be configured on the
>> Host-Element in server.xml.
> 
> It would but, that is an overly complex solution.
> 
> There are two better - in my view - options.
> 
> 1. Deploy a ROOT web application with appropriate error page
> configuration. This will catch all URLs that aren't mapped to any other
> deployed applications.

Wouldn’t the global web.xml provide sort of the same solution - if it‘s really 
Sumit‘s intention to provide a custom 404 page only, for all apps?

The Root-context approach may not work, if you hit a bad request/400, right?


> 2. Use errorCode.0="..." and/or exceptionType.java.lang.Throwable="..."
> attributes of the ErrorReportValve to define static web pages for those
> errors.
> 
> http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Error_Report_Valve/Attributes

That‘s neat! It‘s not available in 8.5 though, that‘s why I used a 
CustomErrorReportValve until now.
good to now, that will indeed remove complexity, as I‘d always have to deploy a 
global lib.

Peter


> 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

Re: Using CsrfPreventionFilter with GET-based submissions

[Peter Kreuser]

Chris,

> Am 13.11.2019 um 02:35 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
>> On 11/10/19 19:05, Peter Kreuser wrote:
>> Chris,
>> 
>>> 
>>> Am 09.11.2019 um 03:58 schrieb Christopher Schultz
>>> :
>>> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> All,
>>> 
>>> I'm playing with the CsrfPreventionFilter and things are working
>>> well in the following situations:
>>> 
>>> link text
>>> 
>>> and
>>> 
>>>  ... 
>>> 
>>> As long as the URL has been passed through request.encodeURL().
>>> 
>>> However, this one is causing me a problem:
>>> 
>>>  ... 
>>> 
>>> This builds a form like this:
>>> 
>>> >> action="https://host/path?org.apache.catalina.filters.CSRF_NONCE=[...
> ]">
>>> 
>>> 
> ...
>>> 
>>> 
>>> Neither Firefox nor Chrome will send the query string present in
>>> a  action attribute if the method="GET". The method must be
>>> "POST" in order for this to be sent. This is due to the HTML
>>> standard[1].
>>> 
>>> Short of changing all  methods to "POST", is there any way 
>>> around this?
>>> 
>>> I have read the code for CsrfPreventionFilter and it does not
>>> appear that the nonce if stored anywhere except in the
>>> CsrfResponseWrapper for the request (and the session's nonce
>>> cache, but that isn't request-specific).
>>> 
>>> Would it be inappropriate to add the CSRF_NONCE to the request 
>>> attributes so that application code could use it directly if 
>>> necessary? Something like this:
>>> 
>>>  ... >> name="org.apache.catalina.filters.CSRF_NONCE" value="<%=
>>> request.getAttribute("CSRF_NONCE") %>" /> 
>> 
>> If i remember correctly, this is the way struts handles CSRF
>> Tokens.
> 
> I'm not sure what Struts has to do with this. I'm using Tomcat's CSRF
> filter which apparently cannot work with GET-based forms. I'm not
> saying that a GET-based form is a good idea, but we have a bunch of
> them so I'm looking into how they can be effectively used with this
> implementation of a CSRF filter.

I just wanted to point out that struts implements the CSRF protection only with 
a hidden field. That’s a bit of a hassle, plus you have to handle this per 
form. Wether it is a POST or a GET.

> I'm really surprised this hasn't come up, yet. Maybe nobody actually
> implements CSRF protection, or maybe nobody uses Tomcat's filter to do
> it, or maybe nobody uses GET-based HTML s. But I can't believe
> that I'm the only person in the world who is trying to use all three
> at once.
> 
>> However there the nonce comes directly from the session . Not 
>> request.
> 
> The nonces are stored in the session, otherwise this wouldn't work.
> But each request generates a new nonce, and that one would be the
> "request's nonce".

That’s another difference to struts and a bit of a nuisance, the nonce is only 
created once (and there is no cache). Once you remove it or generate a new 
nonce, all requests from “old” forms Will fail. But that is another story.

But nevertheless the GET problem would be interesting to figure out. I will try 
this once I’m back from vacation.

Peter
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3K7UkACgkQHPApP6U8
> pFhZBRAAkrD4pr+agtuxblW/UA8ylVm6pceqTmlz8ki39I7k7T5fjgm+Yg1mjG9R
> VgQNI/v0y94rQ3cCjIerUxTTNHTzgHUi2uRk9sSsnTsRXC4W+8wdRSojDSq9j1AB
> z4ZQI3t5Z8+e9RWBDrYOd2TkvW93aGiMzOpcnashvJkhUSDR5102RJtvoz1yAK7r
> Rwzv8feSJRy3/rxjiqQvHYdBH9DeRXVGH0CTP6KZ/+e/icFw0nnH3e+Jrh3+k5du
> fIUi/97JPT0hxkkJbNkKsOJ3P/D4kqzKnbo6WqFr4UwYMCiJizNNTuu+3pG6LAjn
> qTow+EL6/sG3Dtt/VCexyhC7jXdGjcrMDpxcXZx6NwiFxppK2kGWVMi7zKz4qm3X
> ZLR1zSsfzRhUnVPmdjYUAtDonhCbWW+FdQmBtGhGhH7+3wOeXrGpBeWcAq7jjGoD
> rgKQJMKUEN0PMH8j63tgp86Te6zhJCG23/ttBqFTLvP6XWbfHn6KoMFrwSMz8Spz
> EyFDBJihspuFncOMjEJ5kPLmJzs2x811VVkMOBA3BPqIrN2qteTIja9+t3ismo4+
> iBf0sV0q74HL24wvyAfONArae52vFmg4wJLiN38tztNLdoblJpTjqRs04gQ+Q0+5
> u4KKouD6Oz37Zo1Z7IS/HezmfGwYRrZn96CgPzfam4ZQp4Hldi8=
> =mYsp
> -END PGP SIGNATURE-
> 
> -
> 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: Using CsrfPreventionFilter with GET-based submissions

[Peter Kreuser]

Chris,

> 
> Am 09.11.2019 um 03:58 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> All,
> 
> I'm playing with the CsrfPreventionFilter and things are working well
> in the following situations:
> 
> link text
> 
> and
> 
> 
> ...
> 
> 
> As long as the URL has been passed through request.encodeURL().
> 
> However, this one is causing me a problem:
> 
> 
> ...
> 
> 
> This builds a form like this:
> 
>  action="https://host/path?org.apache.catalina.filters.CSRF_NONCE=[...];>
> ...
> 
> 
> Neither Firefox nor Chrome will send the query string present in a
>  action attribute if the method="GET". The method must be "POST"
> in order for this to be sent. This is due to the HTML standard[1].
> 
> Short of changing all  methods to "POST", is there any way
> around this?
> 
> I have read the code for CsrfPreventionFilter and it does not appear
> that the nonce if stored anywhere except in the CsrfResponseWrapper
> for the request (and the session's nonce cache, but that isn't
> request-specific).
> 
> Would it be inappropriate to add the CSRF_NONCE to the request
> attributes so that application code could use it directly if
> necessary? Something like this:
> 
> 
> ...
>  value="<%= request.getAttribute("CSRF_NONCE") %>" />
> 

If i remember correctly, this is the way struts handles CSRF Tokens. However 
there the nonce comes directly from the session . Not request.

Peter

> - -chris
> 
> [1] https://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.4
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3FuqUACgkQHPApP6U8
> pFiRNg/+IIcX8T9/gdui3oGLn3oTWcL2wufs5XN8FUsyYkm9R0Pgj2tzfyHVykF9
> Lqr+jYw6wBmNAo/j319+Wcv7YfN/JHSTKOITvPuquQST4pXYOfYVl4SRBXuqJ7bs
> gI2hTcyH2eUGSk6mSfjD+F4RQ2uigKQgnTXp1XTmFgEW5An/LPxY6o6ruEJ3RbSW
> ceaO9hR4NSBbtB2urT6JsKPAiuZvOy9qELRBoVc54vNLoTqPe2oNUx4AHnq2cRuE
> eKhegWlyj+XYVcVDEK0SK1irmgiN6YVc6Cxyy0QD+pEf0SvPwXeRtvS+3Ucjfpnv
> nQSZDUbia/lXNktMnCiSl3c/ZEfo2AS9br/dlHbWCu5y8ugngaIHrbFPTU5QLNEP
> 0mFjvMYCm4QIqu79/qOyPzDReNpWBuqsLNXfJLbhBG6MuCWLhSzHOLQnmoXb2hmg
> 60vX9/B1/AgZkOv5Uv2EL/AqvyMLH9SnxuR7RVSf4FFoGD8PLpxCGruskb5HoYAr
> IVyLxhzvvbE/ViXXGlwXcfuwaS1EgOXhWZqM+rl8wT1MhHnYd/SX5uGRHqjd43gO
> fuOphdHNC+G5ErCyYqy4urvxyP9vuhipU43O1eUDQV+rRAdI6m+q26gTgA8U+D7i
> LgJ0ZYGj+pzWi7SHyBoKIcA8u1vJrZqBFC6Fa9jlpHgQ/A/1Rtg=
> =Ehsd
> -END PGP SIGNATURE-
> 
> -
> 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: Security issue involving HTTP response headers

[Peter Kreuser]

Hi James,



Peter Kreuser
> Am 02.10.2019 um 08:05 schrieb  
> :
> 
> Tomcat 7.0.63 and above.
> 
> Navigate to the tomcat conf directory and open the web.xml with a text editor.
> 
> In the filter section of the web.xml add the following filter
> 
> 
>   httpHeaderSecurity
>   
> org.apache.catalina.filters.HttpHeaderSecurityFilter
>   
>   antiClickJackingOption
>   SAMEORIGIN
>   
> 

+1

Beware to go with the defaults in a local environment. Set the parameter 
includesubdomains of HSTS to false, or the browsers will redirect any other 
subdomain-site to https! Not easy to get rid of this afterwards!

If you need different values for the headers (x-frame-options), you may also 
copy these settings to your webapp‘s web.xml

Peter

> 
> In the filter mapping section of the web.xml add the following.
> 
> 
>   httpHeaderSecurity
>   /*
>   REQUEST
> 
> 
> 
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Asst Vice President
> 
> Middleware Product Engineering
> Enterprise CIO | Platform Services | 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: jam...@touchtonecorp.com  
> Sent: Wednesday, October 2, 2019 12:35 AM
> To: Tomcat Users List 
> Subject: Security issue involving HTTP response headers
> 
> We have a customer who is particularly concerned about security.
> 
> We just updated their Tomcat, which solved all the issues coming up in their 
> security scan, except for one involving the following HTTP headers:
> 
> X-FRAME-OPTIONS
> X-XSS-PROTECTION
> X-CONTENT-TYPE-OPTIONS
> 
> and strict transport security.
> 
> The environment is Tomcat 7.0.93, JSSE, running on an AS/400.
> 
> Is this something to be fixed in a configuration file, or the webapp, or 
> someplace else?
> -- 
> JHHL
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> B‹CB•È[œÝXœØÜšX™KK[XZ[ˆ\Ù\œË][œÝXœØÜšX™PÛXØ]
> ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ\Ù\œËZ[ÛXØ]˜\XÚK›Ü™ÃBƒ


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

Re: Secure Communication Between Tomcat Servers

[Peter Kreuser]

Isn‘t that what client certs are for?
Https to identify Server A, Client cert to authenticate Server B?

Message integrity should then be unnecessary?!

Or am I missing a piece?

Peter

> Am 09.09.2019 um 21:10 schrieb M. Manna :
> 
> Why not use JWT cookies/tokens? You sign your claims and only you can
> validate the claims and ensure that it’s coming from the right place/user.
> 
> Thanks,
> 
>> On Mon, 9 Sep 2019 at 19:26, Michael Duffy  wrote:
>> 
>> I need to communicate securely between two Tomcat servers running in two
>> different environments.  I have control of both servers.
>> 
>> I would like to do this through a simple REST call from Server-B to
>> Server-A.
>> 
>> On the server I am communicating to, Server-A, I can easily set up HTTPS
>> with a self-signed certificate.  If I import this certificate into the Java
>> Keystore on Server-B, I can make a trusted HTTPS Rest call from my Java
>> code on Server-B.
>> 
>> Good instructions for doing this can be found here:
>> 
>> https://blog.10pines.com/2017/09/25/how-to-communicate-via-https-between-two-tomcat-servers-using-a-self-signed-certificate/
>> 
>> 
>> I would also like to add a confirmation that the Rest call to Server-A is
>> certainly coming from Server-B and the message has integrity.
>> 
>> My plan is to generate a self-signed certificate on Server-B and  import
>> this certificate into the Java Keystore on Server-A.  Then for any REST
>> call from Server-B I will first generate an SHA-512 hash of the message and
>> sign the hash with the private key associated with the Server-B
>> certificate.   When Server-A receives the message, the SHA-512 hash will be
>> recalculated and checked for accuracy of the hash (no message tampering).
>> I will then check the signature of the Hash against the public key of the
>> certificate from Server-B.
>> 
>> For a little bit of extra paranoia I may encrypt the REST message with the
>> public key of the certificate from Server-A; for short messages this should
>> be fine (no need for Symmetric encryption).
>> 
>> Does this seem like a good plan?
>> 
>> Thx in advance for any suggestions.
>> 
>> Mike
>> 


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

Re: Problem with OpenSSL cipher suites -what's wrong with this configuration?

[Peter Kreuser]

Jessica,




Peter Kreuser
> Am 07.08.2019 um 14:33 schrieb Alten, Jessica-Aileen 
> :
> 
> Dear all,
> 
> I have a problem with the Tomcat 9.0.22 configuration for TLSv1.3 using
> jdk8u222-b10_openj9-0.15.1 on Windows Server 2016. In principle TLSv1.3
> works, but I want to specify the allowed cipher suites as well.
> 
> The relevant parts of server.xml are:
>   SSLEngine="on" />
> ...
>maxThreads="150" SSLEnabled="true"
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementat
> ion">
>
>
>  certificateKeystoreFile="D:/ProgramFiles/ApacheSoftwareFoundation/tomcat-bas
> e-8080/conf/keystore-pkcs12.jks"
>   certificateKeystorePassword="mypassword"
> certificateKeystoreAlias="myalias" />
>
> 
> 
> This configuration works!  When I connect to the server, Firefox says under
> technical details: Connection encrypted (TLS_AES_128_GCM_SHA256, 128bit key,
> TLS 1.3).
> 
> But when I try to specify the cipher suites like:  protocols="TLSv1.3" ciphers="TLS_AES_128_GCM_SHA256">

You have to use OpenSSL cipher names in this case. Like this...

ciphers="HIGH:ECDHE-ECDS
A-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY
1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RS
A-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-
SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-
AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128
-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AE
S256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDS
A-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDH
E-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-
RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RS
A-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-S
HA384:AES128-SHA256:AES256-SHA256:AES128-SH
A:AES256-SHA:!DSS">

> Tomcat throws an exception and TLS does not work! Errror code in the browser
> is: SSL_ERROR_RX_RECORD_TOO_LONG

The error in the logs below shows the initialization error in the ciphers 
attribute and thus no ciphers are available...

Peter
> 
> That is the most simplified version, first I tried these three:
> ciphers=""TLS_AES_128_GCM_SHA256,
> TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256". Same result.
> 
> I know, Java JSSE 1.8 does not support TLSv1.3, but openSSL does and Tomcat
> works with openSSL and TLSv1.3 as shown above.
> 
> The relevant part of the catalina log is:
> 
> 07-Aug-2019 13:41:38.183 INFORMATION [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
> based Apache Tomcat Native library [1.2.23] using APR version [1.7.0].
> 07-Aug-2019 13:41:38.183 INFORMATION [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
> [true].
> 07-Aug-2019 13:41:38.183 INFORMATION [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
> configuration: useAprConnector [false], useOpenSSL [true]
> 07-Aug-2019 13:41:38.198 INFORMATION [main]
> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
> successfully initialized [OpenSSL 1.1.1c  28 May 2019]
> 07-Aug-2019 13:41:38.370 INFORMATION [main]
> org.apache.coyote.AbstractProtocol.init Initialisiere
> ProtocolHandler["http-nio-8080"]
> 07-Aug-2019 13:41:38.417 INFORMATION [main]
> org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol The
> ["https-openssl-apr-8181"] connector has been configured to support
> negotiation to h2] via ALPN
> 07-Aug-2019 13:41:38.417 INFORMATION [main]
> org.apache.coyote.AbstractProtocol.init Initialisiere
> ProtocolHandler["https-openssl-apr-8181"] 07-Aug-2019 13:41:38.823 WARNUNG
> [main] org.apache.tomcat.util.net.openssl.OpenSSLContext.init Fehler beim
> initialisieren des SSL Contexts java.lang.Exception: Unable to configure
> permitted SSL ciphers (error:1410D0B9:SSL
> routines:SSL_CTX_set_cipher_list:no cipher match)
> at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:2
> 43)
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247
> )
> at
> org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:403
> )
> at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:369) 
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint
> .java:1124)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1137)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.ja

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Peter Kreuser]

Hi Munzer,

I guess we‘re going a slightly awkward way here, but to fix your problem with 
the new cert in the first place, you could use this:

If your keystore is the old proprietary format, convert it to PKCS12:
keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 
-deststoretype PKCS12 -srcalias tomcat -deststorepass  -destkeypass 

Then extract the key using openssl:
openssl pkcs12 -in keystore.p12 -nocerts -out key.pem
After that recombine it with the new cert.
I‘ve found this here: https://security.stackexchange.com/a/66865

There has to be an easier way, but as your keystore is causing troubles, I‘m 
not really able to troubleshoot that.

After all, you may have to reread on cert handling with keytool vs. openssl.
I prefer the openssl way ;-).

Peter



Peter Kreuser
> Am 06.08.2019 um 19:50 schrieb Munzer Khatib :
> 
> Hi Peter
> I dont have the private key file. That is created when I create the keystore. 
> I dont know if it can be extracted.
> Munzer
>On Tuesday, 6 August 2019, 4:35:51 PM UTC, Peter Kreuser 
>  wrote:  
> 
> Hi,
> 
> 
>> Am 06.08.2019 um 02:42 schrieb Munzer Khatib :
>> 
>> Hi
>> Can you help me with this problem.
>> Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
>> I am trying to install a new SSL certificate into Apache tomcat 8.0.36.I ran 
>> same steps ran successfully in 2013 and 2016 on tomcat 7. Nothing changed 
>> other than moving the virtual machine from old server to new hardware this 
>> year. Windows Server 2008 is still the same Operating system.
>> I created a keystore and extracted CSR, generated certificate using godaddy 
>> for Apache server and imported to server. I keep getting an SSL handshake 
>> errors and I think it is because the certificate entrytype is 
>> "trustedcertEntry" and not "privateKey Entry'
>> Here are the steps I used to create the keystore and import certificate to 
>> it.
>> 1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
>> keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
>> SHA256withRSA -keypass secret19 -keystore tomcat10.keystore
> 
>> 2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
>> SHA256withRSA -keystore tomcat10.keystore -file file10.csr
>> 
>> 3) Generate certificates on godaddy site for "Apache" server (not tomcat)
>> 4) Install root, intermediate and user certificate
>> keytool -import -alias root -keystore tomcat14.keystore -trustcacerts -file 
>> c:\cert_2022\gd-class2-root.crt
>> 
>> keytool -import -alias intermediate -keystore tomcat14.keystore 
>> -trustcacerts -file c:\cert_2022\gd_bundle-g2-g1.crt
>> keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
>> c:\cert_2019\508c844632c0145.crt
> 
> I‘ve not found a keytool command for that. I use openssl to convert the PEM 
> to pkcs12/keystore format
> 
> Care to try the following command?
> openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat -certfile 
> fullchain.pem -passout pass:changeit -out jssekeystore
> 
> Peter
> 
>> I am not sure why but it seems the new one is not linking all certificates 
>> into the private key.
>> I tried many different imports and it would never import the server 
>> certificate as a "privateKeyentry" as the one running now.C:\Program 
>> Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter keystore 
>> password:
>> Keystore type: JKSKeystore provider: SUN
>> Your keystore contains 3 entries
>> root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
>> 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, Jul 
>> 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
>> 27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul 22, 
>> 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
>> B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E
>> 
>> I also tried creating a PEM text file for all certificates and importing 
>> that into private key alias tomcat but it only imported the domain 
>> certificate as "trustedcertentry"
>> My server xml file connector config is like this> port="8080" protocol="HTTP/1.1" connectionTimeout="2" 
>> redirectPort="8443" compression="on" URIEncoding="UTF-8" 
>> compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" 
>> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/json"/>>  port="443" protocol="HTTP/1.

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Peter Kreuser]

Hi,


> Am 06.08.2019 um 02:42 schrieb Munzer Khatib :
> 
> Hi
> Can you help me with this problem.
> Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
> I am trying to install a new SSL certificate into Apache tomcat 8.0.36.I ran 
> same steps ran successfully in 2013 and 2016 on tomcat 7. Nothing changed 
> other than moving the virtual machine from old server to new hardware this 
> year. Windows Server 2008 is still the same Operating system.
> I created a keystore and extracted CSR, generated certificate using godaddy 
> for Apache server and imported to server. I keep getting an SSL handshake 
> errors and I think it is because the certificate entrytype is 
> "trustedcertEntry" and not "privateKey Entry'
> Here are the steps I used to create the keystore and import certificate to it.
> 1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
> keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
> SHA256withRSA -keypass secret19 -keystore tomcat10.keystore

> 2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
> SHA256withRSA -keystore tomcat10.keystore -file file10.csr
> 
> 3) Generate certificates on godaddy site for "Apache" server (not tomcat)
> 4) Install root, intermediate and user certificate
> keytool -import -alias root -keystore tomcat14.keystore -trustcacerts -file 
> c:\cert_2022\gd-class2-root.crt
> 
> keytool -import -alias intermediate -keystore tomcat14.keystore -trustcacerts 
> -file c:\cert_2022\gd_bundle-g2-g1.crt
> keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
> c:\cert_2019\508c844632c0145.crt
> 

I‘ve not found a keytool command for that. I use openssl to convert the PEM to 
pkcs12/keystore format

Care to try the following command?
openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat -certfile 
fullchain.pem -passout pass:changeit -out jssekeystore

Peter

> I am not sure why but it seems the new one is not linking all certificates 
> into the private key.
> I tried many different imports and it would never import the server 
> certificate as a "privateKeyentry" as the one running now.C:\Program 
> Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter keystore 
> password:
> Keystore type: JKSKeystore provider: SUN
> Your keystore contains 3 entries
> root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
> 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, Jul 22, 
> 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
> 27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul 22, 2019, 
> trustedCertEntry,Certificate fingerprint (SHA1): 
> B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E
> 
> I also tried creating a PEM text file for all certificates and importing that 
> into private key alias tomcat but it only imported the domain certificate as 
> "trustedcertentry"
> My server xml file connector config is like this port="8080" protocol="HTTP/1.1" connectionTimeout="2" redirectPort="8443" 
> compression="on" URIEncoding="UTF-8" compressionMinSize="2048" 
> noCompressionUserAgents="gozilla, traviata" 
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/json"/>  port="443" protocol="HTTP/1.1" maxThreads="150" scheme="https" secure="true" 
> clientAuth="false" sslProtocol="TLS" SSLEnabled="true" 
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" 
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
>  TLS_RSA_WITH_AES_256_CBC_SHA" keystorePass="password" 
> keystoreFile="C:\Program Files\Java\jre7\bin\tomcat10.keystore"/>
> 
> 
> Tried many different options for keytool command.
> Followed tomcat 8 documentation and godaddy list for installing certificate.
> When I try to access using browser I get this error
> This page can’t be displayed Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in 
> Advanced settings and try connecting to https://psscr.xyz.c
> When I use openssl I get handshake failure$openssl s_client -connect 
> 10.60.xx.xx:443CONNECTED(0003)140298896533392:error:14077410:SSL 
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake 
> failure:s23_clnt.c:769:---no peer certificate available---No client 
> certificate CA names sent---SSL handshake has read 7 bytes and written 289 
> bytes---New, (NONE), Cipher is (NONE)Secure Renegotiation IS NOT 
> supportedCompression: NONEExpansion: NONENo ALPN negotiatedSSL-Session:
> Protocol  : TLSv1.2Cipher: Session-ID:Session-ID-ctx:
> Master-Key:Key-Arg   : NoneKrb5 Principal: NonePSK identity: None 
>PSK identity hint: NoneStart Time: 1564789174Timeout   : 300 (sec) 
>Verify return code: 0 (ok)
> Thanks,

[slighly OT] Re: Apache Vulnerability - Understanding Connector Protocols

[Peter Kreuser]

Michael, Mark and Chris,

> Am 02.08.2019 um 01:40 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Michael,
> 
>>>> On 8/1/19 15:21, Michael Osipov wrote:
>>>> Am 2019-08-01 um 21:19 schrieb Mark Thomas:
>>>> On 01/08/2019 20:07, Justiniano, Tony wrote:
>>>> And that is what I was thinking, inadvertently, our scanning
>>>> tool just found the apache version during a scan and
>>>> corresponded it (the apache version) with a CVE.
>>>> 
>>>> Do you concur?
>>> 
>>> Sounds likely. Most low quality scanning tools only look at the
>>> version number.
>> 
>> I was told the same security by obscurity nonsense by our ISEC
>> team.

Being the ISEC team(!), I‘d ask you to validate the finding and do your 
homework, patch (you do, right?) or reconfigure your system and if it is a 
false positive mark it as such. Done. So you are aware of the possible problems 
and you have assessed the risk: no http/2==0! (Well you don‘t enable it next 
week, of course?!)

I assume noone here would like a vuln scanner to exploit all issues and tear a 
system down. But of course there are stupid an better ones (Scanner and ISEC 
teams ;-)). Nevertheless the process of excluding false positives should be 
reasonable.

> The OP should just set their reported version number to Tomcat 4.3 and
> let it completely freak out.

Just for the test of it: great idea!

But one of the first hardening actions on Tomcat is to disable standard error 
pages and version info. Server header removed (set to IIS if you like!)



You reduce these findings and the info for the attackers.

Peter
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1DeFsACgkQHPApP6U8
> pFixVBAAtRtkVQipOISzRnd7eFUpKTgpZeENUvbJlCSrgiKu66IJx+1WDdO81zmj
> mAk+F2syOoZgThiB5icu6gISwcpJm4yWWQOb+QileSQtjvkhdgueiv1Hwla74fm3
> jz/FtFc+6xiYGSG07/O9RgJASeM7Dabo+UB7KCXrDpL2WxDw1hU8kWUYIpnR16Ub
> 1DlXtOcIlnFe5FLld4WR8VHO6kAjNJd25EvYNqpEOfkG2WpJwkhGsMyDHcom40AF
> H5b7nrtpAVi1kaiyWcGVGpyFqUjZfdXYHM9bDDn1dsAkMBiYNDg8tlMT8JtkzZK9
> ULKBwnEJdeKJ6PvVfSDpsRYkSCqVJJXS/5X5Wx41VhbrHxKvnywimHNNxB3bQbAn
> LW1rvsP1aD1GaDzBwP2DoUKVUeMqhnVGwM75/Dyi7UjVu79xhoQpnR5aNmtB+k5/
> Kasib1LdFvNpZTs/1UgoG/JjVOd6j8nDe0U44cC23eSYBnq8bsGuaCUmSgsNOvOF
> ykA/0cMoGNFw481GZhgggOfAA+l+4m+x8CDQrawlq5d5Hx/6dBDGSjUqo0XWSg0J
> zJmJxPVj0024aD0Lt+ZO3U9Z0qIQ8doc0AkKO6t5wFJGAWTccDMsQAQV4UejRBDt
> dXpJdvqmZ28yxoOK2PNs8Swo1dg1iFF1xgqtu254nWqlU3/3xV8=
> =z4EQ
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: AW: Outbound SSL?

[Peter Kreuser]

BC_SHA *
>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_RSA_WITH_DES_CBC_SHA 
>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 
>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA 
>>> SSL_DH_anon_WITH_AES_128_CBC_SHA 
>>> SSL_DH_anon_WITH_AES_256_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA 
>>> SSL_DH_anon_WITH_RC4_128_MD5 SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 
>>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA 
>>> SSL_KRB5_EXPORT_WITH_RC4_40_MD5 SSL_KRB5_EXPORT_WITH_RC4_40_SHA 
>>> SSL_KRB5_WITH_3DES_EDE_CBC_MD5 SSL_KRB5_WITH_3DES_EDE_CBC_SHA 
>>> SSL_KRB5_WITH_DES_CBC_MD5 SSL_KRB5_WITH_DES_CBC_SHA 
>>> SSL_KRB5_WITH_RC4_128_MD5 SSL_KRB5_WITH_RC4_128_SHA *
>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA *
>>> SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 *
>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 *
>>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA *
>>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA *
>>> SSL_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_RSA_WITH_AES_256_CBC_SHA *   SSL_RSA_WITH_DES_CBC_SHA 
>>> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA *
>>> SSL_RSA_WITH_RC4_128_MD5 *   SSL_RSA_WITH_RC4_128_SHA
> 
> Almost all of the above cipher suites are useless.
> 
> Anything starting with SSL_*_DSS uses DSS authentication which is used
> by exactly nobody. Same thing with KRB5 -- nobody is being KErberos
> for TLS/SSL. Everyone uses either RSA or Elliptic Curve certificates.
> 
> Anything containing _anon_, EXPORT, FIPS, RC4, or MD5 should be
> eliminated as providing weak or actually-useless security.
> 
> Anything containing NULL means that there is no encryption. Duh.
> 
> So we are left with this list:
> 
>> *   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>> SSL_DHE_RSA_WITH_DES_CBC_SHA *
>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA *
>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA *   SSL_RSA_WITH_AES_128_CBC_SHA 
>> *   SSL_RSA_WITH_AES_256_CBC_SHA *
>> SSL_RSA_WITH_DES_CBC_SHA
> 
> All of those use SHA1 signatures which are no longer considered
> secure. That means that basically none of these cipher suites are
> acceptable for a modern security posture.
> 

+1 however that’s not James’ problem, I think. Customer box is the first list 
of ciphers.

> Here's what we have enabled at $work for production:
> 
> Supported Protocol Cipher
> Accepted  TLSv1.2 TLS_RSA_WITH_AES_256_CBC_SHA
> Accepted  TLSv1.2 TLS_RSA_WITH_AES_256_CBC_SHA256
> Accepted  TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA256
> Accepted  TLSv1.2 TLS_RSA_WITH_AES_128_GCM_SHA256
> Accepted  TLSv1.2 TLS_RSA_WITH_AES_256_GCM_SHA384
> Accepted  TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> Accepted  TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> Accepted  TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> Accepted  TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA
> Accepted  TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> Accepted  TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> Accepted  TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> Accepted  TLSv1.1 TLS_RSA_WITH_AES_256_CBC_SHA
> Accepted  TLSv1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> Accepted  TLSv1.1 TLS_RSA_WITH_AES_128_CBC_SHA
> Accepted  TLSv1.1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> AcceptedTLSv1 TLS_RSA_WITH_AES_256_CBC_SHA
> AcceptedTLSv1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> AcceptedTLSv1 TLS_RSA_WITH_AES_128_CBC_SHA
> AcceptedTLSv1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 
> There are some cipher suites in there with _SHA at the end. Those are
> in there for ancient browsers that simply can't do modern protocols,
> and they are prioritized to the bottom of the list.
> 
> But everything else is pretty good IMO.
> 
> SSLLabs/Qualys still complains about every one of those except these two
> :
> 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> 
> ... calling the others "weak". I think that's because they consider
> anytning that isn't using ECDHE+GCM to be "weak". Well, it's the best
> we can do right now without going up to TLSv1.3.
> 
> Anyhow, if the client (or the server) is being run with any decent
> kind of TLS configuration, then the second list of supported cipher
> suites shown above will simply not be able to connect.
> 
> Assuming that you are using the built-in Java JSSE provider, then the
> problem is that your Java version is just too old: you need a newer
> version of Java to get better cipher suites.
> 
&g

Re: Outbound SSL?

[Peter Kreuser]

James,

Outbound SSL is usually handled by the underlying Java VM.

> Am 29.05.2019 um 20:57 schrieb James H. H. Lampert :
> 
> We have a customer that is running our Tomcat-based webapp, and it is
> apparently having trouble accessing a Google web service.
> 
> The error message they're getting is:
> 
>> Unable to find acceptable protocols. isFallback=false,
>> modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1,
>> TLS_1_0], supportsTlsExtensions=true),
>> ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0],
>> supportsTlsExtensions=true), ConnectionSpec()], supported
>> protocols=[TLSv1]

These are the ciphers and protocols requested. Are these two different 
services?  If that is from server and client the ciphers are OK and protocols 
also overlap.
What strikes me though is the difference in TLS versions and supported 
protocols.

> Is this something that could be caused by a Tomcat configuration issue?
> 
Not really Tomcat. Java. Unless you set specific values on the connection.
Or on the commandline.

Could you please let us know the Java version and maybe the Connection 
settings? JAVA_OPTS?
> --
> James H. H. Lampert
> 
> -----
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Peter

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

Re: Minor version upgrades

[Peter Kreuser]

Dave

> Am 10.05.2019 um 17:23 schrieb Dave Ford :
> 
> Hello,
> 
> We've running many instances of Tomcat 8.5 on some dozens of linux
> servers.  All of this is being managed by Puppet using the puppetforge
> tomcat module.
> 
> The Puppet module that deploys tomcat simple checks to see if the
> NOTICE file is the correct place to determine whether or not it should
> unpack a provided tarball into Catalina_home. 
> 
> My question is this - as we've gone and placed our catalina_base folder
> within a subfolder of catalina_home, we're not going to want to simply
> delete the C_H folder to reinstall a newer version.
> 
> Is it safe/sane to unpack a new minor release (say 8.5.40) over the
> existing installation of (8.4.32) over an existing Catalina_Home?
> 
> Or should I simply bite the bullet, rework my puppet code to deploy the
> instances outside of Catalina_Home and wipe C_H before redeploying it
> with a  newer version?

Take a big bite and make the most of the separation of home and base.

Well you noticed the point of the separate directories already.

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

Just my 2ct

Peter

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

Re: [EXTERNAL] Re: Tomcat(9.0.13) Error in DEV Server

[Peter@Kreuser-Online]

und:  
> TOPS_INTL_FIELD_USER_LAX
> 15-Apr-2019 17:08:17.769 FINE [https-jsse-nio-9443-exec-8] 
> org.apache.catalina.realm.RealmBase.hasRole Username [topsadmin] does NOT 
> have role [TOPS_INTL_FIELD_USER_MIA]
> 15-Apr-2019 17:08:17.769 FINE [https-jsse-nio-9443-exec-8] 
> org.apache.catalina.realm.RealmBase.hasResourcePermission No role found:  
> TOPS_INTL_FIELD_USER_MIA
> 15-Apr-2019 17:08:17.769 FINE [https-jsse-nio-9443-exec-8] 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke  Failed 
> accessControl() test
> 
> 
> 
> The error messages on the screen looks like below:
> 
> HTTP Status 403 – Forbidden
> 
> Type Status Report
> 
> Message Access to the requested resource has been denied
> 
> Description The server understood the request but refuses to authorize it.
> 
> USPS_restricted
> 
> 
> 
> 
> 
> 
> Any idea what is that about?   Again the Ream definition is:
> 
>connectionURL="ldaps://eagandcs-dev-sha2.usps.gov:636"
>   connectionName="wasd...@devsub.dev.dce.usps.gov"
>   connectionPassword=""
>   authentication="simple"
>   referrals="ignore"
>   userSearch="(sAMAccountName={0})"
>   userBase="DC=devsub,DC=dev,DC=dce,DC=usps,DC=gov"
>   userSubtree="true"
>   roleSearch="(member={0})"
>   roleName="cn"
>   roleSubtree="true"
>   roleBase="DC=devsub,DC=dev,DC=dce,DC=usps,DC=gov"
>   adCompat="true"
> />
> 
> 
> 
> Thanks
> Gary
> 
> 

Peter

PS: you should redact sensitive data from your mails. At least change passwords 
now... google is NOT your friend in this case...

> -Original Message-
> From: Luis Rodríguez Fernández [mailto:uo67...@gmail.com] 
> Sent: Monday, April 15, 2019 3:47 AM
> To: Tomcat Users List 
> Subject: [EXTERNAL] Re: Tomcat(9.0.13) Error in DEV Server
> 
> Hello Gary,
> 
> I would recommend you to add some debug to your JNDIReam [1]. For debugging 
> your ldap search filters ldapsearch can be your friend [2] :)
> 
> Hope it helps,
> 
> Luis
> 
> [1]
> https://stackoverflow.com/questions/12311496/how-to-debug-realm-feature-in-tomcat
> [2]
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Examples-of-common-ldapsearches.html
> 
> 
> 
> 
> 
> 
> 
> El vie., 12 abr. 2019 a las 0:23, Hua, Gary - Saint Louis, MO - Contractor
> () escribió:
> 
>> All:
>> 
>> 
>> 
>> Sorry on my previous email I have some graphic contents that can not
>> be displayed.   Now I change it to texts so you can see them
>> 
>> 
>> 
>> *From:* Hua, Gary - Saint Louis, MO - Contractor [ 
>> mailto:gang@usps.gov.INVALID ]
>> *Sent:* Thursday, April 11, 2019 4:29 PM
>> *To:* users@tomcat.apache.org
>> *Subject:* [EXTERNAL] Tomcat(9.0.13) Error in DEV Server
>> 
>> 
>> 
>> Tomcat Experts:
>> 
>> 
>> 
>>The Tomcat server works fine in my local computer with  
>> application “TOPS“ in Eclipse.  I deployed the TOPS application to our 
>> DEV web server eagnmnmed1f45 under webapps.
>> 
>> 
>> 
>>After I started the Tomcat  server (9.0.13) in DEV 
>> server and entered the TOPS home page URL 
>> http://eagnmnmed1f45:9080/TOPS-WEB/Welcome.do (It is
>> http://localhost:8080/TOPS-WEB/Welcome.do  in my local computer)   in the
>> browser,   it was re-directed to
>> https://eagnmnmed1f45:9443/TOPS-WEB/Welcome.do.and following error:
>> 
>> 
>> 
>> 
>> 
>> *The website cannot display the page*
>> 
>>  HTTP 500
>> 
>> 
>> 
>> *Most likely causes:*
>> 
>>   - The website is under maintenance.
>>   - The website has a programming error.
>> 
>> 
>> 
>> *What you can try:*
>> 
>> 
>> 
>> [image: res://\\ieframe.dll/bullet.png]
>> 
>> Refresh the page.Refresh the page.
>> 
>> 
>> 
>> [image: res://\\ieframe.dll/bullet.png]
>> 
>> Go back to the previous page.Go back to the previous page.
>> 
>> 
>> 
>> [image: More information]
>> 
>> More information
>> 
>> 
>> 
>> 
>> 
>> atadmin@eagnmnmed1f45:/opt/TomCat/apache-tomcat-9.0.13/logs>tail -f 
>> catalina.out
>> 
>> 5307 [main] WARN org.hibernate.cache.EhCacheProvider - Could not find 
>> configuration [LegDistanceImpl]; using defaults.
>> 
>> 5764 [main] INFO o

connectionInitSqls

[Peter Tom]

Hi all,

I have third party application installed on Tomcat 8.5.

The application uses DB Oracle connection (ojdbc7) and everything working
fine.

I would like to set session parameter on first db connect (alter session
set NLS_NUMERIC_CHARACTERS = '.,')

I added this (connectionInitSqls ="alter session set NLS_NUMERIC_CHARACTERS
= '.,'") into the context.xml file in the app. META-INF directory:


 
 
 


But still not working.

Has somebody idea how to solve it?


thank you
Peter