Aw: Re: tomcat hangs

2021-09-13 Thread Peter Rader
Chris,

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

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

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

Regards

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



Aw: tomcat hangs

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

Regards


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

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



Re: Apache Tomcat 9 | Tomcat starting issue

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

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

Best regards, Peter

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



Re: Connector Port Issue

2021-08-05 Thread Peter Kreuser
Chris,

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

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

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

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

Peter

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


Re: Understanding issues with connection refused when redirecting internally

2021-04-12 Thread Peter Chamberlain
On Mon, 12 Apr 2021, 09:07 Mark Thomas,  wrote:

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

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

Best regards, Peter.


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


Re: Understanding issues with connection refused when redirecting internally

2021-04-11 Thread Peter Chamberlain
On Fri, 9 Apr 2021 at 18:12, Peter Chamberlain 
wrote:

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

Re: Understanding issues with connection refused when redirecting internally

2021-04-09 Thread Peter Chamberlain
On Fri, 9 Apr 2021, 14:10 Christopher Schultz, 
wrote:

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

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

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

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

Re: Understanding issues with connection refused when redirecting internally

2021-04-09 Thread Peter Chamberlain
On Fri, 9 Apr 2021, 14:29 Mark Thomas,  wrote:

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

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

Thanks alot,

Peter

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

Understanding issues with connection refused when redirecting internally

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

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

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


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

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

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

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



Re: [OT] programming style or mental process ?

2021-04-05 Thread Peter Kreuser
All,

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

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

Peter 


> So it's a defensive programming technique for me.
> 
>> Is it purely a question of individual programming style ?
> 
> Perhaps at this stage in history, it is only "style". But it does have a 
> practical
> 
>> Is there some (temporary ?) fashion aspect involved ?
>> Do the people who write this either way really think in a different way ?
>> Or is there really something "technical" behind this, which makes one or the 
>> other way be slightly more efficient (whether to compile, or optimise, or 
>> run) ?
>> (*) excepting Yoda of course
> 
> -chris
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

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



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

2021-03-08 Thread Peter Rader


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

   
    
  
  
 
Both, HTTP and HTTPS connector have the UTF8 encoding:
 

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

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

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



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

2021-03-02 Thread 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

2021-01-06 Thread Peter Kreuser
James,

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

They should change that for sure!

Peter

> While it's not really my problem (and is only connected to Tomcat by virtue 
> of it happening with a Tomcat server), I'm curious about what's up with it, 
> if anybody here is able and willing to explain it.
> 
> Of course, a customer that's big enough to run a private CA in production is 
> already doing things beyond my pay grade.
> 
> --
> JHHL
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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



Re: Deploying war, Negative Date exception

2020-10-12 Thread Peter Henderson
On Mon, 12 Oct 2020 at 14:50, Mark Thomas  wrote:

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

Thanks for digging into this.

For anyone else who runs into this.

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

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


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

Peter.






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

-- 
Peter Henderson

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


Deploying war, Negative Date exception

2020-10-12 Thread Peter Henderson
Hello fellow tomcat users.

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

Source code [0]

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


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


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

Thanks
Peter.


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

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

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

-- 
Peter Henderson


Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-08-27 Thread Peter Kreuser
Mark,

Sorry for Top-posting.

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

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

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

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

My 2ct.

Peter

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

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-08-25 Thread Peter Kreuser
Pratik,

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


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


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

Peter


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



Re: Request for Help

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

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

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



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



On server start we are getting this exception

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

Any inputs to overcome this could help us in this.

Thanks

Mohan



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

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



Re: Error in stopping application tomcat !!

2020-07-25 Thread Peter Kreuser
Kushagra,


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

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

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

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

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

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

My 2ct.

Peter

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

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

2020-04-09 Thread Peter Kreuser
Mark, James

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

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

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

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


  Require 


Maybe also LocationMatch.

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

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

An apachectl graceful reloads the config without downtime.

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


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

Peter
> 


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



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

2020-04-07 Thread Peter Rader



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

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


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



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

2020-04-06 Thread Peter Kreuser
James,

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

Don‘t be scared!

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


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

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

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

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

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

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

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

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

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

Peter

> --
> James H. H. Lampert
> Touchtone Corporation
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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



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

2020-04-06 Thread Peter Rader
Hello Konstantin Kolinko,

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

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

This is my context.xml









Any idea?



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




Kind regards

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

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



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

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

Ok this will work but I run the app using

  mvn tomcat:run

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

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

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

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

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

>
> Best regards,
> Konstantin Kolinko

Kind regards

Peter Rader

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



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

