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: 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 many security-related headers and
>> maybe it's potential lifetime isn't that long. My guess is that sometime in 
>> the
>> near future, TLS will simply be required for all web traffic. If we bake that
>> kind of thing into core-Tomcat, it becomes something we will need to un-
>> bake in the future, and chefs can tell you that un-baking things rarely works
>> out well.
>> 
>> -chris
>> 
>> -
> 
> Thanks for your elaboration!
> The security headers change from time to time, true.
> Maybe it would be possible to provide a kind of "http-header-valve" which can 
> be configured which headers to add?
> Then you wouldn’t have a tight coupling and when headers change, you can 
> adjust the configuration without changing code.
> It would not be as comfortable as the HttpHeaderSecurityFilter but more 
> flexible.
> 
> Option d) would be to ignore the reported finding of the pen-testing tool 😉
> 
> Greetings,
> Thomas
> 
> B‹CB•È[œÝXœØÜšX™KK[XZ[ˆ\Ù\œË][œÝXœØÜšX™PÛXØ]
> 

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

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
> 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: 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
> 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
>> Tel 515-988-2508 | Cell 515-988-2508
>> 
>> 
> 
>>> jonmcalexan...@wellsfargo.com
>> This message may contain confidential and/or privileged information.
>> If you
> are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply
> e-mail and delete this message. Thank you for your cooperation.
>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: 

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: [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

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: [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

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: 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
>> [[ErrorDocument 400 ""]] meaning that the response will include NO
>> CONTENT.
>> Maybe that's what Qualys is looking for.
> 
> My reading of the thread so far is that the security scanner expects
> either a TLS error or a redirect to https.
> 
> The redirect option is interesting. I can see user benefit in http
> requests to an https port getting redirected to https. The tricky part
> is implementing it. Redirection to a fixed URL is quite simple. As soon
> as you get into redirecting the actual user's request you open up the
> HTTP request parsing can of worms.
> 
> I'm wondering if there is a way to utilise the standard request
> processing 

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: 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
>>> are
>>> getting
>> below
>>> error.
>>> Sat Jul 18 05:49:40 UTC 2020
>>> **
>>> *  Stopping the Web Server
>>> **
>>> Sat Jul 18 05:49:40 UTC 2020
>>> ./wfc: line 28: /usr/local/nginx/nginx: No such file or
> directory
>>> ./wfc: line 233: /usr/local/nginx/nginx: No such file or
> directory
>>> Sat Jul 18 05:49:40 UTC 2020
>>> *  Nginx has been stopped
>>> **
>>> *  Shutdown the wfc Server gracefully
>>> **
>>> #
 *
>>> # Tomcat shutdown with wait time: 30
>>> #
 *
>>> Using CATALINA_BASE:   /usr/local/xyz/tomcat
>>> Using CATALINA_HOME:   /usr/local/xyz/tomcat
>>> Using CATALINA_TMPDIR: /usr/local/xyz/tomcat/temp
>>> Using JRE_HOME:/usr/local/xyz/jdk
>>> Using CLASSPATH:
>>> /usr/local/xyz/tomcat/bin/bootstrap.jar:/usr/local/xyz/tomcat/bin/tomcat-juli.jar
>>> Using CATALINA_PID:/usr/local/xyz/tomcat/tomcat.pid
>>> Tomcat did not stop in time.
>>> To aid diagnostics a thread dump has been written to
>>> 

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

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

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

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: [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 distribution uses
> the "no-AOP" version of Guice which doesn't contain any CGLIB
> classes. It suggests that whoever provided that copy of Maven
> has replaced the
 "no-AOP"
> version with the "AOP" version, and this will cause warnings on
> Java 11. (The "AOP" version uses CGLIB which currently relies
> on certain
 reflective
> access that Java 11 warns about - whereas the "no-AOP" version
> doesn't.)
> 
 
 
 -
 
 
>> 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/
>> 
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VLGgACgkQHPApP6U8
>> pFjmuw//cXWmOfcRCt/2FqHwWZwuB23fIXrzEdOJ3RPdJEfwDUxtVcz/rXGI9TB6
>> ae64Vr1+8Znh8xX+wGvoScITo3L/qUPWDkWf5W3rAhhQNWCqsvJvCM4Sw7YE4ytE
>> pv9gT9seDOx+wiGq+FQ5gdy1T7adgTwgYAVLCeuG/bvk4niz9vtYxXBXdfeTIb5e
>> 

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
>> 
>> PermitTunnel yes
>> 
>> and restarted that. Still no change.
>> 
>> Chris
>> 
>> 
>> [1] 
>> https://serverfault.com/questions/390840/how-does-one-get-tomcat-to-bind-to-ipv4-address
> 
> 
> As a followup to take the tunnel out of the equation I downloaded
> jmxterm [1] on the server and tried to connect
> 
> 
> $ java -jar jmxterm-1.0.0-uber.jar
> Welcome to JMX terminal. Type "help" for available commands.
> $>open localhost:10001
> #RuntimeIOException: Runtime IO exception: Failed to retrieve
> RMIServer stub: javax.naming.CommunicationException [Root exception is
> java.rmi.ConnectIOException: non-JRMP server at remote endpoint]
> $>
> 
> 
> Back to the tomcat documentation, I added this to CATALINA_OPTS
> (based on listener config and assumed defaults)
> 
> -Dcom.sun.management.jmxremote.registry.ssl=false
> 
> and now I get a different error :
> $>open localhost:10001
> #RuntimeIOException: Runtime IO exception: Failed to retrieve
> RMIServer stub: javax.naming.CommunicationException [Root exception is
> 

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]

Chris, James

> Am 01.06.2019 um 02:30 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> James,
> 
>> On 5/31/19 18:41, James H. H. Lampert wrote:
>>> On 5/31/19, 3:34 AM, bernd.sch...@daimler.com wrote:
>>> You can run a small java program on your jvm to print out the
>>> supported And default protocols. Yet, I didn’t find a better
>>> way.
>>> 
>>> e.g. ==> 
>>> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679
> 609085.html
>>> 
>> 
>>> 
>> If I set the same JAVA_HOME as Tomcat was launched under, and
>> compile and run "Ciphers.java" from the above site, on the customer
>> box, I get:
>> 
>>> Default Cipher SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH *
>>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 
>>> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 *
>>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 
>>> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 SSL_DHE_DSS_WITH_DES_CBC_SHA 
>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 
>>> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 
>>> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 SSL_DHE_RSA_WITH_DES_CBC_SHA 
>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
>>> SSL_DH_anon_WITH_AES_128_CBC_SHA 
>>> SSL_DH_anon_WITH_AES_128_CBC_SHA256 
>>> SSL_DH_anon_WITH_AES_128_GCM_SHA256 
>>> SSL_DH_anon_WITH_AES_256_CBC_SHA 
>>> SSL_DH_anon_WITH_AES_256_CBC_SHA256 
>>> SSL_DH_anon_WITH_AES_256_GCM_SHA384 SSL_DH_anon_WITH_DES_CBC_SHA 
>>> *   SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
>>> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
>>> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
>>> SSL_ECDHE_ECDSA_WITH_NULL_SHA *
>>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
>>> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
>>> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 
>>> SSL_ECDHE_RSA_WITH_NULL_SHA *
>>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 
>>> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
>>> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 
>>> SSL_ECDH_ECDSA_WITH_NULL_SHA *
>>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 
>>> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 
>>> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 SSL_ECDH_RSA_WITH_NULL_SHA 
>>> SSL_ECDH_anon_WITH_AES_128_CBC_SHA 
>>> SSL_ECDH_anon_WITH_AES_256_CBC_SHA SSL_ECDH_anon_WITH_NULL_SHA
>>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 
>>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA SSL_KRB5_WITH_DES_CBC_MD5 
>>> SSL_KRB5_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 
>>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>>> SSL_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_RSA_WITH_AES_128_CBC_SHA256 SSL_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_RSA_WITH_AES_256_CBC_SHA256 SSL_RSA_WITH_AES_256_GCM_SHA384 
>>> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 
>>> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_NULL_SHA256 *
>>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> 
> Other than the fact that none of those start with TLS_ like all modern
> cipher suites do, the above looks okay.
> 

Crazy enough, but Google maps provides ciphers even for Java 6.

https://www.ssllabs.com/ssltest/analyze.html?d=maps.google.com=216.58.195.78

So this would be the only strange but obvious difference. The list has EVEN 
ECDH, GCM, AES 256.

 
>> FOR COMPARISON PURPOSES, what we get on our box is:
>>> Default Cipher *   SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA *
>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_DSS_WITH_DES_CBC_SHA *
>>> SSL_DHE_DSS_WITH_RC4_128_SHA *
>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_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 *
>>> 

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]

Hi Gary,

see way below inline...

> Am 16.04.2019 um 03:02 schrieb Hua, Gary - Saint Louis, MO - Contractor 
> :
> 
> Luis:
> 
> Thanks for your input.   I put the following into 
> conf/logging.properties and add  debug="99"  in the Realm definition  so I 
> can see more Realm logging information:
> 
> org.apache.catalina.realm.level = ALL
> org.apache.catalina.realm.useParentHandlers = true
> org.apache.catalina.authenticator.level = ALL
> org.apache.catalina.authenticator.useParentHandlers = true
> 
> 
>After the first login attempt in the application TOPS login screen,   the 
> URL was redirected to  https://eagnmnmed1f45:9443/TOPS-WEB/j_security_check  
> with invalid UID/PW message.Then I entered  topsadmin/@88Topstopstops as 
> id/pd and clicked  the Login button again,  I got the following message in 
> the catalina.out:
> 
> 
> 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke Security checking 
> request POST /TOPS-WEB/j_security_check
> 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking 
> constraint 'SecurityConstraint[Entire Application]' against POST 
> /j_security_check --> true
> 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking 
> constraint 'SecurityConstraint[Secure area's for TOPS_ADMIN user]' against 
> POST /j_security_check --> false
> 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking 
> constraint 'SecurityConstraint[SecuredResource]' against POST 
> /j_security_check --> false
> 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking 
> constraint 'SecurityConstraint[Entire Application]' against POST 
> /j_security_check --> true
> 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking 
> constraint 'SecurityConstraint[Secure area's for TOPS_ADMIN user]' against 
> POST /j_security_check --> false
> 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking 
> constraint 'SecurityConstraint[SecuredResource]' against POST 
> /j_security_check --> false
> 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke  Calling 
> hasUserDataPermission()
> 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.RealmBase.hasUserDataPermission   User data 
> constraint already satisfied
> 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke  Calling 
> authenticate()
> 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.authenticator.FormAuthenticator.doAuthenticate 
> Authenticating username 'topsadmin'
> 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.CombinedRealm.authenticate Attempting to 
> authenticate user [topsadmin] with realm [org.apache.catalina.realm.JNDIRealm]
> 15-Apr-2019 17:08:17.694 INFO [https-jsse-nio-9443-exec-7] 
> org.apache.catalina.realm.JNDIRealm.authenticate Exception performing 
> authentication. Retrying...
> javax.naming.CommunicationException: Connection reset [Root exception is 
> java.net.SocketException: Connection reset];

That may be the reason!?
It cannot connect and everything following is just bad error handling?

> remaining name 'DC=devsub,DC=dev,DC=dce,DC=usps,DC=gov'
>at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2002)
>at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1844)
>at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
>at 
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
>at 
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
>at 
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
>at 
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
>at 
> org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1675)
>at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1510)
>at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1458)
>at 
> org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1403)
>at 
> org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1285)
>at 
> org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:188)
>at 
> org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:153)
> 