2020-03-15 Thread Peter Rader
I wrote a little WebFilter for this task.

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

Kind regards

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

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



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

2020-03-15 Thread Peter Rader


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

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

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

The Problem:

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

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

The Question:

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


Kind regards

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

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



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

2020-02-08 Thread Peter Rader


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

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

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

Kind regards

Peter Rader

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



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

2020-02-03 Thread Peter Rader
> Does it ever work?

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

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

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

   
  524288
  524288
  0



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

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

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

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

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

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

Anyway I found it by myself.

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

I see.

> How did you come to your conclusion?

I noticed two hints that guides me to this idea:

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

> 
> - -chris

--
Peter

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



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

2020-02-02 Thread Peter Rader
> Please post updates to the original thread.

This is the original thread.

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

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

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



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

2020-02-02 Thread Peter Rader
The old version of the application had a daemon that have not yet finished his 
execution.

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

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

Thanks.

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



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

2020-02-02 Thread Peter Rader
Thank you for your reply.

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

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

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



mvn redeploy - double redeployment problem (within 0.2 seconds)

2020-02-02 Thread Peter Rader
oke (TomcatManager.java:604)
at org.codehaus.mojo.tomcat.TomcatManager.deployImpl 
(TomcatManager.java:662)
at org.codehaus.mojo.tomcat.TomcatManager.deploy (TomcatManager.java:295)
at org.codehaus.mojo.tomcat.AbstractDeployWarMojo.deployWar 
(AbstractDeployWarMojo.java:85)
at org.codehaus.mojo.tomcat.AbstractDeployMojo.invokeManager 
(AbstractDeployMojo.java:85)
at org.codehaus.mojo.tomcat.AbstractCatalinaMojo.execute 
(AbstractCatalinaMojo.java:141)
at org.codehaus.mojo.tomcat.AbstractWarCatalinaMojo.execute 
(AbstractWarCatalinaMojo.java:70)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)

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

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

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

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

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

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



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

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

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

Any ideas?

Kind regards

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

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



Re: [OT] Install Comodo SSL in Tomcat

2020-01-28 Thread 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

2020-01-28 Thread Peter Kreuser
Chris,



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

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

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

Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wVGYACgkQHPApP6U8
> pFhaXw//dJcRnA6Q8HUWWgubTA6jlPu85e4LoOxk4qExgCD9P5z3YnqS1Y6YqsmP
> yrTykv/A2vA84ZgAetDU1IASQ08MYXsl4poSFMMOdLRPKEd1MlBzWo+yfR0+e79M
> fWaZ6TbSioXTktWyLZspAaAM5ElFsvgRpktY6pY1+R042BoIj/NwQOsN7OiWWPE+
> sJVFRODD9cZ45MvuRdCli07hDqBmFrpOCdYYz2FIp2ANdce2N4W8GF64AgnQ5K6T
> 6ofA5HeLjWLmJgrrPuO09lNF2DROufBICz6sDP81UdrfLYEYQO2csFQx+8VSArFy
> Ph3iEp17HR/hkf3ztRe+5frXQxba9vKHyzVrT3nDjMCvVTUUN41kOd41PkAmyqAx
> Jy6hAwRRiXP5a47g7RXfNF5wDzY7taKVwVblRLa8qrzi3ub3VYmpdIH29g0b3W8F
> YbTMTQLUyzDog4yPyTcGwDqkBw8B9Z9dOg+ak005mrjsGBBx/FDpSvgQo0kOvmrG
> YvrUvShrnBpPM3BC27Y46WnqwrJMGbrk2FeHtlvrlND+QFZ50IiTf/VPBGisN8+h
> pjUcC1UfvTWgH6YpBtdjSJkAjJZAQWchGG1WflR4St1aIyML95yDkZQcbrLHzgN/
> hgzocAzSWakkYppdwzgfuIdwpOsjzh1ld5fuoo0ibwhpBQdmMew=
> =NdCj
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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



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

2020-01-16 Thread Peter Köhler
Hi Palod,

i think you can do it with:

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

Regards

peter



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



Hi All,

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

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

Regards
Manish




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

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

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



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



Hello,

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

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

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

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

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

Below is the beginning of the JSP page:

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



  





 


  ${initParam['S_IF_MSG_TITLE_WELCOME']}



  
--

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

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

Can you help me solve that problem? 

Best regards.
--
Léa

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



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

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



Dear Lea,

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

helps.

Regards

Peter




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

2020-01-15 Thread Peter Köhler
Von:Léa Massiot 
An: users@tomcat.apache.org
Datum:  15.01.2020 15:40
Betreff:Tomcat9, JSP, CSS and JS not loading in Firefox



Hello,

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

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

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

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

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

Below is the beginning of the JSP page:

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



  





 


  ${initParam['S_IF_MSG_TITLE_WELCOME']}



  
--

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

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

Can you help me solve that problem? 

Best regards.
--
Léa

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



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

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



Dear Lea,

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

Regards

Peter


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

2020-01-15 Thread Peter Köhler
Dear Sirs,

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

The  ssl connector inside server.xml is:



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




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


which is defined inside tomcat-users.xml .


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

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

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


The java configuration inside catalina.sh is:

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


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


What  can i do to solve that problem?

Thanks

Peter





Re: TC8 -> TC9 KeyAlias SSL not supported?

2020-01-13 Thread Peter Kreuser
Peter,

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

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



   

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


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



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

2020-01-13 Thread Peter Rader
> Peter,
>
> Can you find what you are looking for here?
>
> 
>  
>
> ?

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

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



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

2020-01-13 Thread Peter Rader
> > I recently moved from T8 to T9 to use PKI.
>
> Exact versions?

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

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

TC8=


TC9=


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

>
> Mark

Peter

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



TC8 -> TC9 KeyAlias SSL not supported?

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

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



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

2020-01-08 Thread Peter Kreuser
Zahid,

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

STFU or leave.

This calls for an ban!

Peter

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

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

2020-01-07 Thread 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

2020-01-07 Thread 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?

2020-01-06 Thread 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?

2020-01-06 Thread 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?

2019-12-30 Thread 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?

2019-12-30 Thread 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?

2019-12-28 Thread 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

2019-12-16 Thread 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

2019-12-10 Thread Peter Kreuser
Chris‘,

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

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

Peter

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

Re: Global Error Handling

2019-12-03 Thread 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

2019-11-12 Thread 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

2019-11-10 Thread 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

2019-10-02 Thread 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

2019-09-09 Thread 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?

2019-08-07 Thread 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-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">

> 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

2019-08-07 Thread 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

2019-08-06 Thread 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

2019-08-01 Thread 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?

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

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

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

Re: Outbound SSL?

2019-05-29 Thread 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

2019-05-10 Thread 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

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

Peter

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

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

connectionInitSqls

2019-04-12 Thread Peter Tom
Hi all,

I have third party application installed on Tomcat 8.5.

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

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

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


 
 
 


But still not working.

Has somebody idea how to solve it?


thank you
Peter


RE: Access to server denied

2019-03-25 Thread Peter Henriques
Hi Luis,

Its alright. I have uninstalled tomcat on zos USS and will attempt to run an 
install using the tomcat JCL instead.

Thanks anyway.

Peter

-Original Message-
From: Luis Rodríguez Fernández [mailto:uo67...@gmail.com] 
Sent: 25 March 2019 12:55
To: Tomcat Users List 
Subject: Re: Access to server denied

Hello Peter,

I am bit confused: you get the forbidden error after a successful login in the 
third party product? Is that third party product installed in a different 
machine? Which product? Is any kind of SSO solution (keycloak, Microsoft ASDF, 
OpenAM...)? May I ask you to describe a bit your scenario, please?

Best regards,

Luis







El lun., 25 mar. 2019 a las 10:18, Peter Henriques (<
peter.henriq...@macro4.com>) escribió:

> Hello,
>
>
>
> I have successfully installed Tomcat 8.5.39 on z/OS 2.3 under USS. I 
> use the native IBM Java utility.  However I have to connect to a third 
> party product which presents a web front end with a username/password panel.
>
> This is the error I get when I connect zos23.intranet.XX.com:
> portnumber/app/#login:
>
>
>
> *HTTP Status 403 – Forbidden*
> --
>
> *Type* Status Report
>
> *Message* /App/
>
> *Description* The server understood the request but refuses to 
> authorize it.
> --
>
> *Apache Tomcat/8.5.39*
>
>
>
> Is this purely a permissions issue with RACF or is there an error with 
> my config with permissible usernames.
>
>
>
> Regards
>
>
>
> *Peter M Henriques*
>
> *Support Engineer – Mainframe Support Group*
>
> *D:* +44-1293-872072 | *T:* +44-1293-872000 | www.macro4.com
>
>
>
> <http://www.macro4.com/>   <https://www.linkedin.com/company/macro-4>
> <https://twitter.com/macro_4> <https://www.facebook.com/Macro4.4/>
> <https://plus.google.com/115044887053369398852>
>
>
>
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS
>
> Registered in England no: 00927588
>
>
>
> Please consider the environment and only print this email if you 
> really need to.
>
>
>
> This e-mail message has been scanned and cleared by Google Message 
> Security and the UNICOM Global security systems. This message is for 
> the named person's use only. If you receive this message in error, 
> please delete it and notify the sender.
>