Re: Has anybody ever heard of "ECDHE-ECDSA-CHACHA20-POLY1305"? was Re: TLS protocols and cipher suites

[Peter@Kreuser-Online]

Hi James,


> Am 18.03.2019 um 23:49 schrieb James H. H. Lampert :
> 
> I've just (same customer as before) been asked about
> ECDHE-ECDSA-CHACHA20-POLY1305
> and ECDHE-RSA-CHACHA20-POLY1305
> 
> and I can't find either one on the Sun or IBM JSSE cipher lists for Java 8.
> 
Most certainly only >=Java9... (OpenJDK and Oracle, don’t know about IBM though)
> --
> 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: Has anybody ever heard of "ECDHE-ECDSA-CHACHA20-POLY1305"? was Re: TLS protocols and cipher suites

[Peter@Kreuser-Online]

Oh,

and yes I’ve heard about them and used the RSA version!

Peter

> Am 18.03.2019 um 23:49 schrieb James H. H. Lampert :
> 
> I've just (same customer as before) been asked about
> ECDHE-ECDSA-CHACHA20-POLY1305
> and ECDHE-RSA-CHACHA20-POLY1305
> 
> and I can't find either one on the Sun or IBM JSSE cipher lists for Java 8.
> 
> --
> 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: Http insecure headers

[Peter@Kreuser-Online]

Nitin,

sorry for my late reply.


> Am 27.02.2019 um 17:01 schrieb Nitin Kadam :
> 
> Hello ,
> 
> We dint have any reverse proxy in middle layers and we have added filters in 
> web.config only, Please find attached snaps of same.
> i am new to tomcat so didnt able to understand all terms.
> 

Well your added filter will not help, if there is already code in place.
To find a possible configuration you may check on your webapp’s web.xml 
(located in the WEB-INF directory). But that all depends on the webapp...
Is this application developed by you/your company or somebody else? You may 
need help from the developer.

Best regards

Peter

>> On Wed, Feb 27, 2019 at 9:20 PM logo  wrote:
>>  
>> 
>> Hello Nitin, 
>> 
>> Am 27.02.2019 16:34, schrieb Nitin Kadam: 
>> 
>> > Hello Team, 
>> > 
>> > I have added below given filter and restarted tomcat service still it 
>> > shows Cache Control as private. 
>> > Please help me on same.
>> 
>> Pictures are stripped off the mailing list. so better send us text logs.
>> 
>> 
>> Nevertheless I told you before, the Cache-Control header may come from
>> your webapp. So you have to check the web.xml of the app for a possible
>> filter. Maybe it's also in the framework or the servlets itself. What is
>> happening if you request a resource from another context?
>> If it is set in the app, then possibly nothing in tomcat will be able to
>> remove it from the response (maybe a reverse proxy like apache or
>> nginx). 
>> 
>> Hope this helps. 
>> 
>> Peter 
>> 
>> > On Wed, Feb 27, 2019 at 2:54 PM logo  wrote: 
>> > 
>> >> Hi Nitin,
>> >> 
>> >> Am 27.02.2019 10:11, schrieb Nitin Kadam:
>> >>> Sorry for typo in earlier email, i was saying about ExpiresFilter only
>> >>> 
>> >>> so how do i add this filter and failter mapping , Do i need to add
>> >>> both in existing httpHeaderSecurity
>> >>> 
>> >>> 
>> >>> 
>> >>> ExpiresFilter
>> >>> 
>> >>> org.apache.catalina.filters.ExpiresFilter
>> >>> 
>> >>> ExpiresByType image
>> >>> access plus 10 days
>> >>> 
>> >>> 
>> >>> ExpiresByType text/css
>> >>> access plus 10 hours
>> >>> 
>> >>> 
>> >>> ExpiresByType application/javascript
>> >>> access plus 10 minutes
>> >>> 
>> >>> 
>> >>> 
>> >>> ExpiresDefault
>> >>> access plus 0 seconds
>> >>> 
>> >> 
>> >> this is an extra entry. I don't know if you should really put this in 
>> >> the global web.xml or rather in your applications web.xml. Maybe Mark 
>> >> can let us know more about possible consequences?
>> >> 
>> >> Add the ... AND the !!!
>> >> 
>> >> Peter
>> >> 
>> >>> 
>> >>> 
>> >>> On Wed, Feb 27, 2019 at 1:59 PM logo  wrote:
>> >>> 
>> >>>> Hello Nitin,
>> >>>> 
>> >>>> Am 27.02.2019 08:52, schrieb Nitin Kadam:
>> >>>>> Hello,
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> How can i change "Cache Control -private: to "Cache-Control: nostore"
>> >>>>>
>> >>>>> i searched and found that need to add express filters in web config but
>> >>>>> not
>> >>>>> sure on where to add in filters.
>> >>>>>
>> >>>>> can you please guide me on same?
>> >>>>>
>> >>>> 
>> >>>> as far as I can tell, that Header is already set by your application -
>> >>>> Tomcat will not set it by default. Not to "private" for sure.
>> >>>> So it may be necessary to change that in your config, maybe even code.
>> >>>> 
>> >>>> Usually you would have to implement a CacheControl filter like the one
>> >>>> mentioned here at stackoverflow
>> >>>> https://stackoverflow.com/questions/2876250/tomcat-cache-control [1]
>> >>>> 
>> >>>> I don't know if the new ExpiresFilter will let you set the
>> >>>> Cache-Control-Header to that necessary value (other than max-age=0).
>> >&

Re: Http insecure headers

[Peter@Kreuser-Online]

Hi Nitin,

Per se this can be done by enabling the  
org.apache.catalina.filters.HttpHeaderSecurityFilter
in the global or your webapp‘s web.xml

For CSP you should write your own Filter.

Beware though that Content Security Policy is nothing that can be enabled 
without application knowhow, the right settings for your needs and intensive 
testing. You may really break inline Javascript in your pages (css too).

Please check out the great websites of Scott Helme on the Headers
https://Securityheaders.io or https://scotthelme.co.uk/csp-cheat-sheet/


Peter

> Am 19.02.2019 um 19:13 schrieb Nitin Kadam :
> 
> Hello Team
> 
> Need help to enable below security headers in Apache tomcat 7.0.79
> Operating system is windows 2012 R2
> 
> 1. Content  security headers
> 2. HSTS header
> 
> Regards
> Nitin

Re: Question regarding mitigating the CVE-2017-12617 vulnerability

[Peter@Kreuser-Online]

Michael,

> Am 13.02.2019 um 22:03 schrieb Adams, Michael :
> 
> Christopher,
> Thanks for your input.   It was very helpful.  This afternoon, my 
> InfoSecurity technician who runs the Tripwire app believes Apache Tomcat vs 
> 8.5.13 is being flagged for the CVE-2017-12617 vulnerability solely off of 
> the version.   

Not saying that the update would not be worth it, but to get around the version 
check, you should set the ErrorReportValve like so:



That will remove the version info from the 404 or error-pages.

I assume that you removed the Default ROOT and examples webcontext. The are a 
couple more hardening suggestions.

But keep the updates coming. 8.5.13 is a bit aged and the next scan will come.

Just the 2cts of an application security guy.

Peter

> Tripwire isn't trying to see if HTTP PUT is enabled.  He is opening a false 
> positive ticket with the Tripwire vendor to get more information on their 
> check.
> 
> Thanks again,
> Mike
> 
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Sent: Wednesday, February 13, 2019 1:19 PM
> To: users@tomcat.apache.org
> Subject: [External] Re: Question regarding mitigating the CVE-2017-12617 
> vulnerability
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Michael,
> 
>> On 2/13/19 13:35, Adams, Michael wrote:
>> I currently am running Apache Tomcat 8.5.13.0 on Windows Server
>> 2012 R2 servers to support a NCR Aptra Vision application.  A
>> Tripwire vulnerability scan showed the servers have the Apache
>> Tomcat CVE-2017-12617 Vulnerability.  To mitigate I see I could
>> upgrade to Apache Tomcat 8.5.23 or later.   Instead of upgrading to
>> 8.5.23 or later, I am wanting to 'turn off' HTTP PUT
>> functionality.> I have this simple question: Is it possible to
>> mitigate the vulnerability by just adding/setting the init-param
>> readonly param value to true for the DefaultServer in the Apache
>> TomCat instance ../conf/web.xml file? Or is Tomcat 8.5.23 or higher
>> required for Apache TomCat to properly process the DefaultServer's
>> setting when I set the readonly parameter to true?
> Yes and no.
> 
> First of all, conf/web.xml should default to readonly=true and it
> would be a huge security vulnerability to set it to false. It is never
> safe to set readonly=false in conf/web.xml because it would affect all
> applications deployed that do not explicitly set the readonly flag for
> DefaultServlet... and most don't.
> 
> Which brings me to the "no" part of the above.
> 
> If an individual application specifies readonly=false in its web.xml
> file (found in WEBAPP/WEB-INF/web.xml), then the setting at the
> top-level will not disable PUT and DELETE requests.
> 
> AFAIK, there is no way to completely disable it on the server,
> overriding the configuration of the deployed web applications.
> 
>> The reason I ask is this: The Tripwire test still found the Tomcat 
>> CVE-2017-12617 Vulnerability even after I did the following on the 
>> Windoww Server 2012 R2 servers: Stopped Apache Tomcat intance, made
>> the configuration change to the ../conf/web.xml file shown below,
>> and re-started Apache Tomcat.
> 
> I can think of two possible reasons:
> 
> 1. One of your web applications is specifying readonly=false for the
> DefaultServlet. This would (a) be very uncommon if true and (b)
> usually means that the application *absolutely must* have it set up
> that way. It's an unusual configuration mistake to make... you really
> have to go out of your way to make this unsafe.
> 
> 2. Your TripWire scan is checking the version number of the server and
> complaining about everything that could possibly be in it, rather than
> giving you a honest report of what vulnerabilities are actually
> exploitable in your environment.
> 
>> The following should make the context read-only and HTTP commands
>> like PUT and DELETE to be rejected.  
>> default 
>> org.apache.catalina.servlets.DefaultServlet ass>
>> 
>> 
> 
>> debug 0 
>>   listings 
>> false   
>> readonly true 
>>  1 
>> 
>> Your help in the following matter would be much appreciated.
> 
> That should be fine, but it should also be the default and therefore
> unnecessary.
> 
> Check each of the deployed web applications to see if they are
> defining the default servlet. You should be able to do a "FIND" on
> each of the app/WEB-INF/web.xml for DefaultServlet to see if anything
> is in there.
> 
> If that doesn't show any re-definitions of the DefaultServlet, they it
> looks like a version bump is the only thing that will make TripWire happ
> y.
> 
> Fortunately, upgrading Tomcat between point-releases should not be a
> very traumatic experience. If you'd like some help with that, just ask.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxkbaQACgkQHPApP6U8
> pFjsjg//VMeNY7moedueSgNJv7TkPJ63EikCffigqe6Dr8w7ox0Tt54zgQtX34QM
> 