-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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



Access to server denied

2019-03-25 Thread Peter Henriques
Hello,

I have successfully installed Tomcat 8.5.39 on z/OS 2.3 under USS. I use the 
native IBM Java utility.  However I have to connect to a third party product 
which presents a web front end with a username/password panel.
This is the error I get when I connect 
zos23.intranet.XX.com:portnumber/app/#login:

HTTP Status 403 - Forbidden

Type Status Report
Message /App/
Description The server understood the request but refuses to authorize it.

Apache Tomcat/8.5.39

Is this purely a permissions issue with RACF or is there an error with my 
config with permissible usernames.

Regards

Peter M Henriques
Support Engineer - Mainframe Support Group
D: +44-1293-872072 | T: +44-1293-872000 | www.macro4.com<http://www.macro4.com/>

[cid:image001.png@01D4E2EB.B0AA26C0]<http://www.macro4.com/>   
[cid:image002.png@01D4E2EB.B0AA26C0] <https://www.linkedin.com/company/macro-4> 
 [cid:image003.png@01D4E2EB.B0AA26C0] <https://twitter.com/macro_4>  
[cid:image004.png@01D4E2EB.B0AA26C0] <https://www.facebook.com/Macro4.4/>  
[cid:image005.png@01D4E2EB.B0AA26C0] 
<https://plus.google.com/115044887053369398852>

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.


-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 


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

2019-03-19 Thread 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

2019-03-19 Thread 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: Issue with TomCat 8.5 under z/OS2.3 and USS

2019-03-12 Thread Peter Henriques
Hi Mark,

I have resolved this issue. I apparently chose the wrong java location and 
config. There is a pre installed IBM JDK pack. I used this one rather then the 
one I installed(OpenJDK) and  can start up Tomcat now.

Thanks

Peter

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 12 March 2019 11:41
To: users@tomcat.apache.org
Subject: Re: Issue with TomCat 8.5 under z/OS2.3 and USS

On 12/03/2019 11:32, Peter Henriques wrote:
> Hello,
> 
>  
> 
> My Environment:
> 
> z/OS 2.3
> 
> USS
> 
> TomCat 8.5

Please provide a more precise Tomcat version.

Mark


> 
> OpenJDK 8
> 
>  
> 
> I am getting errors submitting JCL PROC for running Apache Tomcat 
> using the JZOS batch Java launcher. It is a PROC that is executed 
> under another job called TCJOB.
> 
>  
> 
> The error I am getting is shown from the resulting joblog:
> 
>  
> 
> -STEPNAME PROCSTEP    RC   EXCP   CONN   TCB   SRB
> 
> -TOMCAT   JAVAJVM    101   2940 49   .00   .00
> 
> IEF404I TOMCAT - ENDED - TIME=10.00.10
> 
> -TOMCAT   ENDED.  NAME-HLQ   TOTAL TCB CPU TI
> 
> $HASP395 TOMCAT   ENDED - RC=0101
> 
>  
> 
> When I check the reason for the abend I see this:
> 
>  
> 
> Output from DD:STDENV config shell script:
> 
>  waiting for child shell process to complete
> 
>  -> waitChild()
> 
>  child shell process exited with exit code 0
> 
>  <- waitChild()
> 
>  Child shell process exited without printing environment; //STDENV 
> should not contain 'exit'
> 
>  <- adoptEnvironment()
> 
>  <- run()
> 
>  -> cleanup()
> 
>  JZOS batch launcher elapsed time=1 seconds, cpu time=0.09 seco
> 
> JZOS batch launcher failed, return code=101
> 
>  <- cleanup()
> 
>  -> ~JzosVM()
> 
>  <- ~JzosVM()
> 
>  
> 
> I don't know if it is an authority issue or JAVA issue. I have 
> searched for this error all over and get various reasons for this 
> error. The closest or more relevant issue I have  seen is :
> 
>  
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PM54627
> 
>  
> 
> I have even attempted to use su under USS shell but it just ignores 
> this authority.
> 
>  
> 
> Is there a way I can modify the supplied JCL(TCJOB, TCENV) to  add 
> superuser privileges?
> 
>  
> 
> Regards
> 
>  
> 
> *Peter M Henriques*
> 
> *Support Engineer - Mainframe Support Group*
> 
> *D:*+44-1293-872072 | *T:* +44-1293-872000 | www.macro4.com 
> <http://www.macro4.com/>
> 
>  
> 
> <http://www.macro4.com/>
> <https://www.linkedin.com/company/macro-4> 
> <https://twitter.com/macro_4><https://www.facebook.com/Macro4.4/> 
> <https://plus.google.com/115044887053369398852>
> 
>  
> 
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS
> 
> Registered in England no: 00927588
> 
>  
> 
> Please consider the environment and only print this email if you 
> really need to.
> 
>  
> 
> 
> This e-mail message has been scanned and cleared by Google Message 
> Security and the UNICOM Global security systems. This message is for 
> the named person's use only. If you receive this message in error, 
> please delete it and notify the sender.


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