Re: [EXTERNAL] Re: tomcat Finding!

[Peter@Kreuser-Online]

Danyaal,


> Am 18.12.2018 um 21:15 schrieb  
> :
> 
> Added following to the Server.xml, still showing in the latest scan.
> 
>  showReport=false" showServerInfo="false" />
> 
> Thank you,
> Danyaal 
> 
> -Original Message-
> From: John Palmer [mailto:johnpalm...@gmail.com] 
> Sent: Friday, December 14, 2018 6:26 PM
> To: Tomcat Users List
> Subject: [EXTERNAL] Re: tomcat Finding!
> 
> WARNING:This is an external email that originated outside of our email 
> system. DO NOT CLICK links or open attachments unless you recognize the 
> sender and know that the content is safe!
> 
> I found this to be easier to accomplish (and maintain):
> 
> add to the Host section of server.xml:
>  showReport=false" showServerInfo="false" />
> 
> (this will disable the tomcat version number and the stacktrace  - the
> defaults for these are "true")
> 
> 
>> On Fri, Dec 14, 2018 at 10:18 AM  wrote:
>> 
>> Good Morning,
>> I'm encountering following scan finding errors and couldn't find way to
>> mitigate this.
>> 
>> Tomcat 8.5.32
>> 12085
>> Apache Tomcat Default Files
>> The following default files were found
>> :/nessus-check/default-404-error-page.html
>> Delete the default index page and remove the example JSP and servlets.

did you also remove the default files under webapps (examples, Root,...)?
This finding is not only for errorpages with version number!

Peter 

>> Follow the Tomcat or OWASP instructions to replace or modify the default
>> error page.
>> 
>> Thank you,
>> Danyaal
>> 
>> -
>> 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: Connection closed error and certificateVerification="required"

[Peter@Kreuser-Online]

Mark,

>> Am 18.04.2018 um 11:55 schrieb Mark Thomas :
>> 
>> On 18/04/18 10:36, Richard Tearle wrote:
>> On 17 April 2018 at 16:45, Richard Tearle
>>  wrote:
>>> On 17 April 2018 at 14:54, Mark Thomas  wrote:
> On 17/04/18 11:36, Mark Thomas wrote:
> On 17/04/18 10:14, Richard Tearle wrote:
 
 
 
> Now all we need to to do is to figure out how to fix this. With the
> understanding of what is (probably) going wrong, the problem can be
> produced with a clean build and the certs we use for unit tests which
> makes things a lot easier. I hope to make progress on this today.
 
 I believe this is fixed in trunk for both 9.0.x and 8.5.x.
 
 Are you able to build either of those from source and test? If not, I
 can provide a snapshot build for you to test with.
 
 Cheers,
 
 Mark
>>> 
>>> I've built from source, re-enabled the health check, and so
>>> far so good - it's been running an hour without an error.
>>> 
>>> Once this run has finished, I'll run it overnight, and let you
>>> know tomorrow morning.
>>> 
>>> Many thanks for your help on this.
>>> 
>>> --
>>> Richard
>> 
>> Just a quick follow up - I've run our test for 8 hours, without the
>> connection closed error.
> 
> Excellent. That is really good news.
> 
>> Again, many thanks.
> 
> No problem. Happy to help. Thanks for your assistance with this issue.
> Your test case and debug logs were invaluable. I couldn't have fixed
> this without them.
> 
> Mark
> 
Do you mind to share more about the root cause? I’ve followed this mail 
communication from the start and am  curious. 

Let me tell you that your endurance on all the tricky issues here is admirable! 

Thank you for that!

Peter

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

Re: Running as user tomcat

[Peter@Kreuser-Online]

Hi Chris,



> Am 23.02.2018 um 18:36 schrieb Cheltenham, Chris 
> :
> 
> Hello All,
>  
> I am trying to run tomcat as a non root user.
>  
> It will start as the tomcat user but it will not bind to connector 443 unless 
> it starts as root.
>  
> Does anyone know why?

Unix will not let you open ports below 1024 as non-root user!

You may use a proxy in front of it or maybe use iptables to be able to use 
standard ports AND user tomcat.

> 23-Feb-2018 09:14:59.140 SEVERE [main] 
> org.apache.catalina.core.StandardService.initInternal Failed to initialize 
> connector [Connector[HTTP/1.1-443]]
> org.apache.catalina.LifecycleException: Failed to initialize component 
> [Connector[HTTP/1.1-443]]
>  
> I’m using java 9.0.4 and Tomcat 8.5.28
>  
>  
> ===
> 
> Thank You;
> 
> Chris Cheltenham
> Technology Services
> The School District of Philadelphia
> 
> Work # 215-400-5025
> Cell # 215-301-6571

Best regards

Peter

Re: [OT] How does tomcat handle session ids?

[Peter Kreuser]

Dear all,

Forgive the top-post!

Going back to the root-cause of the question:

In my opinion the security requirement stems from the idea, that a logout must 
invalidate the session and thus make the data practically inaccessible - 
instead of just removing a typical loggedin flag and keeping the once used 
session with stored values alive.
That is essentially not a requirement to tomcat but to the developer who 
implements the webapp.

If that would always be the case (and of course for tomcat to keep track of 
active ids) would make session id reuse not a big deal.

My 2cts.

Peter

PS: Please also review “session fixation” as a side note to this problem.



Peter Kreuser
> Am 08.02.2018 um 17:14 schrieb Christopher Schultz 
> <ch...@christopherschultz.net>:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Mark,
> 
>> On 2/8/18 4:49 AM, Mark Thomas wrote:
>>> On 07/02/18 23:49, Alex O'Ree wrote:
>>> I was recently perusing security implementation guides and ran
>>> across one that required that sessions id's be "destroyed" after
>>> use and not reused. From my understanding, it looks like the
>>> java/tomcat/servlet equivalent is the jessionid. I'm assuming
>>> this is probably a randomly generated id but I honestly don't
>>> know without digging through the code base.
>> 
>> It is a securely generated random ID.
>> 
>>> If it is a randomly generated UUID it's a pretty safe assumption
>>> that a duplicate id is very unlikely and that reusing a session
>>> id for a different tomcat user session is also very unlikely. Is
>>> this correct?
>> 
>> Correct.
> 
> I did some math on this once when I was trying to figure out how to
> "size" some one-time-use tokens that I need to generate for $work. In
> my case, they really *must* be (a) ONE-time use (no, really) and (b)
> as difficult as possible to randomly-guess a valid token.
> 
> So the question was "how many bits do I need to satisfy both of these
> conditions"?
> 
> I started with Tomcat's default session-id size as a baseline. The
> default session id size (in bytes) is 16[1].
> 
> The number of possible 16-byte tokens is 2^(8*16) = 2^128 =
> 340282366920938463463374607431768211456. That is a /really/ big number.
> 
> It's so big that, if I were able to generate and test 1024 tokens per
> second, it would take me 3846145821136909354467034317940 days to try
> all combinations. That's ~10530173363824529375679765415 years. That is
> a /lot/ of years.
> 
> We ended up choosing 15 bytes because, when base32-encoded, it
> fully-fills a 24-character token without any shortfall. So we are
> limiting ourselves to a mere 160677694150154562006832 years for an
> exhaustive search. C'est la vie.
> 
> As for the distribution of the generated bytes, that depends upon the
> implementation of SecureRandom. Java says that
> java.security.SecureRandom meets the requirements of FIPS 140-2
> section 4.9.1[2].
> 
> Given the hilarious farce that is FIPS, it won't surprise you to find
> out that (a) the hyperlink from Oracle's documentation to the FIPS
> 140-2 reference does not work, (b) the hyperlink from Oracle's
> documentation to the FIPS 140-2 reference is in fact 404 Not Found,
> and (c) section 4.9.1 of the current FIPS 140-2 reference is unrelated
> to random-number generation. If you follow the rabbit-hole long
> enough, you will lose your mind. ;)
> 
> - -chris
> 
> [1]
> https://tomcat.apache.org/tomcat-8.5-doc/config/sessionidgenerator.html#
> Standard_Implementation
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp8d3sdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgchxAArwmFELprgINIeVSY
> SzZZ0kEexVub9VkBw8jsgbsfBOqeIGgFUXLZIf9aKkzX2gowu8KpU3C5eJ6Z8+Dc
> SDesMyNujG2+DS/6v6eNF8zZhaYBfafh/V/YCmX2sf1IZ44uyDuLjr9D+85a3nxI
> EvKVJESHFoaRLQP2GRY/x5t6NWFNtt7BI9OIXKbsDBX+Toz079/aoxKioCnNk1xq
> /5r8dOyTEE5ST9Z4n+dzLXYOqvWA65VVfoIQCDkA2pkkFI//TD2orOjYgz0ZtsCl
> dFygrblkrv5CFYU1pfjHw89UT0Gtsov99Ip0PE2CRJBo+NiCSbERrSCCMhzTjtHC
> fsmpBQl9ZgZRjdgq8mZOr5L6y3N3xSoAULvj0McTIdULZlQL/qQfOcenrwsZseIy
> WMywV+EDRLSNqmwoIGAEXJNI3OFaN1owehxtusYbS39f6d0DN1P8Op6E8O9RcggU
> htqO/qwuWDY0u99ho6dd3DU2vnCHrqo+VrnTIabFPg2fKv7MtXRBPoslLCCLYPvk
> G6yLk0MvHiWkoqTnxSBQoa6EVvjP0W0EZHUiYGwNTGIGPUFsaf93kaKv8E3yr0kg
> bt1p2F9xe4R8fTu/3Cm7iv2DWo6N2C7MV6xTF/kAKANyjSEXDaTvxnCluOfR/8YS
> lz81Fbclj3JOOyu9fhJlTLes1F4=
> =xn/y
> -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 Environment variables instead of Java -D properties for context.xml substitution

[Peter Kreuser]

BTW:


> Am 23.01.2018 um 13:56 schrieb Peter Kreuser <l...@kreuser.name>:
> 
> Algirdas,
> 
> 
> 
>> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas <apvei...@gmail.com>:
>> 
>> Andre, my apologies for bringing up a topic that has been repeated ad
>> nauseum.
>> 
>> We were thinking of a process like the following, which would eliminate
>> "the information has to available somewhere in a file" on the actual server
>> where Tomcat is running.
>> 
>>> cd $TOMCAT_HOME/bin
>>> set +o history
>>> export DB_USERNAME=xyz
>>> ./startup.sh
>> . once the process has started
>>> unset DB_USERNAME
>>> set -o history
>> 
>> This process does not eliminate the need to store the values of sensitive
>> information.  But by supporting environment variables, one could eliminate
>> using catalina.properties or -DDB_USERNAME, which exposes the information
>> on the server.  In our case, operations would get the data from a secure
>> vault and then run the above scripts.  I suppose we could get the same
>> effect by modifying catalina.properties, starting the server and then
>> clearing catalina.properties, until the next restart...
> 
> Where would you put that script with the text?
> Well if you use a secure vault, then that script would have to know the 
> password to the full secure vault...
> 
> You get a feel for the problem?
> 
> Run Tomcat in a dedicated service user, make the conf only readable for him 
> and restrict the access to the user’s home/tomcat dirs...
> 
> The admins of the server will have access to all the information anyhow. But 
> any other users around will not be able to read the conf, even the java opts 
> of the process will be invisible.
> 
> Just my 2cts.
> 
> Peter

the commandline parameters (-D) are also in the tomcat logs, thus probably in 
your backups and archives.

Peter 

>> Don't want to restart an old thread, so if preferred, we can stop the
>> discussion.  Thank you for your time.
>> 
>> On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) <a...@ice-sa.com>
>> wrote:
>> 
>>> Hi.
>>> 
>>>> On 23.01.2018 12:11, Algirdas Veitas wrote:
>>>> 
>>>> Thanks for the quick reply George!
>>>> 
>>>> We could, but the data is still available, in this case a file, versus in
>>>> the output of "ps -ef | grep java".  We can obviously encrypt the
>>>> sensitive
>>>> information.
>>>> 
>>>> One idea, in order to support injecting Environment Variables would be to
>>>> support a syntax of
>>>> 
>>>> ${env.DB_USER}
>>>> 
>>>> where if the subsitution property starts with "env", then the variable
>>>> could be retrieve by System.getEnv(...) otherwise System.getProperty(...).
>>> and where does the environment variable value come from ?
>>> 
>>> Isn't this the forever-recurring same "chicken-and-egg" kind of issue that
>>> has been repeated ad nauseam over hundreds of posts on dozens of forums
>>> already ?
>>> 
>>> Wherever you put any kind of "sensitive" information, in the end it has to
>>> be available *somewhere* for Tomcat (or any other server) to read. And if
>>> you encrypt it, then the key for decrypting it has to be available
>>> somewhere also.
>>> And the answer to that, is always the same in the end, no matter how many
>>> recursions you go through : the information has to be available somewhere
>>> in a file, readable *only* by the user-id under which the server runs (and
>>> of course whoever can create such a file).
>>> And if someone not authorized to do so, has access to that file, then you
>>> have bigger problems than just with the server software.
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev <gstanc...@serena.com>
>>>> wrote:
>>>> 
>>>> Can you use catalina.properties? From the docs [1]
>>>>> 
>>>>> " All system properties are available including those set using the -D
>>>>> syntax, those automatically made available by the JVM and those
>>>>> configured
>>>>> in the $CATALINA_BASE/conf/catalina.properties file."
>>>>> 
>>>>> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
>>>>> 
>>>>

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Peter Kreuser]

Algirdas,



> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas :
> 
> Andre, my apologies for bringing up a topic that has been repeated ad
> nauseum.
> 
> We were thinking of a process like the following, which would eliminate
> "the information has to available somewhere in a file" on the actual server
> where Tomcat is running.
> 
>> cd $TOMCAT_HOME/bin
>> set +o history
>> export DB_USERNAME=xyz
>> ./startup.sh
> . once the process has started
>> unset DB_USERNAME
>> set -o history
> 
> This process does not eliminate the need to store the values of sensitive
> information.  But by supporting environment variables, one could eliminate
> using catalina.properties or -DDB_USERNAME, which exposes the information
> on the server.  In our case, operations would get the data from a secure
> vault and then run the above scripts.  I suppose we could get the same
> effect by modifying catalina.properties, starting the server and then
> clearing catalina.properties, until the next restart...
> 

Where would you put that script with the text?
Well if you use a secure vault, then that script would have to know the 
password to the full secure vault...

You get a feel for the problem?

Run Tomcat in a dedicated service user, make the conf only readable for him and 
restrict the access to the user’s home/tomcat dirs...

The admins of the server will have access to all the information anyhow. But 
any other users around will not be able to read the conf, even the java opts of 
the process will be invisible.

Just my 2cts.

Peter
> Don't want to restart an old thread, so if preferred, we can stop the
> discussion.  Thank you for your time.
> 
> On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) 
> wrote:
> 
>> Hi.
>> 
>>> On 23.01.2018 12:11, Algirdas Veitas wrote:
>>> 
>>> Thanks for the quick reply George!
>>> 
>>> We could, but the data is still available, in this case a file, versus in
>>> the output of "ps -ef | grep java".  We can obviously encrypt the
>>> sensitive
>>> information.
>>> 
>>> One idea, in order to support injecting Environment Variables would be to
>>> support a syntax of
>>> 
>>> ${env.DB_USER}
>>> 
>>> where if the subsitution property starts with "env", then the variable
>>> could be retrieve by System.getEnv(...) otherwise System.getProperty(...).
>>> 
>>> 
>> and where does the environment variable value come from ?
>> 
>> Isn't this the forever-recurring same "chicken-and-egg" kind of issue that
>> has been repeated ad nauseam over hundreds of posts on dozens of forums
>> already ?
>> 
>> Wherever you put any kind of "sensitive" information, in the end it has to
>> be available *somewhere* for Tomcat (or any other server) to read. And if
>> you encrypt it, then the key for decrypting it has to be available
>> somewhere also.
>> And the answer to that, is always the same in the end, no matter how many
>> recursions you go through : the information has to be available somewhere
>> in a file, readable *only* by the user-id under which the server runs (and
>> of course whoever can create such a file).
>> And if someone not authorized to do so, has access to that file, then you
>> have bigger problems than just with the server software.
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
>>> wrote:
>>> 
>>> Can you use catalina.properties? From the docs [1]
 
 " All system properties are available including those set using the -D
 syntax, those automatically made available by the JVM and those
 configured
 in the $CATALINA_BASE/conf/catalina.properties file."
 
 [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
 
 
 -Original Message-
 From: Algirdas Veitas [mailto:apvei...@gmail.com]
 Sent: Monday, January 22, 2018 4:02 PM
 To: users@tomcat.apache.org
 Subject: Using Environment variables instead of Java -D properties for
 context.xml substitution
 
 Hi,
 
 We have a context.xml under $TOMCAT_HOME/conf that looks like this:
 
 >>>auth="Container"
type="javax.sql.DataSource"
username="${DB_USERNAME}"
password="${DB_PASSWORD}"
driverClassName="oracle.jdbc.OracleDriver"
validationQuery="select 1 from dual"
testOnBorrow="true"
url="${DB_URL}"
 />
 
 if we do something like this in setenv.sh, the substitution works great
 
 export DB_USERNAME=xyz
 export DB_PASSWORD=vvv
 
 export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
 export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
 
 However, if on a linux box, if someone did a "ps -ef | grep java", they
 would be able to see the actual values of these parameters.
 
 theuser 127734  1  0 Jan19 ?00:04:39 /opt/java/bin/java
 -Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
 

Re: Activating Tomcat 8.5 APR on RHEL7

[Peter Kreuser]

Hi Jean-Pierre,

> Am 15.01.2018 um 15:45 schrieb Jean Pierre Urkens 
> :
> 
> I am having problems getting the apr library discovered by Tomcat 8.5. This 
> is what I tried:
>  
> 1.  I installed Tomcat-8.5 on RHEL-7.
> 2.  As the native tomcat apr libraries wheren’t available on RHEL I made 
> them myself as instructed by 
> http://tomcat.apache.org/tomcat-8.5-doc/apr.html. After that the tomcat 
> native apr libraries where present under ‘/usr/local/apr/lib’.
> 3.  To get this library path included in java.library.path I tried:
> a.  Create/modify $TOMCAT_BASE/bin/setenv.sh to include the following two 
> lines:
>LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/apr/lib
>export LD_LIBRARY_PATH
> After restarting tomcat the catalina log shows the message:
> 15-Jan-2018 13:03:31.778 INFO [main] 
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based 
> Apache Tomcat Native library which allows optimal performance in production 
> environments was not found on the java.library.path: 
> [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
> 

Set this variable using JAVA_OPTS with -Djava.library.path=/usr/local/apr/lib


> Apparantly the LD_LIBRARY_PATH isn’t taken up by catalina?
> b.  I also tried setting environment variables via the command prompt:
> #> TOMCAT_HOME=/opt/tomcat8;
> #> export TOMCAT_HOME
> #> TOMCAT_BASE=/var/lib/tomcat8/nodes/node1; 
> #> export TOCAT_BASE
> #> LD_LIBRARY_PATH=$LD_LIBARAY_PATH:/usr/local/apr/lib;
> #> export LD_LIBRARY_PATH
> #> /opt/tomcat8/bin/startup.sh start
> 
> But also that is giving the same AprLifecycleListener  message?
>  
> Could someone clarify what the right way is to get the apr libraries on the 
> java.library.path of Tomcat8.5?
>  
> Met vriendelijke groet,
> Jean Pierre Urkens
> System Architect
> Adv. Dev and Cloud Integration
> +32 (0)14 722162
> +32 (0)478 838336
> jean-pierre.urk...@devoteam.com
> 
> 
> 
> 
> 
> Maatschappelijke zetel Devoteam NV/SA
> Belgicastraat 17  - 1930 Zaventem
> VAT: BE 0466.475.275  /  RPM Bruxelles - RPR Brussel
>  
>  

Best regards

Peter

Re: Apache Tomcat 8.5.24 SSL Configuration

[Peter Kreuser]

Thomas,

> Am 22.12.2017 um 15:38 schrieb Thomas Delaney :
> 
> I apologize for the poor grammar in my last response and extra email. The
> site I have setup is internal only. I will not be able to test the site
> using SSL Labs.
> 

You may try https://testssl.sh and download the script from there.
That works in internal networks.

It even simulates connects with different clients (eg Chrome)

Peter

> On Fri, Dec 22, 2017 at 9:37 AM, Thomas Delaney 
> wrote:
> 
>> The site is internal so I won't not be able to check via ssllabs
>> 
>>> On Thu, Dec 21, 2017 at 5:36 PM, George S.  wrote:
>>> 
 On 12/21/2017 3:24 PM, Thomas Delaney wrote:
 
 Thank you for the input so far!
 
 I have used both java versions jdk 1.7.0_79 and jdk1.8.0_152 and still
 receive the same result
 
 when running the openssl s_client command I recieved this as the Cipher
 and
 SSL version
 Protocol  : TLSv1.2
 Cipher: DHE-RSA-AES256-GCM-SHA384
 
 I also get a message saying  "verify error:num=20:unable to get local
 issuer certificate"
 "Verify return code: 20 (unable to get local issuer certificate)"
 
>>> 
>>> I second Chris Schultz's recommendation that you run the site through the
>>> SSL Labs testing site and see what it points out. It's going to check a lot
>>> more things right off the bat and display them in an easier format:
>>> 
>>> https://www.ssllabs.com/ssltest/
>>> 
>>> 
>>> 
>>> 
>>> 
 On Thu, Dec 21, 2017 at 2:31 PM, Christopher Schultz <
 ch...@christopherschultz.net> wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
>> On 12/21/17 2:38 AM, l...@kreuser.name wrote:
>> 
>> Hi Thomas,
>> 
>> Am 21.12.2017 um 00:56 schrieb Thomas Delaney
>>> :
>>> 
>>> Greetings,
>>> 
>>> I am having trouble regarding google chrome's behavior to Apache
>>> Tomcat's SSL setup. I have been successful getting an ssl website
>>> to work with Apache HTTP web server, but not Apache Tomcat 8.5.24
>>> on google chrome. Mozilla Firefox brings me to my site with no
>>> problem.
>>> 
>>> When going to https://mydomain.com:8443 I recieve a message from
>>> Google Chrome.
>>> 
>>> Google Chrome Error - This site can’t provide a secure
>>> connection mydomain.com uses an unsupported protocol.
>>> ERR_SSL_VERSION_OR_CIPHER_MISMATCH
>>> 
>>> Unsupported protocol The client and server don't support a common
>>> SSL protocol version or cipher suite.
>>> 
>>> When checking Google Chrome's Browser console in the security tab
>>> I recieve: Page is not secure Valid certificate secure resources
>>> 
>>> Here is the following background info I have for the
>>> configuration I gave Apache Tomcat when setting up the 8443
>>> connector
>>> 
>>> Chrome Version 63.0.3239.108 (Official Build) (64-bit)
>>> 
>>> Linux OS: SUSE Enterprise 12 sp1
>>> 
>>> Packages installed:
>>> 
>>> - OpenSSL 1.0.2n  7 Dec 2017 - jdk version 1.7.0_79
>>> 
>> That may be the culprit.
>> 
>> Apparently this (old) version of Java7 will not provide in the
>> default modern ciphers that Chrome requires. And the config is
>> using the JSSE SSL implementation. But as you have TC Native and
>> openssl 1.0.2 you should switch to openssl.
>> 
> This probably isn't the problem since Thomas is using the APR
> connector. TLS cipher suite support (or lack thereof) from Java 1.7 is
> not relevant.
> 
> - tomcat version -> apache-tomcat-8.5.24 - apr-1.6.3 -
>>> tomcat-native-1.2.16-src
>>> 
>>> Server.xml apr connector (Certificates are signed from GoDaddy
>>> and are placed in the conf directory of Apache Tomcat):
>>> 
>>> >> protocol="org.apache.coyote.http11.Http11AprProtocol"
>>> maxThreads="150" SSLEnabled="true" defaultSSLHostConfigName="
>>> mydomain.com" > >> protocols="TLSv1,TLSv1.1,TLSv1.2"> >> certificateKeyFile="conf/server.key"
>>> certificateFile="conf/server.crt"
>>> certificateChainFile="conf/CA_server_bundle.crt" type="RSA" />
>>>  
>>> 
>> This looks okay to me. If you start Tomcat and then use "openssl
> s_client -connect :", does openssl connect? It should
> report the protocol and cipher suite being used to connect.
> 
> If you server is externally-accessible, consider using an external TLS
> capabilities scanner such as that from Qualys,
> https://www.ssllabs.com/ssltest/
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlo8C/0dHGNocmlzQGNo
> 

Aw: Trouble with TLS/SSL and Tomcat 8.5.23

[Peter Kreuser]

Richard,





> Gesendet: Mittwoch, 22. November 2017 um 14:40 Uhr
> Von: "Richard Tearle" 
> 
> An: users@tomcat.apache.org[mailto:users@tomcat.apache.org]
> Betreff: Trouble with TLS/SSL and Tomcat 8.5.23
> Hello
> 
> Apache Tomcat 8.5.23
> Centos 7.4 (3.10.0-514.16.1.el7.x86_64)
> Java 1.8.0_152 (with jce)
> Running in Docker Container
> 
> I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23,
> but when trying to get TLS/SSL working on a connector I get the
> following error:
> 
> 22-Nov-2017 11:52:46.098 SEVERE [main]
> org.apache.coyote.AbstractProtocol.init Failed to initialize end point
> associated with ProtocolHandler ["https-jsse-nio2-18443"]
> java.lang.IllegalArgumentException:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
> at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
> at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
> at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
> at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982)
> at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
> at 
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:997)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at 
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at 
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:644)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> Caused by: java.security.InvalidAlgorithmParameterException: the
> trustAnchors parameter must be non-empty
> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
> at 
> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368)
> at 
> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292)
> at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
> ... 20 more
> 
> I've changed the connector configuration to use
> SSLHostConfig/Certificate, but our certificate generation process
> (self signed certificates) has remained the same. I did a quick
> internet search, and saw that other people had similar, but not exact
> issues, and going back to 8.5.4 "solved" the issue. So I did this as a
> quick test, so at least I could see that our configuration changes
> where correct, and yes the application ran ok with Tomcat 8.5.4. The
> connector configuration is:
> 
>  protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true" server="Apache" maxPostSize="10">
>  sslProtocol="TLSv1.2" protocols="TLSv1.2"
> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
> truststoreType="PKCS12"
> truststorePassword="${truststore.pass}" honorCipherOrder="true"