-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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



RE: Issue with TomCat 8.5 under z/OS2.3 and USS

2019-03-12 Thread Peter Henriques
HI,

I also saw this issue that could be related:


https://serverfault.com/questions/824107/authorization-required-to-install-jzos-batch-launcher/824367

Regards

Peter

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 12 March 2019 11:41
To: users@tomcat.apache.org
Subject: Re: Issue with TomCat 8.5 under z/OS2.3 and USS

On 12/03/2019 11:32, Peter Henriques wrote:
> Hello,
> 
>  
> 
> My Environment:
> 
> z/OS 2.3
> 
> USS
> 
> TomCat 8.5

Please provide a more precise Tomcat version.

Mark


> 
> OpenJDK 8
> 
>  
> 
> I am getting errors submitting JCL PROC for running Apache Tomcat 
> using the JZOS batch Java launcher. It is a PROC that is executed 
> under another job called TCJOB.
> 
>  
> 
> The error I am getting is shown from the resulting joblog:
> 
>  
> 
> -STEPNAME PROCSTEP    RC   EXCP   CONN   TCB   SRB
> 
> -TOMCAT   JAVAJVM    101   2940 49   .00   .00
> 
> IEF404I TOMCAT - ENDED - TIME=10.00.10
> 
> -TOMCAT   ENDED.  NAME-HLQ   TOTAL TCB CPU TI
> 
> $HASP395 TOMCAT   ENDED - RC=0101
> 
>  
> 
> When I check the reason for the abend I see this:
> 
>  
> 
> Output from DD:STDENV config shell script:
> 
>  waiting for child shell process to complete
> 
>  -> waitChild()
> 
>  child shell process exited with exit code 0
> 
>  <- waitChild()
> 
>  Child shell process exited without printing environment; //STDENV 
> should not contain 'exit'
> 
>  <- adoptEnvironment()
> 
>  <- run()
> 
>  -> cleanup()
> 
>  JZOS batch launcher elapsed time=1 seconds, cpu time=0.09 seco
> 
> JZOS batch launcher failed, return code=101
> 
>  <- cleanup()
> 
>  -> ~JzosVM()
> 
>  <- ~JzosVM()
> 
>  
> 
> I don't know if it is an authority issue or JAVA issue. I have 
> searched for this error all over and get various reasons for this 
> error. The closest or more relevant issue I have  seen is :
> 
>  
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PM54627
> 
>  
> 
> I have even attempted to use su under USS shell but it just ignores 
> this authority.
> 
>  
> 
> Is there a way I can modify the supplied JCL(TCJOB, TCENV) to  add 
> superuser privileges?
> 
>  
> 
> Regards
> 
>  
> 
> *Peter M Henriques*
> 
> *Support Engineer - Mainframe Support Group*
> 
> *D:*+44-1293-872072 | *T:* +44-1293-872000 | www.macro4.com 
> <http://www.macro4.com/>
> 
>  
> 
> <http://www.macro4.com/>
> <https://www.linkedin.com/company/macro-4> 
> <https://twitter.com/macro_4><https://www.facebook.com/Macro4.4/> 
> <https://plus.google.com/115044887053369398852>
> 
>  
> 
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS
> 
> Registered in England no: 00927588
> 
>  
> 
> Please consider the environment and only print this email if you 
> really need to.
> 
>  
> 
> 
> This e-mail message has been scanned and cleared by Google Message 
> Security and the UNICOM Global security systems. This message is for 
> the named person's use only. If you receive this message in error, 
> please delete it and notify the sender.


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


-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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



RE: Issue with TomCat 8.5 under z/OS2.3 and USS

2019-03-12 Thread Peter Henriques
Hi,

Apologies...8.5.38

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 12 March 2019 11:41
To: users@tomcat.apache.org
Subject: Re: Issue with TomCat 8.5 under z/OS2.3 and USS

On 12/03/2019 11:32, Peter Henriques wrote:
> Hello,
> 
>  
> 
> My Environment:
> 
> z/OS 2.3
> 
> USS
> 
> TomCat 8.5