The error message says that either the file simply is not there or the cert 
that you expect is not in the keystore, maybe even empty...

Peter

> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> 
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
> 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> 
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
> 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> 
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
> 
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> 
> 

Re: URL-encoding and "#"

[Peter Kreuser]

Chris,




Peter Kreuser
> Am 13.10.2017 um 04:29 schrieb Christopher Schultz 
> <w...@christopherschultz.net>:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> James,
> 
>> On 10/12/17 8:44 PM, James H. H. Lampert wrote:
>> Question:
>> 
>> The application we're developing has a suite of web services
>> (RESTful, Swagger-based), and at least one of them can accept a
>> pound sign ("#") as a URL parameter.
>> 
>> Several months ago, with the application and all of its services
>> running on Tomcat 7, it was accepting a plain, naked # in the URL.
>> Now, running on Tomcat 8.5, it's returning an error message
>> ("HTTP/1.1 400").
> 
> No client should ever send a naked # to a server. It's a violation of
> the spec, full stop. That isn't to say that Tomcat should fail in any
> particular way, but Tomcat is well within its rights to say "a # is
> not allowed in a URL, so this is a bad request".
> 

Nevertheless there is AFAIR a commandline switch to set TC 8.5 to the old 
behavior.

James, please browse the mail archives.
From a quick look this seems to help, for a short term solution:

https://marc.info/?l=tomcat-user=150183715500537=2

Please nevertheless fix the client, for a better world as Chris pointed out ;-P.

Best regards

Peter

>> The developer (in a different time zone) has explained about 
>> URL-encoding, but hasn't said whether there was anything in his
>> code to make it stop tolerating the naked # sign.
>> 
>> Did the change from Tomcat 7 to Tomcat 8.5 have anything to do
>> with this?
> 
> Each version of Tomcat gets more and more strict about the garbage it
> will accept from clients. This is done to improve the world as a
> whole, and also improve security when it comes to things like
> converting URL paths into filesystem paths, etc. Strictly speaking,
> everything should *always* be safe, but it helps to stop The Badness
> at the earliest opportunity.
> 
>> And if so, are there any other common ASCII characters that used
>> to be accepted as characters, but now have to be URL-encoded?
> Anything in the URL spec that is allowed should be allowed. Clients
> should expect that anything not mentioned in the spec would be
> rejected by a compliant server.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJRsACgkQHPApP6U8
> pFhqMg//cP4U9z0v8AzkdGRfWJilIAVdsgbA8fdfqTM0f542GzHo4tWidx6F89zK
> y2oVxz9Fr4RQev2Dgr5DyPrJnv2JYufe2S3AxBltA1jQQCu6GnqEjgzxlvmrGY05
> hhrBYBBOgBudgLXcK4bHuoIk+W5ke1Hc1n94WqyVDq2EJZUibKLJLGo3nsAItBcS
> a7jFitbzAQT/0fX/Nzo/LFanNNLenOkoKxZA0KyqzDYiwOGcsLLukOIV1AOiWgEU
> cy4dFhYkixoi8lfs5SjivNknp5tDJSq6Rf3UYChkXUcwQUTVA45AecRWvaEihwjr
> fFN91h9AVKXoVBVNjPYLKS7K7ODahR6oLNqta/2aji4QgCBnyfrPvopIG7e6fbM8
> BYo+MfpbrVi8b7ZL69d2Cl8+/6MmcUbWfuPzZsBm9Mg7tdza13NQ0vin3uyv0y6N
> 73ytO57G1CVfFK3T8v6giEMt6URpBzviF1PK0gTpBImZO13eXYVO5D8E0cXp0Q2d
> cTSC120wgwIhN4tBlrf2asjdut+0K7cpYpuAQVHFCacedhdTxDPR+OoWo4zRoYuI
> 3D776j6OoyxGCmU2GNR9kNK8q3fuVouplCapdRKPPqlbskCzmfb70SjevVGX3sAT
> /OwMwonndlCQoFOob4zg03a2rnKMritVcflffeYmih0Xm+UU7QY=
> =SwD9
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[Peter Kreuser]

Christopher,