Please provide a more precise Tomcat version.

Mark


> 
> OpenJDK 8
> 
>  
> 
> I am getting errors submitting JCL PROC for running Apache Tomcat 
> using the JZOS batch Java launcher. It is a PROC that is executed 
> under another job called TCJOB.
> 
>  
> 
> The error I am getting is shown from the resulting joblog:
> 
>  
> 
> -STEPNAME PROCSTEP    RC   EXCP   CONN   TCB   SRB
> 
> -TOMCAT   JAVAJVM    101   2940 49   .00   .00
> 
> IEF404I TOMCAT - ENDED - TIME=10.00.10
> 
> -TOMCAT   ENDED.  NAME-HLQ   TOTAL TCB CPU TI
> 
> $HASP395 TOMCAT   ENDED - RC=0101
> 
>  
> 
> When I check the reason for the abend I see this:
> 
>  
> 
> Output from DD:STDENV config shell script:
> 
>  waiting for child shell process to complete
> 
>  -> waitChild()
> 
>  child shell process exited with exit code 0
> 
>  <- waitChild()
> 
>  Child shell process exited without printing environment; //STDENV 
> should not contain 'exit'
> 
>  <- adoptEnvironment()
> 
>  <- run()
> 
>  -> cleanup()
> 
>  JZOS batch launcher elapsed time=1 seconds, cpu time=0.09 seco
> 
> JZOS batch launcher failed, return code=101
> 
>  <- cleanup()
> 
>  -> ~JzosVM()
> 
>  <- ~JzosVM()
> 
>  
> 
> I don't know if it is an authority issue or JAVA issue. I have 
> searched for this error all over and get various reasons for this 
> error. The closest or more relevant issue I have  seen is :
> 
>  
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PM54627
> 
>  
> 
> I have even attempted to use su under USS shell but it just ignores 
> this authority.
> 
>  
> 
> Is there a way I can modify the supplied JCL(TCJOB, TCENV) to  add 
> superuser privileges?
> 
>  
> 
> Regards
> 
>  
> 
> *Peter M Henriques*
> 
> *Support Engineer - Mainframe Support Group*
> 
> *D:*+44-1293-872072 | *T:* +44-1293-872000 | www.macro4.com 
> <http://www.macro4.com/>
> 
>  
> 
> <http://www.macro4.com/>
> <https://www.linkedin.com/company/macro-4> 
> <https://twitter.com/macro_4><https://www.facebook.com/Macro4.4/> 
> <https://plus.google.com/115044887053369398852>
> 
>  
> 
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS
> 
> Registered in England no: 00927588
> 
>  
> 
> Please consider the environment and only print this email if you 
> really need to.
> 
>  
> 
> 
> This e-mail message has been scanned and cleared by Google Message 
> Security and the UNICOM Global security systems. This message is for 
> the named person's use only. If you receive this message in error, 
> please delete it and notify the sender.


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


-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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



Issue with TomCat 8.5 under z/OS2.3 and USS

2019-03-12 Thread Peter Henriques
Hello,

My Environment:
z/OS 2.3
USS
TomCat 8.5
OpenJDK 8

I am getting errors submitting JCL PROC for running Apache Tomcat using the 
JZOS batch Java launcher. It is a PROC that is executed under another job 
called TCJOB.

The error I am getting is shown from the resulting joblog:

-STEPNAME PROCSTEPRC   EXCP   CONN   TCB   SRB
-TOMCAT   JAVAJVM101   2940 49   .00   .00
IEF404I TOMCAT - ENDED - TIME=10.00.10
-TOMCAT   ENDED.  NAME-HLQ   TOTAL TCB CPU TI
$HASP395 TOMCAT   ENDED - RC=0101

When I check the reason for the abend I see this:

Output from DD:STDENV config shell script:
 waiting for child shell process to complete
 -> waitChild()
 child shell process exited with exit code 0
 <- waitChild()
 Child shell process exited without printing environment; //STDENV should not 
contain 'exit'
 <- adoptEnvironment()
 <- run()
 -> cleanup()
 JZOS batch launcher elapsed time=1 seconds, cpu time=0.09 seco
JZOS batch launcher failed, return code=101
 <- cleanup()
 -> ~JzosVM()
 <- ~JzosVM()

I don't know if it is an authority issue or JAVA issue. I have searched for 
this error all over and get various reasons for this error. The closest or more 
relevant issue I have  seen is :

http://www-01.ibm.com/support/docview.wss?uid=swg1PM54627