Peter Kreuser
> Am 10.10.2017 um 00:14 schrieb Christopher Schultz 
> <ch...@christopherschultz.net>:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> James,
> 
>> On 10/9/17 5:19 PM, Christopher Schultz wrote:
>>> On 10/6/17 6:34 PM, James H. H. Lampert wrote:
>>> Noting that my connector tag is written using Tomcat 7 connector 
>>> syntax, is there a good example of how to code a ciphers clause
>>> for that tag?
>> 
>> Tomcat 8.5+ and 9.0+ can do it... but nobody has written a 
>> command-line tool around that capability. (I could have sworn such
>> a tool existed already. I guess I'll write one.)
> 
> Okay, it's in Tomcat 9, now. Grab Tomcat 9 trunk, build it ("ant
> deploy"), then run:
> 
> $ output/build/bin/ciphers.sh [cipherspec]
> 
> where "cipherspec" is an OpenSSL-style cipher suite spec, like:
> 
> $ output/build/bin/ciphers.sh 'DEFAULT'
> 
> This gives you the JVM's current default, and dumps-out all of the
> IANA-style cipher suite names. So if you want to add one cipher suite
> to the default Java suites, just do this:
> 
> $ output/build/bin/ciphers.sh 'DEFAULT'
> 
> and then add this to the end:
> 
> TLS_RSA_WITH_AES_256_CBC_SHA
> 
> (Unless TLS_RSA_WITH_AES_256_CBC_SHA is already present in the list.)
> 
> Note that the "DEFAULT" list has a bunch of junk you don't need.
> Specifically, you can probably get rid of all of these things with no
> ill effects, and your configuration will "look" simpler:
> 
> $ ./bin/ciphers.sh '!PSK:!aNULL:!DSA:!SRP:!DSS:HIGH'

A good read on the appropriate (openssl) cipher string that I use can be found 
here:
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
Hynek explains the whys and don'ts and updates the string on a regular basis!

HTH

Peter

> Hope that helps,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb9NkdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFisoA//bj9GFzlMaZdPYXHt
> y2iQIToESUg6Wa8vU5lQscLDfqtXeAIawiXusILz/th1fCu1usy8HeC/5nBINXAQ
> McbEUSRiq6YitPXDIwXqbOGZS76vxmheFPTst6gHCN6hNOYbFEbejK3cxX8s0Bbg
> kXtqcrnnN+a+J5UZmFeB3tctQfwsVLyGcvcwzDRTjFCIjrD1CwdEd+Ckk740jCFU
> HXgEewO6rVnxAx80hP2c9ztsHblNt0KFm4zMtWjxmHTigac1EEA1ZAi5P3nIJu5n
> 7HIw0jVX3qZHamVHXWSPb7skEZY/wj7Kko8XmJFWS0bbwuaTQJ+Pr8ZJPT145/Tb
> F0w6PqPqiR9sre7Yvy4v9y/QOqFjujEqMzkTNedRaBEItmzELPkYBBms2b2bkIVj
> bMptV5FidCthzvJAnQ5efuiG9qYCuHajNEjQM4Mhu0t95yolmh4+yD2yxA4sS35W
> YPxy24tgY9A2nNpJS+QSWtCzkQBJz+0Uxnw8y3AbW2oRkA649i+9+KppSAqCx7kH
> QYUSwTD+7aETlVthfANEr5D/MbzJbflhTjXl/bZjuEc2p1tWPxZrqC+E8FwniMLL
> NYwK4rMDrSZfrgY7mn6uPcTxzEIMTj/KvtaZCFY1GRAlAf16vNVlnCHQzMvlYKGW
> gtqS2tF9DBurCs65qocxtWLAQwU=
> =bEIh
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: Enforcing server preference for cipher suites

[Peter Kreuser]

Harish,


> Am 10.10.2017 um 00:00 schrieb Harish Krishnan :
> 
> Thanks for the response, Chris.
> 
> Below are my answers in order.
> To keep the response as short as possible, i have not included the ciphers
> list in the connector -
> 
> a) Tomcat 7.0.79 (will be updating to 7.0.82)
> b) JRE 1.80_144
> c) Our connector configuration is below.
> d) We are using NIO.
> e) I am using a simple java client that makes TLS connection to our tomcat
> on below port. I am capturing the SSL handshake.
> The way i tested the client preference is: Lets take the same example i
> gave in my first email i.e. clients preference is ABCDEF and the tomcat
> servers preference is DEFABC with *useServerCipherSuitesOrder* set to true.
> During the 1st handshake connection, "A" cipher suite was chosen. I removed
> "A" from my tomcat connector, restarted the service, and did the connection
> test again.
> "B" was chosen during this 2nd handshake. Same test was continued and
> observed that CDEF were chosen next in order.
> I am expecting DEFABC as the order of preference as per the
> *useServerCipherSuitesOrder* setting.
> 
I believe that there is a misunderstanding. Your simple client does not seem to 
handle the situation correctly (even not at all).
I think if you request cipher B you will get B.

Please check with a ssl-tool like sslyze or testssl.sh. If your site is 
available on the internet, you could try ssllabs.com.

The settings seem to be OK, unless I do not see an incorrect formatting on my 
phone.

HTH,

Peter

> Let me know if i am missing anything or is my understanding is incorrect.
> 
> id="orion.server.https"
>acceptCount="100"
>*useServerCipherSuitesOrder*="true"
>ciphers="we have around 20 cipher suites listed..."
>clientAuth="want"
> 
> compressableMimeType="text/html,text/xml,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json"
>compression="on"
>compressionMinSize="2048"
>disableUploadTimeout="true"
>enableLookups="false"
>keystoreFile="keystore/xyz"
>keystorePass=""
>maxConnections="500"
>maxHttpHeaderSize="8192"
>maxKeepAliveRequests="500"
>maxThreads="250"
>minSpareThreads="25"
>noCompressionUserAgents="gozilla, traviata"
>port="8443"
>processorCache="500"
>protocol="org.apache.coyote.http11.Http11NioProtocol"
>scheme="https"
>secure="true"
>server="Undefined"
>sessionCacheSize="400"
>SSLEnabled="true"
>sslProtocol="TLS"
>sslEnabledProtocols="TLSv1.1, TLSv1.2"
>truststoreFile="keystore/xyz"
>truststorePass=""
>truststoreType="jks"
>URIEncoding="UTF-8" />
> 
> 
> On Mon, Oct 9, 2017 at 2:06 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Harish,
>> 
>>> On 10/9/17 12:31 PM, Harish Krishnan wrote:
>>> Need your expert input here. Not sure what I am doing wrong,  but I
>>> cannot get this server preference cipher suites feature working.
>>> 
>>> My setup: Latest tomcat 7.x build (which supports
>>> useServerCipherSuitesOrder attribute) Latest Java 1.8 build.
>>> 
>>> No matter what value I set to this attribute (true OR false OR
>>> undefined which is by default), I always see the Clients preference
>>> picked. As an example, if clients order is ABCDEF, and servers
>>> order is DEFABC, no matter what value I set to this
>>> useServerCipherSuitesOrder attribute, always the order selected is
>>> ABC...
>> 
>> What exact version of Tomcat are you using?
>> What exact version of Java are you using?
>> 
>> Please post your  configuration, minus any secrets.
>> 
>> Do you know if you are using the BIO, NIO, or APR connector?
>> 
>> How are you determining client-preference?
>> 
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5M4dHGNocmlzQGNo
>> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh+zxAAy11WLuuRfIQBdP/C
>> qt+eW8qFulTBX1eYGfNdCcTBnTRRTqpI1GVIT//XKkcqwLmh/0jwQSK1kRfkkHhK
>> j1V4djhQwoVtpNxP38WxsSr9yMczZNKK7OzTIEULeQqJJJTIUfGj00ayHIW/gp1p
>> MdqFw8CCwk4Xuwpz8PYeXgYPPq7EFvyU6ABs70rrJ7ZT0yRiJHQ/fmNdHekUa63s
>> n4+TB6BFzKIc11atGdpoHh4EXfaLMxeFWD6FVSH17FTQVqYxdDFQm32XcRgPP6If
>> xYPQpbN8Yb5dl2jhU1u9hvgGnDUccVCKooeEZ/fsu7whztNlR6bDl2lWVJkyO+m0
>> RJhCNI051iEf6+pbqlj2TaqeWjlxMFozLS8gwhO5usf/ZvrhYFkOanF2KRxkKaaR
>> /xwOvuSot06w+BVicbS0jbPiaEOux140ZUuPIxgi462mVIncYsW/oZvsbhrCoA7O
>> 

Re: encodeURL, jsessionid and mod_rewrite ?

[Peter Kreuser]

Peter Kreuser