I have even attempted to use su under USS shell but it just ignores this 
authority.

Is there a way I can modify the supplied JCL(TCJOB, TCENV) to  add superuser 
privileges?

Regards

Peter M Henriques
Support Engineer - Mainframe Support Group
D: +44-1293-872072 | T: +44-1293-872000 | www.macro4.com<http://www.macro4.com/>

[cid:image001.png@01D4D8C6.1B18EE90]<http://www.macro4.com/>   
[cid:image002.png@01D4D8C6.1B18EE90] <https://www.linkedin.com/company/macro-4> 
 [cid:image003.png@01D4D8C6.1B18EE90] <https://twitter.com/macro_4>  
[cid:image004.png@01D4D8C6.1B18EE90] <https://www.facebook.com/Macro4.4/>  
[cid:image005.png@01D4D8C6.1B18EE90] 
<https://plus.google.com/115044887053369398852>

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.


-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 


Re: Http insecure headers

2019-03-05 Thread 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

2019-02-19 Thread 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

2019-02-13 Thread 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 mak

Re: [EXTERNAL] Re: tomcat Finding!

2018-12-19 Thread 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



unsuscribe

2018-07-05 Thread Peter
unsubscribe

Re: Connection closed error and certificateVerification="required"

2018-04-19 Thread Peter@Kreuser-Online
Mark,

>> Am 18.04.2018 um 11:55 schrieb Mark Thomas <ma...@apache.org>:
>> 
>> On 18/04/18 10:36, Richard Tearle wrote:
>> On 17 April 2018 at 16:45, Richard Tearle
>> <richard.tea...@northgateps.com> wrote:
>>> On 17 April 2018 at 14:54, Mark Thomas <ma...@apache.org> 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

2018-02-23 Thread Peter@Kreuser-Online
Hi Chris,



> Am 23.02.2018 um 18:36 schrieb Cheltenham, Chris 
> <ccheltenham-...@philasd.org>:
> 
> 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?

2018-02-08 Thread 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

2018-01-23 Thread 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

2018-01-23 Thread Peter Kreuser
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
> 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
>>>> 
>>>> 
>>>> -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.Dat

Re: Activating Tomcat 8.5 APR on RHEL7

2018-01-15 Thread Peter Kreuser


Hi Jean-Pierre,

> Am 15.01.2018 um 15:45 schrieb Jean Pierre Urkens 
> <jean-pierre.urk...@devoteam.com>:
> 
> 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

2017-12-22 Thread Peter Kreuser


Thomas,

> Am 22.12.2017 um 15:38 schrieb Thomas Delaney <tdelaney@gmail.com>:
> 
> 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 <tdelaney@gmail.com>
> 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. <geor...@mhsoftware.com> 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
>>>>>>> <tdelaney@gmail.com>:
>>>>>>> 
>>>>>>> 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 sw

Aw: Trouble with TLS/SSL and Tomcat 8.5.23

2017-11-22 Thread Peter Kreuser




Richard,





> Gesendet: Mittwoch, 22. November 2017 um 14:40 Uhr
> Von: "Richard Tearle" 
> <richard.tea...@northgateps.com[mailto:richard.tea...@northgateps.com]>
> 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_SHA

Re: URL-encoding and "#"

2017-10-13 Thread 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.

2017-10-10 Thread 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

2017-10-10 Thread Peter Kreuser
Harish,


> Am 10.10.2017 um 00:00 schrieb Harish Krishnan <harish@gmail.com>:
> 
> 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
>> --

Re: encodeURL, jsessionid and mod_rewrite ?

2017-10-03 Thread 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

2017-09-27 Thread Peter Kreuser
John,


> Am 27.09.2017 um 18:08 schrieb John Ellis <john.el...@lsgsolutions.com>:
> 
> 
> 
> 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 <users@tomcat.apache.org>
> Subject: Re: tomcat ssl setup
> 
> John,
> 
> 
> 
>> Am 26.09.2017 um 21:26 schrieb John Ellis <john.el...@lsgsolutions.com>:
>> 
>> 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
>  
> <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

2017-09-21 Thread 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

2017-08-19 Thread 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) <a...@ice-sa.com>:
> 
> 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)

2017-08-16 Thread 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 <jam...@touchtonecorp.com>:
> 
>> 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

2017-08-15 Thread 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



[2xOT] Re: More (Solved!) Re: I've just installed Tomcat (7.0.67) on an old CentOS 5 box. It can't be reached from outside the box.

2017-08-11 Thread Kreuser, Peter
I'm glad that we get so well over serious problems. Made my day :-) !

PS: André: Sorry for the top post.
PPS: James: I still can't get over it, that you run Tomcat on AS400, my first 
contact to production systems back in '90.

-Ursprüngliche Nachricht-
Von: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Gesendet: Freitag, 11. August 2017 10:45
An: users@tomcat.apache.org
Betreff: [OT] Re: More (Solved!) Re: I've just installed Tomcat (7.0.67) on an 
old CentOS 5 box. It can't be reached from outside the box.

On 11.08.2017 00:27, James H. H. Lampert wrote:
> After looking up the man page (and while I *know* where the term comes 
> from, I *still* think there ought to be "woman," "boy," and "girl" 
> pages [and maybe "cat" and "dog" pages] as well!)

Note that there may be no "woman" command, but that one can do "man | more".
Similarly, there is no "boy" command, but one can do "man | less".
There is no "girl" command, but the Linux developers have tried to ease the 
pain of that by providing "talk", "chat" and "nice" (and even "tee", for the 
mature generation).
As for the animal world, there is indeed a "cat" command. And there may not be 
any "dog" 
command, but there are  "tail" and "head", which might be seen as more generic.


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



AW: I've just installed Tomcat (7.0.67) on an old CentOS 5 box. It can't be reached from outside the box.

2017-08-10 Thread Kreuser, Peter
Hi all,

>-Ursprüngliche Nachricht-
>Von: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
>Gesendet: Donnerstag, 10. August 2017 11:34
>An: users@tomcat.apache.org
>Betreff: Re: I've just installed Tomcat (7.0.67) on an old CentOS 5 box. It 
>can't be reached from outside the box.

>Addendum :
>James,
>this may also be of interest to you :
>https://backdrift.org/tcp-ping-ping-tcp-port

well then you could also go with nmap or netcat (nc).

I would check the host firewall and iptables -L . That may be misconfigured.

Maybe that is also the reason why you can't reach the repos anymore.

Best regards

Peter


>On 10.08.2017 08:46, André Warnier (tomcat) wrote:
> On 10.08.2017 02:32, James H. H. Lampert wrote:
>> This is weird. I've never seen this before.
>>
>> Then again, I don't think I've installed Tomcat on Linux from a 
>> tarball before: the previous CentOS installation was, if I remember 
>> right, via Yum, and the one Debian installation I've done was via apt-get.
>>
>> But I can apparently no longer reach the Yum repository from our 
>> CentOS 5 boxes, so I went with the tarball.
>>
>> It launches. The port opens. It shows up in a netstat. And I can 
>> reach it at either
>> 127.0.0.1:8080 or port 8080 at the box's own IP address.
>>
>>  From the box it's running on.
>>
>> But if I try to reach it from other boxes on the same LAN, I get 
>> "Firefox can't establish a connection" whether I use the box's name 
>> (from boxes that have it in their host table), or its IP address.
>>
>> I can ping the box. And I can reach Samba shares on it. And I can ssh to it.
>
> Ping works at the IP low level, so it means that there is an IP path 
> to the server, but it does not say anything about TCP/UDP "open ports".
> Samba and SSH working, means that TCP/UDP packets addressed to their 
> respective server ports get through.
> Firefox not working must mean that something is blocking port 8080.
>
> Try "telnet ip_of_the_server 8080". It will either also tell you 
> (after a while) "port not reachable", or show a blank screen. If the 
> former, there /is/ something blocking access to port 8080 on the 
> server. If the latter, then ip/port ip_of_the_server:8080 is accessible, and 
> your problem is somewhere else.
>
> Note: for "telnet", you will need a telnet client installed; this is 
> not necessarily standard on non-Windows workstations.
> And the reason for telnet is that it is about the simplest client that 
> can be used, that shows when something comes back, but does not 
> automatically follow "redirects" and that kind of stuff.
>
>
>>
>> The only firewall on the Lan is a TP-Link N750, and if it has any 
>> settings in place to block traffic within the LAN, I can't find them.
>>
>> I've got three different Tomcat 7 servers all running on the LAN, and 
>> can reach them easily.
>>
>> --
>> 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
>


-
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)

2017-08-01 Thread Peter Kreuser
 Bernd,



> Am 01.08.2017 um 11:01 schrieb Bernd Wahlen <abernd.wah...@k2interactive.de>:
> 
> 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)

2017-07-31 Thread Peter Kreuser
Hi Bernd,
 

> Am 31.07.2017 um 19:17 schrieb Bernd Wahlen <bernd.wah...@k2interactive.de>:
> 
> 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 <bernd.wah...@k2interactive.de>
>> 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



  1   2   3   4   5   6   7   8   9   10   >