> Am 04.10.2017 um 02:44 schrieb Christopher Schultz 
> <ch...@christopherschultz.net>:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Laurant,
> 
>> On 10/3/17 5:17 PM, Laurent Perez wrote:
>> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
>> "foo" war is deployed at /foo context path under tomcat. The /foo
>> path is not public, apache has a rewrite rule defined as : /bar/* 
>> rewrites internally to /foo/*.
>> 
>> I'm using jstl and its  for every url in my
>> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
>> cookie is not yet set (1st requests)
>> 

adding to Christopher, accepting the jsessionid from the Url is a bad security 
risk (Session fixation). So you should disable that by accepting the session 
only via COOKIE via

COOKIE 
then at least this rewriting problem is gone.

Peter

>> Now my question is : the  results in a
>> "/foo/page.jsp;jsessionid=..." I want the result instead as
>> /bar/pages.jsp;jsessionid=
>> 
>> Should I go straight for a HttpServletResponseWrapper replacing
>> every /foo/ with /bar/ or is there a more elegant way ? If the
>> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
>> mod_headers to pass the original path instead of hardcoding /bar/
>> ?
> 
> You are going down a path that will produce endless problems, hacks,
> and ugly solutions to those problems. It will be much easier for you
> to simply re-name your application from "foo" to "bar" and not worry
> about any of this rewriting foolishness.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
> f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
> f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
> OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
> bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
> GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
> MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
> VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
> jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
> QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
> /LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
> j/5ZMvfJiUZdDAdQxoFH6B9ochU=
> =0zb2
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: tomcat ssl setup

[Peter Kreuser]

John,


> Am 27.09.2017 um 18:08 schrieb John Ellis :
> 
> 
> 
> John Ellis
> 
> 405.285.2500 office
> 
> 
> 
> 
> http://biz-e.io
> 
> 
> -Original Message-
> From: l...@kreuser.name [mailto:l...@kreuser.name] 
> Sent: Tuesday, September 26, 2017 3:26 PM
> To: Tomcat Users List 
> Subject: Re: tomcat ssl setup
> 
> John,
> 
> 
> 
>> Am 26.09.2017 um 21:26 schrieb John Ellis :
>> 
>> Yesterday my boss suggested setting up Tomcat vers. 8 as he thought this is 
>> what Jira and/or Confluence would use so I did that and it worked fine on 
>> http port of 8080. I then edited the server.xml file again for the SSL port 
>> and got the same result as before; never gets to a webpage login using the 
>> secure port of 8443 but I can still get the webpage on port 8080. When I 
>> look at the Tomcat 8 Catalina log file I see several lines where it says- 
>> "java.security.KeyStoreException: Cannot store non-PrivateKeys". I have been 
>> googling that error and found a couple of posts saying to change from JKS to 
>> JCEKS but when I ran the commands I didn't have JKS in the command; only RSA 
>> for the algorithm. Can someone provide me with the proper keytool commands 
>> that I need to use to create an SSL certificate for Tomcat?   
>> 
>> John Ellis
>> 
>> 405.285.2500 office
>> 
>> 
> 
> 
> We’re talking about Tomcat 8.5, 8.0 is EOLed so it may not make sense to ride 
> a dead horse, also SSL setup has changed quite a bit in 8.5/9.0.
> 
> So my setup is as follows:
> 
> server.xml:
> 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
>allowTrace="false"
>maxThreads="150"
>SSLEnabled="true"
>compression="off"
>scheme="https"
>server="Apache Tomcat"
>secure="true"
>defaultSSLHostConfigName=“ localhost” >
>hostName="localhost"
>honorCipherOrder="true"
>certificateVerification="none"
>protocols="TLSv1.2"
>
> ciphers="ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-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-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS">
>  certificateKeystoreFile="${catalina.base}/conf/ssl/jssecacerts"
>  certificateKeystorePassword="changeit"
>  certificateKeyAlias="tomcat"
>  type="RSA" />
>
>  
> 
> https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl
>  
> 
> 
> I use openssl to create the certs (as let’s encrypt for an official cert will 
> generate the same structure) and then convert to JKS:
> 
> openssl genrsa -aes256 -out server.key 4096 -subj 
> "/C=XX/ST=XX/L=XX/O=XX/CN=localhost"
> openssl req -new -key server.key -out server.csr -sha512  -subj 
> "/C=XX/ST=XX/L=XX/O=XX/CN=localhost/emailAddress=x...@xx.com"
> #there is more to it to get SAN extensions, but that’s not necessary to get 
> it running
> 
> openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out 
> server.crt # you may need your own ca and a signing-process to make this work 
> in all browsers
> 
> #Verify Server Cert
> openssl x509 -in server.crt -text -noout
> 
> openssl pkcs12 -export -in server.crt -inkey server.key -out jssecacerts 
> -name tomcat keytool -list -v -keystore jssecacerts -storepass changeit
> 
> 
> Hope this helps for a start.
> 
> Regards
> 
> Peter
> 
> Peter I have never seen entries in the "" part of the 
> server.xml file. Does that have to be in there for SSL to work in Tomcat?
> 
That's the way you define one Connector on one port with different certificates 
in TC 8.5 and 9.0.
I guess that's one of the important new features!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -
> 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: "Cannot store non-PrivateKeys" exception moving from 8.0.37 to 8.5.20 - Linux

[Peter Kreuser]

Peter Kreuser

> Am 21.09.2017 um 18:19 schrieb Sean Dawson <sean.dawson2...@gmail.com>:
> 
> Hello,
> 
> We migrated our application that was running fine on 8.0.37 to 8.5.20 and
> on startup we receive:
> 
> java.lang.IllegalArgumentException: java.security.KeyStoreException: Cannot
> store non-PrivateKeys
> 
> I unfortunately deleted the logs and under time pressure we had to go back
> to 8.0.37 so I don't have the full stacktrace. But I didn't see anything
> else in them that looked helpful.
> 
> I've googled and couldn't really get any good answers that applied to
> us.This seemed a bit similar but we do have sslEnabled set (and the issue
> is apparently fixed)...
> 
> http://tomcat.10.x6.nabble.com/SSL-inconsistency-td5052956.html
> 
> I've tried modifying the connector based off the current 8.5
> documentation.  But always get the above.
> 
> We're on: CentOS release 6.9 (Final),
> Java version "1.8.0_144"
> 
>maxThreads="150" SSLEnabled="true" asyncTimeout="6"
> compression="on"
>scheme="https" secure="true" >
>sslEnabledProtocols="TLSv1,TSLv1.1,TLSv1.2"
>sslProtocol="TLS"
>certificateVerification="false" >
>certificateKeystorePassword="masked"
> type="RSA" />
>
>

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

[OT]Re: Tomcat server apparently bouncing up and down

[Peter Kreuser]

Talking nicely and understandingly to it won't help either, I guess...

Have a nice weekend
Peter

> Am 19.08.2017 um 08:31 schrieb André Warnier (tomcat) :
> 
> 3 kids raised, 30 years of programming talking : slap it.
> 
> 
> -
> 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: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[Peter Kreuser]

That's what I tried to say... sorry I was maybe not specific enough...

Peter

> Am 17.08.2017 um 02:29 schrieb James H. H. Lampert :
> 
>> On 8/16/17, 11:43 AM, André Warnier (tomcat) wrote:
>> , , ,
>> So as a start, look at /etc/init.d/tomcat7 on your system, and check
>> what other files this calls/references. One important thing here, is
>> what the environment variable CATALINA_BASE ends up containing.
> 
> Ok. This is starting to look interesting. CATALINA_BASE seems to be set to 
> /var/lib/tomcat7.
> 
> And when I do an "ls -l" on /var/lib/tomcat7, I find that "conf" is a 
> symbolic link to /etc/tomcat7, and "logs" and "work" are also symbolic links.
> 
> Now THIS is interesting: in /etc/tomcat7/Catalina/localhost, I find a couple 
> of files, "manager.xml" and "host-manager.xml," and both of them contain a 
> "Context" tag with a docBase pointing to where the corresponding contexts 
> live.
> 
> Am I getting any closer to understanding how this works?
> 
> --
> 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: Where Tomcat webapp contexts live on Debian

[Peter Kreuser]

I'd assume the service that starts tomcat sets the bin-Dir, that contains a 
setenv.sh, that has the CATALINA_HOME and BASE env-Varaibles, where you find 
the context-Files that have a docbase.

I'd like to repeat the question: who did this setup?

Peter Kreuser

> Am 15.08.2017 um 23:45 schrieb James H. H. Lampert <jam...@touchtonecorp.com>:
> 
> I think I've mentioned before that I have a Tomcat server on a Google Compute 
> Debian instance, that I installed with an "apt-get," rather than from an 
> Apache download.
> 
> I had to apt-get manager separately, which is odd to begin with.
> 
> And things ended up in unexpected places.
> 
> Some stuff (like the Catalina directory) wound up in /etc/tomcat7. Other 
> stuff (like the bin and lib directories) wound up in /usr/share/tomcat7.
> 
> But the weirdest thing is where the webapp contexts wound up. The default 
> ROOT context (which doesn't look quite like the default ROOT context of 
> anything I've installed from an Apache download) is in 
> /var/lib/tomcat7/webapps/ROOT. But the manager and host-manager webapps are 
> in /usr/share/tomcat7-admin/manager and /usr/share/tomcat7-admin/host-manager.
> 
> Setting aside any questions of why whoever set this up for Debian did it this 
> way, all of this still raises a very big question:
> 
> How is Tomcat finding all of this?
> 
> --
> 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: No traffic after upgrade to Tomcat 8.5.16 (loadbalancing issue)

[Peter Kreuser]

 Bernd,



> Am 01.08.2017 um 11:01 schrieb Bernd Wahlen :
> 
> Hi M, Peter and Christoph,
> 
> >Have you tried taking the affected server out completely from the >farm? In 
> >this way, you have 4 tomcats seen by the loadbalancer. Once >you have done 
> >the upgrade, re-register this server with your load >balancer.
> 
> >If not, can the F5 reach your server, can you reach the HC-page?
> 
> i have no access to the load balancer, because it's shared infrastructure.
> 
> >Also, have you checked whether your server.xml file and other settings
> >files are correct/as per your original settings - or is there any
> >adjustment that's required?
> >I am assuming that all you want to do is upgrade tomcat, so your >server.xml
> >should have the identical settings to your other 4 tomcats.
> 
> of course: webapps, server.xml etc. all the same and if i make a request
> direct against the upgraded server - no problem at all.
> 
> >Do the access logs contain anything on the server running 8.5.16?
> 
> >Do you see F5-healthcheck-requests in your accesslogs? If so, did you 
> >>compare the old and new responses?
> 
> tomcat 8.5
> 213.221.109.131 - - [01/Aug/2017:09:39:49 +0200] "GET / " 404 1070 "-" "-" "-"
> 213.221.109.130 - - [01/Aug/2017:09:39:51 +0200] "GET / " 404 1070 "-" "-" "-"
> 
> tomcat 8.0
> 213.221.109.130 - - [01/Aug/2017:09:57:18 +0200] "GET / " 404 994 "-" "-" "-"
> 213.221.109.131 - - [01/Aug/2017:09:57:19 +0200] "GET / " 404 994 "-" "-" "-"
> 
From my perspective the Tomcat is working, responding and serving content.

That leads to the thought, that the F5 is not evaluating the response correctly.
In my opinion you should talk to the admins and ask them why they are not 
activating your service.
The Healthcheck of the F5 usually checks for certain data. 404 responses are 
strange but may also work.

The responses differ in size, so, there may be the problem (content and/or 
header differ!).  The new response is larger, so it's not only missing the 
Server header!

Peter

> The only difference that i see is that the Server Header is removed in 8.5 
> Server →Apache-Coyote/1.1
> 
> But that is not the problem, i checked in both directions: adding
> the header to 8.5 and remove it from 8.0.
> I also tried to add a empty index.html to GET 200 for the health-
> checks, no changes.
> 
> >Is the F5-HC checking for specific values, headers, response codes?
> 
> from my point if view not, just a port 80 check without checking
> the response.
> >You can also use the default null Receive String value [""]. In this >case, 
> >any content retrieved is considered a match. If both the Send >String and 
> >Receive String are left empty, only a simple connection >check is performed.
> >https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_monitors.html
> 
> >Are you actually using AJP between F5 and Tomcat? I would find that an
> >unusual setup... usually F5 -> Tomcat would be HTTP(S).
> 
> I don't know if this connector is needed (maybe for https session stickyness 
> - i don't know how it is working exactly) I just tested any port/connector to 
> find differnences.
> 
> 
> Many thanks in advance,
> 
> Bernd Wahlen
> K2 Interactive GmbH
> 
> -
> 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: No traffic after upgrade to Tomcat 8.5.16 (loadbalancing issue)

[Peter Kreuser]

Hi Bernd,
 

> Am 31.07.2017 um 19:17 schrieb Bernd Wahlen :
> 
> Thanks for your help,
> 
> what do you mean with take it off the server farms first?
> 
> The upgrade process is like this:
> stop tomcat
> change symlink to new version
> start tomcat
> 
> loadbalancer detect that the server is down and routes the traffic
> to the other hosts.
> This is like we always do since tomcat 6.
> After downgrading back to the old version load is comming back fast.
> 
> Because of the shared infrastructure every change to the
> loadbalancing pools must be ordered and costs money.
> 
> 
> 
>> On 07/31/2017 07:04 PM, M. Manna wrote:
>> When you upgraded the affected tomcat from 8.0.45 to 8.5.16, Did you take
>> it off the server farms first? Or did you do it without?
>> Try to remove the affected tomcat off the server farm. Do you upgrade, and
>> then put it back inside the farm.
>> 
>> Or have you tried this already?
>> 
>> On 31 July 2017 at 17:59, Bernd Wahlen 
>> wrote:
>> 
>>> 
>>> We are running a cluster of 5 tomcats behind
>>> a loadbalancer (shared big ip f5).
>>> Traffic is http, https and websocket.
>>> After upgrading one of the servers to
>>> Tomcat 8.5.16 this server get no traffic anymore.
>>> Everything is running fine until 8.0.45.
>>> If i connect directly against the node
>>> with 8.5, everything is running fine also,
>>> so it must be a issue related to the loadbalancing
>>> or loadbalancing checks.
>>> 
>>> I read the changes and tries the following
>>> 
>>> 1.)
>>> https://www.joedog.org/2016/02/28/test-connectivity-to-an-aj
>>> p-server-with-ajping/
>>> => AJP is still working
>>> 
>>> 2.)
>>> Configure CookieProcessor to LegacyCookieProcessor
>>> 
>>> but no success.
>>> Any idea what to i can check or what changed related
>>> to that problem?
>>> 
>>> Many thanks in advance,
>>> 
>>> Bernd Wahlen
>>> K2 Interactive GmbH
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>>> 
>> 
Do you see F5-healthcheck-requests in your accesslogs? If so, did you compare 
the old and new responses? 
If not, can the F5 reach your server, can you reach the HC-page? 
Is the F5-HC checking for specific values, headers, response codes?

Peter

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

Re: Server giving 404 since upgrade to Tomcat7

[Peter Kreuser]

Hi all,

> Am 25.07.2017 um 21:00 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
>>> On 7/25/17 11:14 AM, Peter Flynn wrote:
>>> On 24/07/17 11:57, Mark Thomas wrote:
>>> On 24/07/17 11:12, Flynn, Peter wrote:
>> 
>> I must apologise first for unintentionally misleading you: the
>> upgrade was from Tomcat 7.0.54-2 to 7.0.69-11, not from 6 to 7. I
>> inherited this along with what was clearly bad information.
> 
> Thanks for the clarification.
> 
>>> Running from a package tends to limit the members of this that
>>> are available to help to those that understand the packaging on
>>> the platform in question.
>> 
>> I'm afraid so. But I hope this is not about packaging, but about 
>> modifying the configuration.
> 
> Probably so, especially because it was a minor version upgrade.
> 
>>> Tomcat needs allowLinking to be correctly set if that path to a
>>> web application (or the web application itself) uses symlinks. I
>>> don't think that has changed between 6.0.x and 7.0.x.
>> 
>> There seem to be two, but I have never used or touched examples.
>> 
>> # find /var/lib/tomcat/webapps -type l -ls 5369297260
>> lrwxrwxrwx   1 tomcat   tomcat 40 Aug 11  2016 
>> /var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar -> 
>> /usr/share/java/jakarta-taglibs-core.jar 5369297270 lrwxrwxrwx
>> 1 tomcat   tomcat 44 Aug 11  2016 
>> /var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar -> 
>> /usr/share/java/jakarta-taglibs-standard.jar
> 
> That looks like the package manager's doing, and is probably okay. If
> it's not okay, then complain to the package manager that they have
> broken their own package :) (And the package manager happens to be
> reading this thread, so you should be good, here.)
> 
 # In new-style instances, if CATALINA_BASE isn't specified, it
 will # be constructed by joining TOMCATS_BASE and NAME.
>>> 
>>> Those last two variables are package specific.
>> 
>> What is a 'package' in this context? A Tomcat application?
> 
> Mark was referring to the Tomcat "package" as packaged by the package
> manager (e.g. yum).
> 
> In this case, Tomcat itself doesn't do anything with environment
> variables called TOMCAT_HOME or NAME. Tomcat only cares about
> CATALINA_BASE (where instance-specific configuration and webapps are
> kept) and CATALINA_HOME (which is where the base Tomcat files can be
> found).
> 
>>> The Tomcat logs should at least tell you what - if anything -
>>> Tomcat is deploying.
>> 
>> If I can make sense of them...
>> 
>>> There is no one 'right' way to install Tomcat. Pick the one that
>>> works best for you (and be prepared to try an alternative if you
>>> hit problems).
>> 
>> :-) I'd rather compile from scratch, but that's just the way I was 
>> brought up.
> 
> Building Tomcat from source is a waste of your time: the official
> packages (both from ASF and from Red Hat) have all been built for you
> and are environment agnostic. I would never recommend that anyone
> build Tomcat themselves unless they are trying to hack on it for their
> own needs.
> 
> Let's try this:
> 
> 1. Stop Tomcat and remove all log files (or push them somewhere else
> out of the way)
> 2. Launch Tomcat (and please tell us how you do that)
> 3. Make a single request that returns 404 but should not
> 4. Stop Tomcat
> 5. Post the contents of logs/catalina.out to the list
> 
> Please remove any secrets that might be in that file (the only secrets
> that might be in there would be coming from your application).
> 
> I saw your log file snippets, but there might be something you missed
> (since the log was incomplete).
> 
> I've used Apache Cocoon with Tomcat 4.x and later and haven't had any
> problems like you describe. I suspect this is a simple configuration
> problem that we can help you get corrected.
> 
> - -chris

All started contexts are from a default install. ROOT may be also the default 
homepage, so that would explain the 404s.

Maybe the new installation is using a different than expected webapps dir?! Or 
has overwritten your ROOT?

I would try to remove all webapps (besides manager), restart tomcat and see 
what's in the logs. (That's best practise anyways to remove samples and the 
default ROOT).


BTW: from the logs I see a misconfigured server/context.xml as tomcat warns 
that xml attributes are used that have no corresponding setters!?

Best regards

Peter

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

Re: 8.5.11/8.5.14 using SSLHostConfig protocols and ciphers list ignored

[Peter Kreuser]

Todd,




Peter Kreuser


Peter Kreuser
> Am 26.06.2017 um 18:56 schrieb Christopher Schultz 
> <ch...@christopherschultz.net>:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Todd,
> 
>> On 6/23/17 2:56 PM, Todd wrote:
>> Thank you Peter - I tried that previously, and just to double check
>> tried it again.  No difference at all.  a set of ciphers is being
>> presented that do not match to the cipher list that I've included
>> at all.
>> 
>> Any other ideas as to what could be overriding this list?  As
>> mentioned, some things when edited do take effect, like the
>> protocol selection (I can remove TLS, add SSL, etc.), if I have a
>> syntax error, the server won't start and will give an error, but
>> nothing I put in ciphers seems  to work.
> 
> Can you provide a clean configuration that exhibits this behavior?
> 
> What are you using to test the effective configuration?

Another question: are you sure that you hit the Connector that you configure? 
Tomcat should be reasonably configured in defaults with a current JDK...

8443 or the like are not scanned with ssllabs! So it may as well hit an apache 
on the same machine!

Can you show detail on what ssllabs is complaining about?

Best regards

Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllRPNcACgkQHPApP6U8
> pFiKXA/9F+2gPydxc19zOIEKnGbyxz/rSL2vzt7Liaxwt/tXQyGxRwmTAQ91NJIL
> PKCKLWizMr9GfTvEPD2w4fLGw8QTdlcpMIbUmJh9QFjFThPBCl7IXrMeDYU8P38c
> 0d8+KGBB/pwCJYoK7m+c0RHAungMRtvtdOrjSfwyP5T2a6AEcoY0tVg5IyFJOypW
> +diAioM9u5Jtrj/ZYjTXrc6AZ5FvVX2lcD0tQqIuIsDZHz9WJHEs6LhDNdEGykPV
> vN2Y42c9AoGesKRpY7p7ptHnG6igCcbMtfvKls7YYTpP+jc8aIO0tLvnG5IdUmH5
> XiqCbUnMkTk+ygjM4fk1Pel/Z4bHPjT8XZ3ZcuMMKBLfnKkjD2G0DesP9b7e355q
> 0F6wm2vBL8b169RxeS5L4qcW9aLz7PLyo+nWjnhP6+Cgd9DrJzNxQa2M3RYC5L87
> KmJ1ImCf5JisXXWLLcK+hxAitD65ndGVzNcet7khJMsoKsk5O/TocQYdRpBNHi+7
> t/CefXFWskPmYVEG8ffYJQH8ZU+i02pmaXPagQJIorvaMNEBEebPkRfjzoMGOidx
> L+dFde/tRn5gLWlESg7mMfT8y8UsSjw3xUKXmZ8fD/UPUVTOAsu0MpiVBURF4BXG
> cXwdtY6Jk0Ox/UN+VziwSQgVNroEDriaoua1Vq8hYjeZOtkMkIk=
> =WnIS
> -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: Apache httpd server 2.4.25 binaries for Non Windows platforms

[Peter Kreuser]

Olaf,




Peter Kreuser
+49 172 6649346
>> Am 16.06.2017 um 11:14 schrieb Olaf Kock <tom...@olafkock.de>:
>> 
>> Am 16.06.2017 um 08:55 schrieb Prarthana Agwania:
>> We have a requirement to package Apache httpd server together with mod_jk
>> 1.2.42 and distribute it to customers. Our application is hosted on Tomcat
>> which needs to be load balanced. We tried the topology where in Apache
>> httpd server act as the load balancer in conjunction with mod_jk which
>> works perfectly fine. Now, we are required to package this and distribute
>> it but I am unable to find the binaries for the latest version. We cannot
>> compile and build it as it will be distributed to customers and we will
>> have to ensure everything is correctly build and runs on all platforms.
> My expectation is that there's no binary for /all/ platforms - in fact,
> the download page on https://tomcat.apache.org/download-connectors.cgi
> specifically lists binary downloads "for selected versions" and only
> provides Windows. I'm typically using the binary from the Linux
> distribution that I'm using - but that naturally doesn't include the
> other platforms that you name as examples:
>> Therefore, I request you to provide the binaries for different non windows
>> platform say, OEL, Solaris, HP and AIX.
> As the list of possible platforms (and their versions) is open ended (I
> read the "say" in your request as "for example"): Note that you get the
> source code, with all permissions of the Apache License, which is far
> more than you get from any commercial vendor. Asking you to do a little
> bit for yourself (especially when the release team might not even have
> the platforms available, or resources to test on them) is not too much
> IMHO. The simple statement "We cannot compile and build it" offloads
> your responsibility (you have decided for mod_jk on your own) to a
> project that you do not indicate to have any involvement with other than
> using its products for free.
> 
> In order to make that request, I recommend to pay some commercial vendor
> in order to get these services from them (and there are great ones, even
> supporting this project). Alternatively you might negotiate a donation
> (probably quite sizeable) to the Apache foundation or the project
> committers and supporters in order to build the infrastructure to build,
> test and distribute more than the volunteered "selected platforms". I'm
> sure that you can find a commercial vendor, I'm not sure that/if its
> possible to negotiate the donation suggestion - others on this list will
> have more insight on this.
> 
> The quickest result, however, will be: Just compile it. You'll need to
> test it anyways, even when you download binaries - or do you distribute
> your software claiming support for platforms that you've never tested?
> 
> Olaf
Nicely said!

Prarthana,
Be nice and ask politely for help and suggestions. You may get further...

I suggest going back to the drawing board and define a manageable system setup 
(say list of supported systems and pre-packaged httpd,modjk) and rely on the 
distributions like redhat, debian, ubuntu. 
For others I'd provide hints and links to build it themselves.

PLUS: from my security point of view: leave an option to exchange the tomcat 
(minor) version to the user. Or even have their own tomcat installation!
It's a pain to tie a httpd or tomcat update to a complete version update of 
your software! That leads to running old insecure versions of software 
components (httpd, tomcat), as business will not approve a (paid) software 
update!

My 2cts.

Peter

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