Re: "You don't have permission to access this resource." message on manager

2022-11-15 Thread James H. H. Lampert

On 11/15/22 9:50 AM, Mark Thomas wrote:
. . .

Is this from Tomcat, or is it from something else?


Lots of guess work here.

I think, something else.

. . .

It *is* from something else. I'd completely forgotten that on that 
particular box, Tomcat was behind Apache HTTPD, and the relevant .conf 
file has


  
   Require ip 1.2.3.4 5.6.7.8 9.10.11.12
  

(IP addresses change to protect the innocent). The office fixed IP 
address is one of the allowed addresses. And my boss's IP address is 
apparently no longer one of them.)


And thanks for the sample allow clause; it will be helpful elsewhere.

--
JHHL

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



"You don't have permission to access this resource." message on manager

2022-11-15 Thread James H. H. Lampert

We have Tomcat running on an AWS EC2 linux box.

I can get into manager from the office IP address, with the usual prompt 
for user and password, but the boss, working from home, gets "You don't 
have permission to access this resource."


Is this from Tomcat, or is it from something else?

Looking at the context.xml for manager, I see:



From what little I know about this, my own ability to get in is more 
puzzling than my boss's inability to do so. Any insights on that?


I never did learn how to write a RemoteAddrValve allow clause (so we've 
just been disabling it); assuming we want to accept connections from 
"1.2.3.4" and "5.6.7.8", could somebody show me what the allow clause 
would look like?


--
JHHL

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



Strange timeout: is it Tomcat, or is it some intermediate stage?

2022-10-10 Thread James H. H. Lampert
Lately, we've been getting this response to a web service call. The web 
service is our own, running under Tomcat on an Amazon "beanstalk"; the 
client is also our own, running on a customer's IBM Midrange box.


  
  504 Gateway Time-out
  
  504 Gateway Time-out
  nginx/1.20.0
  
  

It's a long-running web service call, taking a little over a minute, and 
we didn't see any response at all until I extended the client-side timeout.


Is this coming from Tomcat? Or is it coming from some intermediate 
stage, maybe the load-balancer on the beanstalk, or something in the 
customer's netork?


Any insights would be appreciated.

--
JHHL

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



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

2022-08-10 Thread James H. H. Lampert

On 8/10/22 6:50 AM, Brian Wolfe wrote:

You can disable the protocols at the java level in the java.security file

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, TLSv1,
TLSv1.1


I think that's exactly what I did on "Customer Box #1" (and forgot to 
document having done). Because I dug up the java.security file (I'm 
really glad there's a "find" command available from QShell and other 
*nix-style command lines in OS/400), and it has TLSv1 and TLSv1.1 added 
to it.


--
JHHL

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



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

2022-08-10 Thread James H. H. Lampert

On 8/10/22 8:52 AM, Jason Hall wrote:

If you have another network device in front of your server - that could be what 
is trumping the app server's settings.


I'd planned on investigating that as well.

But it *looks* like the cert I'm seeing matches the cert in the keystore 
their Tomcat is using, and I *don't* think an intermediate device would 
also have that cert.


--
JHHL

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



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

2022-08-10 Thread James H. H. Lampert

Interesting. The new "protocols" parameter.

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


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


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

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


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


--
JHHL

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



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

2022-08-09 Thread James H. H. Lampert
I think this may have come up before, but I don't recall how it was 
resolved.


On customer box #1, I have:
address=""
   maxThreads="400" SSLEnabled="true" scheme="https" 
secure="true"
   keystoreFile="/tomcat/wttomcat.ks" 
keyAlias=""


ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
   clientAuth="false" sslProtocol="TLSv1.2" /> 



and an SSLLabs scan shows it accepting only TLSv1.2, as it should.

But on customer box #2, I have:

   keystoreFile="/tomcat/wttomcat.ks" 
keyAlias=""

   clientAuth="false" sslProtocol="TLSv1.2" />

and an SSLLabs scan shows it accepting TLSv1.0, TLSv1.1, and TLSv1.2.

What could be wrong here? I vaguely recall seeing something like this 
before.


--
JHHL

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



TCP timestamp vulnerability -- any insights on how this relates to Tomcat?

2022-08-05 Thread James H. H. Lampert
Today is the first time I heard of such a thing as a "TCP timestamp 
vulnerability." It seems a bit overblown to me, especially for a Tomcat 
server running on an AS/400.


Can anybody share any insights about how this vulnerability relates to 
Tomcat?


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



Re: Help with deploying multiple .WAR files in Tomcat

2022-08-04 Thread James H. H. Lampert
Multiple WAR files work fine for us. But we don't simply "drop [the WAR 
files] in the webapps folder (and for the most part, that *doesn't* work 
for us, even with *only one* webapp).


We always deploy through the Manager webapp (which we always customize 
to increase the allowable WAR file size by an order of magnitude, every 
time we update somebody's Tomcat), and there are plenty of installations 
where we have multiple nearly-identical contexts based on completely 
identical WAR files (and note that another customization we make when 
installing Tomcat is to disable re-expansion of WAR files when Tomcat 
launches, since that would overwrite parameters manually inserted into 
the contexts after deployment).


--
JHHL

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



Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."

2022-04-15 Thread James H. H. Lampert
In response to my question about what could cause a system to disregard 
its own host table,


On 4/15/22 11:31 AM, Jack Woehr (of the Midrange List) wrote:

Which order the search happens, DNS or hosts table first, is an option in
IBM i TCP configuration. CFGTCP option 12.


Fascinating. I can't begin to imagine how setting it to "*REMOTE" could 
possibly be useful (or that the OS would *allow* LOCALHOST or LOOPBACK 
to be overridden), but I see that at least one other customer box has 
this setting.


I will note that this, by itself, wasn't enough to kill Tomcat. It was a 
combination of this, and a DNS (presumably a "house DNS" rather than a 
public one) that recognized LOCALHOST and LOOPBACK, and responded with 
"LOCALHOST." or "LOOPBACK.," and an 
address that was something other than 127.0.0.1, that did it.


--
JHHL

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



Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."

2022-04-15 Thread James H. H. Lampert

On 4/15/22 10:37 AM, Christopher Schultz (of the Tomcat Users' List) wrote:
. . .
Try specifying the "address" attribute of  along with the port. 
Give it a concrete IP address instead of "localhost" and see if that 
improves things.

. . .

My Dear Mr. Schultz:

That did it!

Not knowing whether to give it 127.0.0.1 or give it the box's actual IP 
address, I gave it the former.


It works. And the connector is configured to listen on anything, so it 
came up just fine, and is entirely visible from the outside world.


But that still leaves open the question of why an IBM Midrange box would 
suddenly start disregarding its own host table. I've never heard of a 
scenario in which *any* box with a TCP stack would disregard its own 
host table (and indeed, on any box under my control that can browse the 
Web, in which the host table is user-modifiable, I use host table 
entries to ensure that I can't be tricked [it's happened, more than 
once] into accessing Facebook, Twitter, LinkedIn, or a few other noisome 
domains).


What can make a box disregard its own host table?

--
JHHL

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



Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."

2022-04-15 Thread James H. H. Lampert

On 4/15/22 10:37 AM, Christopher Schultz (on the Tomcat Users' List) wrote:
. . .
if "localhost" doesn't resolve to 127.0.0.1 on your system, you 
may get this error. Can you quickly check it's not a DNS resolution 
failure?


THIS is interesting.

If I look at the host table entries, I see
   ::1 IPV6-LOOPBACK
   IPV6-LOCALHOST
   127.0.0.1   LOOPBACK
   LOCALHOST

Now if I ping '127.0.0.1' on this box, I get a normal response.

If I ping localhost on our box, or another customer box, I get

Verifying connection to host system LOOPBACK at address 127.0.0.1.


followed by a normal response.

But if I ping localhost or loopback on this box, I get

Verifying connection to host system LOOPBACK. at address .

or

Verifying connection to host system LOCALHOST. at address .


Somehow, this box is DISREGARDING ITS OWN HOST TABLE!

--
JHHL

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



Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."

2022-04-15 Thread James H. H. Lampert

On 4/15/22 9:54 AM, Jim Oberholtzer wrote:

On a modern system if you're contemplating stopping/starting TCP you might
just as well IPL.  Seems like using a nuke when a 100# bomb might work
though.


Looking at the QSYSOPR messages, I see that the system was taken down to 
restricted condition at 01:04 this morning, system time, for a backup, 
which completed at 02:03, with the subsystems, and TCP, starting.


Looking at catalina.out for *YESTERDAY* shows Tomcat being shut down at 
01:04 yesterday morning, and coming back up at 02:04 that morning, 
without incident.


Today, however, catalina.out shows the same thing up to the point where 
8005 shows up as unavailable.


Looking back at the QSYSOPR messages, I see TWO OVERLAPPING STRTCPs, 
initiated within seconds of each other. That doesn't make any sense to 
me. And yet I see it happening every day this week.


So far, nothing is making any sense. TCP can't be in *that bad* of a 
shape, since I'm able to get terminal sessions via TN5250. And WRKTCPSTS 
shows 59 servers waiting for connections, and 61 established connections.


--
JHHL

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



Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."

2022-04-15 Thread James H. H. Lampert

On 4/15/22 9:39 AM, Jack Woehr wrote:

Not sure about the particular pathology in this instance, but it's the Java
runtime itself telling you something already has hold of the socket, and
it's not lying.


But it could be deluded into *thinking* something already has hold of 
the socket.


WRKTCPSTS shows *nothing* on 8005, 8009, 443, or 8443. I've tried 
changing 8005 to 8009. No joy. I then tried changing 443 to 8443. No joy.


I'm seriously considering having them do an ENDTCP followed by a STRTCP 
(although I haven't a clue how that can even be done on a box that 
presumably isn't old enough to have Twinax). And if that doesn't work, 
re-IPL the system.


--
JHHL

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



Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."

2022-04-15 Thread James H. H. Lampert

On 4/15/22 9:24 AM, James H. H. Lampert wrote:
This morning, I arrived at work to find that a customer was complaining 
about their Tomcat server (running on an IBM Midrange box).


It had locked up last night, while being shut down, and now, if you try 
to start it, it fails . . . 


I tried changing the port number from 8005 to 8009 (not in use for its 
usual purpose), since it appears to be specifically failing when trying 
to open 8005.


And it behaves exactly the same: it throws the same error, only this 
time on 8009.


This makes no sense.

--
JHHL

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



Tomcat 8.5.73 not coming up on customer box. "Bind failed."

2022-04-15 Thread James H. H. Lampert
This morning, I arrived at work to find that a customer was complaining 
about their Tomcat server (running on an IBM Midrange box).


It had locked up last night, while being shut down, and now, if you try 
to start it, it fails with

15-Apr-2022 10:35:34.867 SEVERE [main] 
org.apache.catalina.core.StandardServer.await StandardServer.await: 
create[localhost:8005]:
  java.net.BindException: The socket name is not available on this system. (Bind failed)   
  at java.net.PlainSocketImpl.socketBind(Native Method)   
  at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:417)  
  at java.net.ServerSocket.bind(ServerSocket.java:444)
  at java.net.ServerSocket.(ServerSocket.java:258)  
  at org.apache.catalina.core.StandardServer.await(StandardServer.java:414)   
  at org.apache.catalina.startup.Catalina.await(Catalina.java:776)
  at org.apache.catalina.startup.Catalina.start(Catalina.java:722)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)


Catalina.out shows "Starting ProtocolHandler ["https-jsse-nio-443"]," 
then "Server startup in 20227 ms," then it blows up as above.


According to the server.xml, the only ports it is listening on are 8005 
and 443. And according to a WRKTCPSTS *CNN (the AS/400 equivalent of a 
"super netstat"), there is nothing currently grabbing hold of either of 
those two ports.


Any insights as to what could be happening?

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



Stuff in the "temp" directory within the Tomcat directory

2022-02-10 Thread James H. H. Lampert
I'm doing some cleanup on a customer box, removing a previous version of 
Tomcat 8.5 that I'd replaced some time ago, and I'm finding huge amounts 
of "stuff" in the "temp" directory within the Tomcat directory. Is that 
stuff Tomcat itself left behind, or stuff our webapp left behind, or both?


Assuming any of it is from Tomcat itself, any advice on keeping the 
contents of that directory down to something reasonable?


--
JHHL

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



Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread James H. H. Lampert

Thanks. I think I understand now.

All except for one thing:

I can *barely* wrap my mind around the idea of getting executable code 
from an RMI server, but what legitimate purpose could be served by 
allowing a *logger* to resolve executable code?


--
JHHL
(And I have a fair amount of experience writing "solutions looking for a 
problem" that "seemed like a good idea at the time," but turned out to 
have no practical use. More experience than I'd like to have, in fact.)


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



Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread James H. H. Lampert

On 12/13/21 10:53 AM, Mark Thomas wrote:

Log4j2 supports a log message format syntax that includes JNDI lookups.

Log4j2 processes log messages repeatedly until it doesn't find any more 
format strings. This means the output of one format string can insert a 
new format string.

. . .

Thanks. It's starting to make sense to me now, even given that much of 
it involves Java functionality I'd never heard of.


After re-reading the Veracode article in light of what you said, I then 
found a couple of Wikipedia articles that further clarify things, for me 
at least:


https://en.wikipedia.org/wiki/Log4j
https://en.wikipedia.org/wiki/Log4Shell

So it's the ability to resolve stuff of the general format 
"${prefix:name}" within a log string, that's the problem.


It's starting to reach a point where I can wrap my 59-year-old little 
grey cells around it.


--
JHHL

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



Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread James H. H. Lampert
The thing I'm still utterly unclear about is how simply logging traffic 
could, by itself, create a vulnerability.


In our case, the log entries are not even viewable unless you are signed 
on to a command line session on the server (ssh for headless Linux; a 
physical Twinax terminal, or a 5250 emulator of some sort, for IBM 
Midrange).


How can a log entry be executed as a command, anyway?

--
JHHL

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



CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-10 Thread James H. H. Lampert

A customer brought this to my attention:

https://www.randori.com/blog/cve-2021-44228/

I have no idea how (or if) Tomcat is affected. I have only the vaguest 
idea what this vulnerability even *is.*


Can anybody here shed any light?

--
JHHL

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



Re: Odd messages in catalina.out

2021-12-10 Thread James H. H. Lampert

On 12/10/21 8:38 AM, Mark Thomas wrote:
. . .
The messages are there to warn you that you might have a malicious actor 
trying a brute force attack on your server.


Can anybody point me to a good tutorial for constructing a regular 
expression for RemoteAddrValve?



allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"


obviously can't work for a server that's incapable of running a browser, 
and at any rate, I can't make head or tail of the regular expression 
syntax in use here.


--
JHHL

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



Odd messages in catalina.out

2021-12-10 Thread James H. H. Lampert
Could anybody here shed some light on this message? A whole bunch of 
them appeared in catalina.out.


WARNING [https-jsse-nio-443-exec-29] 
org.apache.catalina.realm.LockOutRealm.filterLockedAccounts An attempt 
was made to authenticate the locked user [user]


--
JHHL

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



One other thing, Re: Updating Tomcat on an Amazon Linux 2 EC2 instance?

2021-12-08 Thread James H. H. Lampert
Also, based on what "yum check-update" returned, it appears that at the 
moment, I can only go as far as 8.5.72, rather than 8.5.73. Is there a 
way to go all the way to 8.5.73 without fundamentally changing how 
Tomcat is installed on that instance?


--
JHHL

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



Re: Updating Tomcat on an Amazon Linux 2 EC2 instance?

2021-12-08 Thread James H. H. Lampert

On 12/8/21 9:46 AM, jonmcalexan...@wellsfargo.com.INVALID wrote:

I think it's going to come down to how the 8.5.58 was installed. Was
it via an rpm or zip file? I have used both methods and you should be
able to install the 8.5.73 without affecting the 8.5.58. If you are
using a separated CATALINA_BASE and CATALINA_HOME, then updating your
configuration should be super simple, especially if using symbolic
links to point to your Tomcat binaries.


At first, that answer didn't seem like it was telling me much, but then 
I realized that it was telling me a great deal:


First, for some reason, I *thought* that Amazon Linux used apt, rather 
than yum, but your mention of "rpm" said otherwise, and sure enough, 
when I looked in the AWS docs, it does indeed use yum.


That, in turn, pointed me in the direction of looking up how to use yum.

That led me to try "yum check-update," which returned:
. . .

 tomcat.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5
 tomcat-admin-webapps.noarch   8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5
 tomcat-el-3.0-api.noarch  8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5
 tomcat-jsp-2.3-api.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5
 tomcat-lib.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5
 tomcat-servlet-3.1-api.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5
 tomcat-webapps.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5

. . .

and a bit more digging found "yum list installed," which returned:
. . .

 tomcat.noarch 8.5.58-1.amzn2  @amzn2extra-tomcat8.5
 tomcat-admin-webapps.noarch   8.5.58-1.amzn2  @amzn2extra-tomcat8.5
 tomcat-el-3.0-api.noarch  8.5.58-1.amzn2  @amzn2extra-tomcat8.5
 tomcat-jsp-2.3-api.noarch 8.5.58-1.amzn2  @amzn2extra-tomcat8.5
 tomcat-lib.noarch 8.5.58-1.amzn2  @amzn2extra-tomcat8.5
 tomcat-servlet-3.1-api.noarch 8.5.58-1.amzn2  @amzn2extra-tomcat8.5
 tomcat-webapps.noarch 8.5.58-1.amzn2  @amzn2extra-tomcat8.5

. . .
which matches what shows up in Manager.

So it does indeed appear that it was installed from an rpm file, via yum.

So how do I proceed from here? Would I do a "yum update tomcat.noarch"? 
And what about the webapp contexts and configuration settings (not to 
mention the settings to allow me into manager) installed in the existing 
Tomcat? (For IBM Midrange updates, we have to take care of all that 
manually, as the update there amounts to a clean installation of the 
product in a default state.)


--
JHHL

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



Updating Tomcat on an Amazon Linux 2 EC2 instance?

2021-12-08 Thread James H. H. Lampert

We have a Tomcat server running on an Amazon Linux 2 EC2 instance.

Off the top of my head, I don't remember how I originally installed it, 
but it's currently at 8.5.58.


I'd like to update it to 8.5.73, but I don't quite know how to do this 
in Amazon Linux 2 (now if somebody asked about installation or update on 
an IBM Midrange System, I could practically write a how-to manual).


Can somebody relieve my ignorance?

--
JHHL

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



Re: [SECURITY] CVE-2021-42340 Apache Tomcat DoS

2021-12-06 Thread James H. H. Lampert

On 10/14/21 7:12 AM, Mark Thomas wrote:
The fix for bug 63362 introduced a memory leak. The object introduced to 
collect metrics for HTTP upgrade connections was not released for 
WebSocket connections once the WebSocket connection was closed. This 
created a memory leak that, over time, could lead to a denial of service 
via an OutOfMemoryError.


Question:

Is this even an issue if the Tomcat is configured to *only* listen on 
443, and rejects non-HTTPS connections outright?


--
JHHL

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



Question about serving a 404

2021-09-10 Thread James H. H. Lampert

Our Tomcat team has been struggling with this issue for a few days:

If a request comes in for https://foo.com/bar.html, which doesn't exist, 
then a 404 is returned, and we see a standard Tomcat 404 page.


But if a request comes in for https://foo.com/bar.jsp, which also 
doesn't exist, then our webapp takes control, and returns a 200 with a 
redirect to a "you are not signed on" page.


In the most recent attempt to correct this, they now return a 404 page 
of their own design for both of the above scenarios. Unfortunately, if 
the webapp context we're trying to reach is installed as something other 
than ROOT (i.e., if we call it "baz," then https://foo.com/baz), then 
even a correct URL still returns a 404 page.


Seems to me that there's something wrong with this picture. Seems to me 
that a request for a nonexistent "bar.jsp" should behave the same as one 
for a nonexistent "bar.html."


Is there something I can pass along to the Tomcat team?

--
JHHL

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



200 response and redirect for ".../test.jsp"

2021-08-24 Thread James H. H. Lampert
I could have sworn I asked about this over a year ago, but I can't find 
any record of having done so.


We've got a low-priority complaint about a security scan looking for 
"test.jsp" on one of our installations, expecting a 404 response, and 
instead getting a 200 response and a redirect to our own error page.


Just a sanity check: this *is* a problem with our ROOT context, not with 
Tomcat itself, right? And it has to be solved within our ROOT context, 
right?


--
JHHL

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



Getting some peculiar TLS results in Tomcat 7

2021-08-13 Thread James H. H. Lampert

While we've been systematically updating our customer boxes, a few of
our customer boxes are still on Tomcat 7.

I've got the following Connector tag set up in server.xml:


 compressableMimeType="text/html,text/xml,text/plain,text/css,
 text/javascript,text/json,application/x-javascript, 
 application/javascript,application/json" />
And yet SSLLabs tells me the box in question is still accepting TLS 1.0 
and TLS 1.1.


Can anybody shed any light on this? (And yes, I know, "alias" should be 
"keyAlias," but it's the only chain in the keystore, so it shouldn't 
make any difference.)


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



Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

2021-08-09 Thread James H. H. Lampert

On 8/9/21 11:33 AM, Mark Thomas wrote:


The fix will be in the September releases.


Thanks.

--
JHHL

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



Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

2021-08-09 Thread James H. H. Lampert

On 8/9/21 10:24 AM, Mark Thomas wrote:
Future versions of Tomcat won't see this issue but if the customer is 
prepared to update Tomcat to fix this issue then they might as well just 
update Java (assuming that is indeed sufficient to fix this).


Given that they currently seem to be happy as clams on their currently 
installed Tomcat 7, and that we've only been updating customers to 
Tomcat 8 in order to proactively deal with any security complaints that 
might come up, they can presumably wait for a Tomcat 8 that has the 
relevant fix.


And this customer is not in any particular hurry for updating *anything* 
(a trait I share).


Any idea when a Tomcat 8 with the relevant fix might come out?

--
JHHL

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



Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

2021-08-09 Thread James H. H. Lampert

On 8/6/21 9:17 AM, Konstantin Kolinko wrote:


Try to find what *.jar file in your system contains the above classes.

E.g. searching for string "crimson" in *.jar files.
That string will be visible in the archive file as it is a name of a directory.


I've learned that QShell (a *nix-like shell that was added with Java 
support) on an AS/400 does have both "find" and "grep," so it wasn't 
quite so futile as I thought.


If I go into QShell, navigate to the JVM home directory, and do a
"find . -name '*.jar'"
I get

 ./jre/lib/ppc64/compressedrefs/jclSC180/vm.jar
 ./jre/lib/ppc64/default/jclSC180/vm.jar
 ./jre/lib/ext/db2_classes18.jar
 ./jre/lib/ext/CmpCrmf.jar
 ./jre/lib/ext/IBMSecureRandom.jar
 ./jre/lib/ext/cldrdata.jar
 ./jre/lib/ext/dnsns.jar
 ./jre/lib/ext/dtfj.jar
 ./jre/lib/ext/dtfjview.jar
 ./jre/lib/ext/gskikm.jar
 ./jre/lib/ext/healthcenter.jar
 ./jre/lib/ext/ibmcmsprovider.jar
 ./jre/lib/ext/ibmjcefips.jar
 ./jre/lib/ext/ibmjceplus.jar
 ./jre/lib/ext/ibmjceprovider.jar
 ./jre/lib/ext/ibmkeycert.jar
 ./jre/lib/ext/ibmpkcs11impl.jar
 ./jre/lib/ext/ibmsaslprovider.jar
 ./jre/lib/ext/ibmxmlcrypto.jar
 ./jre/lib/ext/ibmxmldsigprovider.jar
 ./jre/lib/ext/ibmxmlencprovider.jar
 ./jre/lib/ext/jaccess.jar
 ./jre/lib/ext/localedata.jar
 ./jre/lib/ext/nashorn.jar
 ./jre/lib/ext/traceformat.jar
 ./jre/lib/ext/xmlencfw.jar
 ./jre/lib/ext/zipfs.jar
 ./jre/lib/aggressive.jar
 ./jre/lib/charsets.jar
 ./jre/lib/dataaccess.jar
 ./jre/lib/ddr/j9ddr.jar
 ./jre/lib/deploy.jar
 ./jre/lib/ibmcertpathfw.jar
 ./jre/lib/ibmcertpathprovider.jar
 ./jre/lib/ibmcfw.jar
 ./jre/lib/ibmjcefw.jar
 ./jre/lib/ibmjgssfw.jar
 ./jre/lib/ibmjgssprovider.jar
 ./jre/lib/ibmjssefw.jar
 ./jre/lib/ibmjsseprovider2.jar
 ./jre/lib/ibmorb.jar
 ./jre/lib/ibmorbapi.jar
 ./jre/lib/ibmpkcs.jar
 ./jre/lib/ibmsaslfw.jar
 ./jre/lib/javaws.jar
 ./jre/lib/management-agent.jar
 ./jre/lib/math.jar
 ./jre/lib/plugin.jar
 ./jre/lib/resources.jar
 ./jre/lib/rt.jar
 ./jre/lib/se-service.jar
 ./jre/lib/security/US_export_policy_56bit.jar
 ./jre/lib/security/local_policy_56bit.jar
 ./jre/lib/security/policy/limited/US_export_policy.jar
 ./jre/lib/security/policy/limited/local_policy.jar
 ./jre/lib/security/policy/unlimited/US_export_policy.jar
 ./jre/lib/security/policy/unlimited/local_policy.jar
 ./jre/lib/tools/monitoring-api.jar
 ./jre/lib/xml.jar
 ./jre/lib/xmldsigfw.jar
 ./IBMmisc.jar
 ./lib/dt.jar
 ./lib/ibmorbtools.jar
 ./lib/jconsole.jar
 ./lib/tools.jar
 ./lib/IBMi5OSJSSE.jar

If I do a "find . -name '*crimson*'", I get nothing.

If I do a "find . -name '*.jar' -exec grep -l 'crimson' {} \;", I also 
get nothing.


So unless anybody else has any ideas, I'm once again stuck, at least on 
this angle.


Mark Thomas wrote:

Tomcat 7 doesn't have JASPIC support so you'll never see this issue in Tomcat 7.


. . . to which I replied (seriously, rather than flippantly) "What's a 
JASPIC?"


I've finally taken a look at what JASPIC is. Interesting. If it's JASPIC 
support in Tomcat 8 that is throwing exceptions and killing manager 
under this particular Java 8 JVM, is there a way to disable it, at least 
until the customer has their PTFs up to date?


--
JHHL

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



Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

2021-08-06 Thread James H. H. Lampert
Searching JAR files for "crimson" would likely be an exercise in 
futility on an AS/400.


--
JHHL

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



Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

2021-08-06 Thread James H. H. Lampert

On 8/6/21 1:40 AM, Mark Thomas wrote:

Tomcat 7 doesn't have JASPIC support so you'll never see this issue in 
Tomcat 7.


What's a JASPIC?

And as to configuration, Mr. Schultz, my usual procedure is to (after 
commenting out the default 8080 unsecured connector) copy and paste the 
active secured port 443 connector *directly* from the Tomcat 7 
conf/server.xml to the Tomcat 8 conf/server.xml. Ditto for the one user 
definition in tomcat-users.xml.


That particular installation has a note to add this clause

birtUseSvg
false

to the web.xml of *our webapp,* but nothing server-wide.

--
JHHL

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



More information, Re: Tomcat 8.5.68 failing on takeoff!

2021-08-05 Thread James H. H. Lampert
I finally had a chance to switch the customer back to the failing Tomcat 
8.5.68, and this is what the browser error page shows (with a 500 error):



Type Exception Report

Message AuthConfigFactory error: java.lang.reflect.InvocationTargetException

Description The server encountered an unexpected condition that 
prevented it from fulfilling the request.


Exception

java.lang.SecurityException: AuthConfigFactory error: 
java.lang.reflect.InvocationTargetException


javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:85)

org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1421)

org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1411)

org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:535)

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)

org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:698)

org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:364)

org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:624)

org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)

org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831)

org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1651)

org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:811)
Root Cause

java.lang.reflect.InvocationTargetException
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83)

sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
java.lang.reflect.Constructor.newInstance(Constructor.java:437)

javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:76)

javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:67)
java.security.AccessController.doPrivileged(AccessController.java:696)

javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:66)

org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1421)

org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1411)

org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:535)

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)

org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:698)

org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:364)

org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:624)

org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)

org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831)

org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1651)

org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:811)
Root Cause

java.lang.SecurityException: org.xml.sax.SAXNotRecognizedException: 
Feature: http://apache.org/xml/features/allow-java-encodings


org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.loadProviders(PersistentProviderRegistrations.java:65)

org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.loadPersistentRegistrations(AuthConfigFactoryImpl.java:345)

org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.(AuthConfigFactoryImpl.java:68)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83)

sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
java.lang.reflect.Constructor.newInstance(Constructor.java:437)


Re: Tomcat 8.5.68 failing on takeoff!

2021-08-03 Thread James H. H. Lampert

Mssrs. Kolinko and Schultz said:


2. The stack trace starts with "Bootstrap.main". I.e. it is the thread
that starts Tomcat.

I.e. this occurs when Tomcat starts up and has nothing to do with your
attempt to access the Manager web application.


3. The stack trace contains "org.apache.crimson".

Apache Crimson project was retired 11 years ago and should not be used 
nowadays.

https://xml.apache.org/crimson/
https://attic.apache.org/projects/crimson.html

You have that library in Tomcat classpath? Where? Why?


Good catch.

The JVM has been bundled with a SAX parser for ages, now. You might ask 
your application/engineering team if it's okay to try your application 
without a bundled XML library.


You might also ask why it's being put into CATALINA_BASE/lib (or 
endorsed-libs?) instead of in the application's WEB-INF/lib where it 
belongs.


A bit more information:

Our application isn't even *installed* in the new Tomcat yet. As I said, 
the *only* context currently in Webapps is manager; everything else was 
stripped out, including the default ROOT, shortly after I unpacked the 
Tomcat 8.5.68 ZIP file on the box.


Tomcat 7.0.93 continues to run just fine, under the same Java 8, after I 
swapped it back in (and I'm definitely glad I do updates in a way that 
makes that easy).


Last night, I was a bit lax in proofreading my initial post, and somehow 
some critical information got left out.


The stacktrace included in the post was, of course, from the launch 
process.


When I attempt to connect to manager, I get a "500-Internal Server 
Error" page, that has a few stacktraces of its own (but adds nothing to 
Catalina.out). Alas, I didn't save a copy of the error page, and it 
could be several hours before I can swap the 8.5.68 back in and take 
down the details.


Jon McAlexander suggested a possible bad JVM; while I wonder how that 
could be, given that Tomcat 7.0.98 runs just fine, I will note that this 
particular box is on a slightly different Java 8 JVM from what we see on 
other customer boxes where we already have 8.5.6x running, and I think 
we've already asked them to check on whether their Java PTFs (analogous 
to what M$ calls "service packs") are current. The Tomcat 7 manager 
reports their JVM version as "8.0.5.20 - pap6480sr5fp20-20180802_01(SR5 
FP20)"


I just checked the Catalina.out of another customer we have on 8.5.68. 
Nothing at all between
   06-Jul-2021 19:11:49.841 INFO [main] 
org.apache.catalina.startup.Catalina.load Initialization processed in 
3303 ms

and
   06-Jul-2021 19:11:49.905 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Catalina]



Is there any other information I could gather, without having to switch 
the customer's Tomcat 8 live?


--
JHHL

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



Tomcat 8.5.68 failing on takeoff!

2021-08-02 Thread James H. H. Lampert
This is beyond my pay grade, I'm afraid. Hopefully somebody here has a 
clue what went wrong.


I installed Tomcat 8.5.68 on an AS/400 with Java 8, that had been 
running Tomcat 7 for years with no problems.


On launching Tomcat 8, if I try to connect to "manager" (the only 
context currently in Webapps), right after:


02-Aug-2021 18:15:11.655 INFO [main] 
org.apache.catalina.startup.Catalina.load Initialization processed in 
3271 ms


I'm getting

02-Aug-2021 18:15:11.707 WARNING [main] 
org.apache.catalina.users.MemoryUserDatabase.open Exception configuring 
digester to permit java encoding names in XML files. Only IANA encoding 
names will be supported.
org.xml.sax.SAXNotRecognizedException: Feature: 
http://apache.org/xml/features/allow-java-encodings
	at 
org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213)
	at 
org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143)

at org.apache.crimson.jaxp.SAXParserImpl.(SAXParserImpl.java:126)
	at 
org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113)
	at 
org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141)

at 
org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:526)
	at 
org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:440)
	at 
org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:105)
	at 
org.apache.naming.factory.FactoryBase.getObjectInstance(FactoryBase.java:96)

at 
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:332)
at org.apache.naming.NamingContext.lookup(NamingContext.java:847)
at org.apache.naming.NamingContext.lookup(NamingContext.java:157)
	at 
org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:115)
	at 
org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:69)
	at 
org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:32)
	at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:131)
	at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:105)
	at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:80)
	at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
	at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)

at 
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
	at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:763)

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)

at java.lang.reflect.Method.invoke(Method.java:508)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)


I can't recall ever seeing anything like this.

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



Error that only occurs on mobile

2021-07-20 Thread James H. H. Lampert
First, understand that I have even less involvement in development of 
our mobile apps than I do in the development of our Tomcat webapp. So 
I'm grasping at straws here. All I know is that the mobile apps work 
through the webapp.


It seems that at a specific customer installation, when the mobile app 
(both Apple and Android) tries to access our BIRT-based dashboards, they 
don't work (the dashboards work fine from a desktop browser). We 
recently updated that customer from 7.0.93 to 8.5.68, and installed the 
latest version of our webapp.


The error message that appears on Android is in the form:


The webpage at https://[very long url omitted] could not be loaded because:

net::ERR_BLOCKED_BY_RESPONSE


I will note that we do have the httpHeaderSecurity filter enabled, with 
an antiClickJackingOption of SAMEORIGIN.


Does anybody here have any insights that I might pass on to the 
webapp/mobile team?


--
JHHL

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



Re: CVE-2021-25329, was Re: Most recent security-related update to 8.5

2021-07-02 Thread James H. H. Lampert

On 7/2/21 12:02 AM, Mark Thomas wrote:

It is an alternative session manager that persists session data via a 
configured Store. There are two Store implementations provided by 
default - File and DataSource.


You would know if you were using it as it requires explicit configuration.


Thanks for the specific documentation link; I would not have known where 
to look in the docs. My friends and colleagues seem to think I have 
brilliant research skills; in fact, I simply have no qualms about asking 
for help.


Our webapp totally lacks a "context.xml" (I looked for one) but I see 
such files, with Manager elements, in the manager and host-manager 
webapps. Are they affected by CVE-2021-25329/CVE-2020-9484?


Incidentally, speaking of those webapps, when installing, we immediately 
jettison all as-shipped webapps *except* manager and host-manager. We 
use manager all the time, but I'm not even sure what host-manager does.


--
JHHL

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



Re: What is "h2c"? What is CVE-2021-25329? Re: Most recent security-related update to 8.5

2021-07-01 Thread James H. H. Lampert

On 7/1/21 4:55 PM, in response to:


I will note, however, that the Tomcat servers in question are
*not* configured to listen on any ports other than HTTPS (either
443, 8443, or something else in that vein) and the shutdown port.


Shawn Heisey wrote:


In that case, you don't need h2c, and probably don't want it.



O. . . . k.

That makes sense, so far, but how is it even enabled? Is there some way
I could have h2c enabled, with the situation I described (no HTTP at 
all, not even as a redirect), and not *know* I have it enabled?


--
JHHL

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



What is "h2c"? What is CVE-2021-25329? Re: Most recent security-related update to 8.5

2021-07-01 Thread James H. H. Lampert

On 6/21/21 9:42 AM, Christopher Schultz wrote:
If you are using h2c, you'll definitely want to 8.5.63 or later, as 
there is a critical fix there.


My understanding, based on what I looked up a week and a half ago, is 
that we're not using h2c, but at the same time, don't think I fully 
understand what "h2c" is.


I will note, however, that the Tomcat servers in question are *not* 
configured to listen on any ports other than HTTPS (either 443, 8443, or 
something else in that vein) and the shutdown port.


Also, I've got somebody complaining about CVE-2021-25329. I'm not sure I 
understand what CVE-2021-25329 is, or what the underlying CVE-2020-9484 
is. And

https://nvd.nist.gov/vuln/detail/CVE-2020-9484
doesn't exactly help a whole lot: it talks about "PersistenceManager," 
and I'm not entirely sure what that even *is.*


--
JHHL



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



Re: Most recent security-related update to 8.5? And setting up access to Manager?

2021-06-21 Thread James H. H. Lampert

On 6/21/21 9:42 AM, Christopher Schultz wrote:
I think it depends upon your environment, honestly. There were many 
organizations where the "AJP endpoint is trusting, because that's what 
it's for" announcement was a real surprise and represented a must-fix 
issue immediately. That was not the case for my $work, where we were 
already protecting our AJP connections and not allowing just anyone to 
connect.


If you are using h2c, you'll definitely want to 8.5.63 or later, as 
there is a critical fix there.


We don't, so far as I'm aware, use AJP or h2c. The only enabled 
connectors are HTTPS (still coded as a Tomcat 7.0 connector and using a 
Java Keystore) and Shutdown.


--
JHHL

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



Most recent security-related update to 8.5? And setting up access to Manager?

2021-06-19 Thread James H. H. Lampert

We are finally migrating customer installations from 7 to 8.5.

Would anybody happen to know, off the top of his or her head, what the 
most recent security-related update to 8.5 is?


I know that 68 is the most recent release, but what's the most recent 
one that addresses a significant security issue?


Also, while I'm here, can somebody point me to an example of how to code 
the Manager's RemoteAddrValve setting to allow access from, say, two or 
three arbitrary IP addresses?


(And yes, this is also an excuse to double-check that my List traffic is 
getting through with DMARC enforcement turned on.)


--
JHHL

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



Heap allocations when switching from Tomcat 7 to Tomcat 8

2021-06-09 Thread James H. H. Lampert
We are beginning to migrate some of our customers from Tomcat 7 to 
Tomcat 8.5.


Some of them have performance issues even with heap allocations of 
-Xms4096m -Xmx5120m


Would it be necessary to go even bigger with Tomcat 8.5?

--
JHHL

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



Re: [OT] Re: What exactly does the AJP connector on 8009 do?

2021-04-06 Thread James H. H. Lampert

On 4/6/21 9:11 AM, Olaf Kock wrote:

*Everybody* has a dedicated testing system. Always!

*Some* are lucky that they have a completely separate production system.


We expect disk drives to fail. So we plan for it, using some form of 
RAID (full mirroring in my case).


And so the power supply fails instead.

Also:

The likelihood of a power supply failure is inversely proportional to 
its maintenance accessibility.


--
JHHL

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



Re: What exactly does the AJP connector on 8009 do?

2021-04-05 Thread James H. H. Lampert

On 4/5/21 1:22 PM, Christopher Schultz wrote:
If you are not running a reverse-proxy in front of Tomcat, then it does 
absolutely nothing for you.


If you *are* running a reverse-proxy in front of Tomcat, then it *may* 
do something for you, depending upon what software you are using and 
what its configuration is.


Thanks.

Hmm. We have *something* on one of our cloud servers, that has Tomcat 
sitting behind httpd (on the same box), and we have load balancing 
(through a couple of AWS Beanstalks) on our cloud-based product, but I 
don't know if the AJP port is involved in any of that.


--
JHHL

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



What exactly does the AJP connector on 8009 do?

2021-04-05 Thread James H. H. Lampert
We've just gotten a complaint about a vulnerability involving AJP (to 
something called "Ghostcat") from a customer. The report from the 
security consultant recommends updating to a more recent version of 
Tomcat, and I note that we've already started rolling out 7.0.108 to 
customers.


Looking at server.xml, the only reference to AJP is in relation to port 
8009, and that this connector is commented out in 108, but not in 93.


So what exactly *is* this connector, and what purpose does it serve?

--
JHHL

-
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-07 Thread James H. H. Lampert
Thanks to all, for both satisfying my morbid curiosity and verifying 
that it's the customer's problem, not mine.


--
JHHL

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

On 1/6/21 3:46 PM, Robert Turner wrote:

You'll want to set the protocols, ciphers, and honorCipherOrder ...


The precise wording in the error message is:

. . . but the server presented a certificate signed using a weak
signature algorithm (such as SHA-1). . . .


Which is to say, it doesn't sound like a cipher or protocol problem, or 
anything else that's actually under Tomcat's control.


But I figured somebody here might know something about it.

--
JHHL

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



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 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."


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



Re: Manager setup in Tomcat 8

2020-12-22 Thread James H. H. Lampert

On 12/22/20 10:51 AM, Christopher Schultz wrote:

I would try to lock-down that IP range as much as you can, rather than 
either removing the Valve (which would allow connections from anywhere) 
or specifying something like ".*" in the "allow" attribute (which is a 
regular expression which will be applied to the remote-user's IP 
address, either IPv4 or IPv6 as the case may be).


Dear Mr. Schultz:

Thanks. Very much applicable to the EC2 instance (and I recall doing 
just that, although I'd have to look at what I did to recall exactly 
how), and to most customer boxes, but not necessarily so much for this 
particular customer: they've got everything locked down in the tightest 
VPN I've ever seen.


--
JHHL

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



Manager setup in Tomcat 8

2020-12-22 Thread James H. H. Lampert
A few months back, as I recall, I ran into some "gotchas" in connection 
with the manager context, while setting up Tomcat 8.5 on one of our AWS 
EC2 instances. As I recall, I had to do something special, somthing I 
don't have to do with Tomcat 7, in order to make the manager context 
reachable from the outside.


Very shortly, I'll be setting up Tomcat 8.5 for the first time on an 
AS/400, and like the EC2, it can't exactly browse itself, so it, too, 
will need to have the manager context reachable from the outside world.


Can somebody remind me of what it is I had to do, that I don't have to 
do for Tomcat 7?


--
JHHL

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



Re: Strange crash-on-takeoff, Tomcat 7.0.104

2020-11-18 Thread James H. H. Lampert

Ladies and Gentlemen:

The same customer installation that required 104 (but with the 103 
catalina.sh, to avoid Bug 64501) back in June is now demanding an update 
to 106 because of the CVE-2020-13935 vulnerability.


Two questions:

1. Is the problem from June fixed in 106?
2. Does 106 take care of CVE-2020-13935?

--
JHHL


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



Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

2020-11-11 Thread James H. H. Lampert

On 8/21/20 1:02 PM, logo wrote:

 From my experience I have excluded .well-known from the redirect.


That appears to be the correct answer. I probably didn't see that line 
back in August, or I probably would have replied by asking something 
like, "Ok, and how do I do that?"


Be that as it may, Andrew Schulman came up with an answer on my 
ServerFault thread (https://serverfault.com/a/1041882/498231) to the 
effect of changing the rewrite block from:



RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]


to:


RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]


While I'm not going to be certain until December, when the cached 
challenge expires, it certainly seems to work: if I go to 
http://sub.domain.com, it immediately redirects me to 
https://sub.domain.com, and I get the Tomcat server, whereas if I try to 
go to http://sub.domain.com/.well-known/acme-challenge/foo, it remains 
http, and gives me the expected "Not Found" error.


--
JHHL

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



Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

2020-11-05 Thread James H. H. Lampert

On 8/24/20 9:57 AM, Christopher Schultz wrote:


So your RewriteCond[ition] is expected to always be true? Okay. Maybe
remove it, then? BTW I think your rewrite will strip query strings and
stuff like that. Maybe you just want RedirectPermanent instead of
Rewrite(Cond|Rule)?


Ladies and Gentlemen:

This past Friday, the cached challenge result expired, and so this past 
Monday, I ran another certbot test.


With the rewrite in place for our "subdomain of interest," the cert 
covering everything else served by the httpd server renewed without 
incident, but the separate cert covering this subdomain failed completely.


I commented out the rewrite, and ran the test again, and both renewed 
without incident.


I posted a redacted version of the complete VirtualHost blocks back on 
August 24th. And after I'd run my tests this week, I've also posted it 
to ServerFault, at

https://serverfault.com/q/1041047/498231

I'm intrigued by Mr. Schultz's suggestion of


Maybe you just want RedirectPermanent instead of
Rewrite(Cond|Rule)?


Would that make a difference? Or is it just a matter of altering the 
RewriteCond clause to specifically ignore anything that looks like a 
Let's Encrypt challenge? Or is there something I can put on the default 
landing page for the subdomain, rather than in the VirtualHost, to cause 
the redirection?


As I recall (unless there's a way to force-expire the cached challenge 
result on a certbot call), I have to wait until December to run another 
test.


--
JHHL

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



Re: Our webapp is running very slowly on one particular customer box

2020-10-28 Thread James H. H. Lampert

First, thanks once again, Mr. Schultz, for getting back to me.

I noticed something rather promising: it seems that maxThreads for the 
Port 443 connector were set at 150 for System "A" (problem box), but 400 
for System "J" (box that's quite happy).


I've restarted Tomcat with the maxThreads bumped up to 400, and so far, 
it seems much happier than it was. That could have been the problem all 
along.


My colleagues and I also observed that yesterday, when we did *not* shut 
down and restart, the slowdown and the nearly-full "tenured-SOA" portion 
of the heap eventually resolved itself, which suggests that it wasn't a 
memory leak in any even remotely conventional sense of the term.


The page-faulting is a virtual memory term: on an AS/400, the entire 
combined total of main storage and disk is addressable (the concept is 
called "Single-Level Store"), and virtual storage paging is built into 
the OS at a very low level; a "page fault" is when a process finds tries 
to access something that's been paged out to disk.


As to the private memory pool, it's not that the subsystem is restricted 
to its private pool; rather, everything else is kept *out* of that 
private pool. It still has full access to the "Machine" and "Base" 
shared pools.


--
JHHL

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



Our webapp is running very slowly on one particular customer box

2020-10-27 Thread James H. H. Lampert

This is related to my query (thanks, Mr. Gregg) about "Tenured SOA."

It seems that on one of our customer installations, our webapp gets into 
a state of running very slowly, and the dedicated subsystem it's running 
in is showing massive levels of page-faulting.


I've compared the GC stats of the "problem" system with one that's 
actually got more users connected, but isn't experiencing performance 
issues. It seems that they're both going to GC about every 30-50 
seconds, but GC on the "problem" system appears to be somewhat less 
effective.


Also, I've looked at the threads on both. On the system that is behaving 
normally, the "GC Slave" threads (7 of them) are showing total CPU (at 
this moment) of around 150 seconds each, and Aux I/O of mostly zero, 
with one showing 1 and one showing 3. Conversely, on the "problem" 
system, I'm seeing 15(!) GC Slave threads, each with total CPU under 6 
seconds each, but Aux I/O ranging from 5800 to over 8000.


I'm not sure what to make of this. In both cases, Tomcat's JVM is 
running in a subsystem of its own, with a private memory pool of around 
7G, and they're both running with -Xms4096m -Xmx5120m.


--
JHHL

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



What exactly is "tenured-SOA"?

2020-10-22 Thread James H. H. Lampert
In at least two of our Tomcat installations, the Server Status page of 
Manager is showing "tenured-SOA" around 3G, while the other pools are 
showing much lower. What exactly *is* "tenured-SOA," and should this be 
cause for alarm?


--
JHHL

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



Re: Recent Tomcat crash produced error messages I've never seen before

2020-10-20 Thread James H. H. Lampert

On 10/20/20 1:26 PM, Christopher Schultz wrote:

Theoretically, it should not be possible to cause a JVM to crash with
pure Java code.


Thanks.

Of course, we all know that while theory and practice are the same in 
theory, they aren't always in practice. ;-P


--
JHHL

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



Recent Tomcat crash produced error messages I've never seen before

2020-10-20 Thread James H. H. Lampert
We had a Tomcat crash on a customer box, a few hours ago (a simple 
restart got them back up and running), and it produced a whole bunch of 
errors in the general vein of

*** Invalid JIT return address 0006E2E2E400 in 0001A83C5210


before finally failing with a null pointer exception, and producing a 
Java dump, a Snap dump, and a JIT dump, all over the course of a couple 
of seconds.


Prior to that, our webapp was having a great deal of trouble accessing 
Office365.


Other than that it's almost certainly our webapp, rather than Tomcat 
itself, that caused the "Invalid JIT return address" messages, does 
anybody here have any insights? I've literally never seen messages of 
this type before.


--
JHHL

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



Re: completely automated (for real) Let's Encrypt on embedded Tomcat

2020-10-06 Thread James H. H. Lampert

On 10/6/20 2:48 PM, Christopher Schultz wrote:

Thanks for mentioning LEGO. Any time I've been mentioning certbot, you
can replace that with $your-favorite-acme-client.


You're welcome.

LEGO definitely cut my Gordian Knot on that particular project, wherein 
Certbot absolutely, positively, refused to work. The other AWS 
installations either have httpd handling the https front-ending, or they 
have a load-balancer handling it, with Amazon itself providing the certs.


So I'm always likely to suggest it as a second choice (and one that 
appears to play much more nicely with Tomcat) if certbot won't do it in 
a given situation.


--
JHHL

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



Re: completely automated (for real) Let's Encrypt on embedded Tomcat

2020-10-05 Thread James H. H. Lampert
I'm coming into this conversation late, so what I say could be 
completely irrelevant, but when I recently set up an independent (i.e., 
not behind httpd) Tomcat server on one of our AWS EC2 instances, and 
could not get certbot to function at all, to save my life, I ended up 
using something called "LEGO." It *does* require one to shut the Tomcat 
server down during the renewal process (because it has to take over the 
port briefly), but it also *does* play nicely with a Tomcat server 
that's doing its own SSL.


--
James H. H. Lampert

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



Re: SSL debug?

2020-09-08 Thread James H. H. Lampert

On 9/8/20 1:12 PM, john.e.gr...@wellsfargo.com.INVALID wrote:

I don't remember the precise problem, but verbose SSL will tell you
what trust store and key store you're using, among other things.


I don't blame you. It's been close to a month since I last attempted to 
do something about this.


The problem is that when the webapp tries to call the Google
  https://maps.googleapis.com/maps/api/geocode
web service, it gets:

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]


In the past, removing DESede from the list of disabled algorithms solved 
the problem, but it appears that in the latest IBM Java 8 JVMs, DESede 
was not only disabled, but *removed* from the JVM.


--
JHHL


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



Re: SSL debug?

2020-09-08 Thread James H. H. Lampert

I'm finally back on this problem.


We are once again having SSL difficulties with our webapp connecting
with an outside web service: the java.security override that had solved
the problem in the past (specifically, removing "DESede" from the
"jdk.tls.disabledAlgorithms" in an override file) is now failing with
certain Java 8 JVMs on AS/400s.


More specifically, the call is to
https://maps.googleapis.com/maps/api/geocode

Last month, I got a suggestion (on the Midrange Java List, but endorsed 
when I asked about it here) of adding "-Djavax.net.debug=ssl:handshake" 
to catalina.sh.


Today, I finally tried it. It took several tries before I got anything 
at all, but when I did, I got 678k of information. Any suggestions on 
where my proverbial needle would be in that haystack, and what it would 
look like?


Also today, I tried the "sledgehammer" approach of editing the JVM's own 
java.security instead of merely overriding it. No difference.


--
JHHL

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



Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

2020-08-25 Thread James H. H. Lampert

I think I found something.

At the very bottom of LE's FAQ page, https://letsencrypt.org/docs/faq
(under "I successfully renewed a certificate but validation . . ."), I
found:


Once you successfully complete the challenges for a domain, the
resulting authorization is cached for your account to use again
later. Cached authorizations last for 30 days from the time of
validation. If the certificate you requested has all of the necessary
authorizations cached then validation will not happen again until the
relevant cached authorizations expire.


In other words, the authorization cache is likely invalidating the tests 
I ran with the rewrite in place!


The more you overthink the plumbing, the easier it is to stop up the drain!

Last night, after I discovered this, I set an alarm for myself (using a 
1970s-vintage Los Angeles County Fire Station alarm*, because it's 
impossible to ignore), to try another forced renewal next month, one 
month after the original certificate issuance, and see what happens. If 
the renewal fails, it will give me two months to solve the problem.


__
* FWIW, one of many online copies of the Station 51 alarm (from 
"Emergency!") can be found at

https://tvshrine.com/Emergency/ebuzzer.wav


JHHL

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



Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

2020-08-24 Thread James H. H. Lampert

On 8/24/20 9:57 AM, Christopher Schultz wrote:

So your RewriteCond[ition] is expected to always be true? Okay. Maybe
remove it, then? BTW I think your rewrite will strip query strings and
stuff like that. Maybe you just want RedirectPermanent instead of
Rewrite(Cond|Rule)?

Okay, so everyone gets redirected from http://exmaple.com/ to
https://example.com/. If LE requests
http://example.com/.well-known/uherfhuerhfiu then it will be
redirected to https://example.com/.well-known/uherfhuerhfiu,
presumably locate the correct file and authorize the certificate
request, right?

But you have said that "everything is unconditionally passed to
Tomcat". You posted some config that definitely passes some things to
Tomcat, but without seeing the rest of the  configuration
it's not possible to know for sure nothing else is going on.


Ok. In the original post, I posted the virtual host configuration as it 
was at the time, with meaningful domain names and IP addresses redacted, 
and some commented-out, abandoned-in-place lines removed.


Here is what I currently have in place, albeit with names and IP 
addresses "changed to protect the innocent." I'm sending you the 
uncensored version off-List.


 
 ServerName foo.frobozz.com
 # ServerAlias bar.frobozz.com
 DocumentRoot /var/www/html/test
 ServerAdmin i...@frobozz.com
 
 AllowOverride All
 
  RewriteEngine on
  RewriteCond %{HTTP_HOST} !^www\. [NC]
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 

 
 
 ServerName foo.frobozz.com
 # ServerAlias bar.frobozz.com
 DocumentRoot /var/www/html/test
 ServerAdmin i...@frobozz.com
 # 
 # AllowOverride All
 # 
 # https://foo.frobozz.com/manager/html/*;>
 #  Require ip aa.bb.cc.dd
 # 
 # https://bar.frobozz.com/manager/html/*;>
 #  Require ip aa.bb.cc.dd
 #  
 
  Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
 
 
  Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
 
 ProxyPass "/" "http://127.0.0.1:8080/;
 ProxyPassReverse "/" "http://127.0.0.1:8080/;
 ProxyRequests Off
 Include /etc/letsencrypt/options-ssl-apache.conf
 SSLCertificateFile /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/foo.frobozz.com/privkey.pem
 
 

--
JHHL

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



Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

2020-08-24 Thread James H. H. Lampert

On 8/22/20 7:35 AM, Christopher Schultz wrote:


(1) every http request is unconditionally redirected to https:

RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule
^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]


This is not unconditional. That's what "RewriteCond" does: it sets up
a condition :)

If Let's Encrypt requests http://www.yoursite.com/ then it won't be
redirected.

. . .

What domains are you asking LE to certify?


Except that the "www." prefix subdomain is undefined. There's no entry 
for it in Amazon Route 53; it was deliberately *not* given in the 
initial provisioning of the cert from LE, and it's *not* in the certbot 
configuration file for the subdomain.


--
JHHL

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



Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

2020-08-18 Thread James H. H. Lampert
Something just worked, that I wasn't expecting to work. Or rather, I was 
expecting it to work, but kill cert renewal.


The port 80 virtual host had

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]


which I commented out, because https for that virtual host is a pure 
front-end for Tomcat, and of course, Certbot needs to stick something on 
the server that Let's Encrypt is expecting to be able to find.


So a few minutes ago, just for test purposes, I uncommented the above 
lines. Initially, it didn't work (it redirected the browser from 
http://foo.bar.com to a nonexistent https://www.foo.bar.com), but when I 
removed the "www" in the RewriteRule, changing the block to

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]


it worked just fine.

So then, I did a "certbot renew --force-renewal" (expecting it to fail 
on the relevant cert, but in fact, it renewed just fine.


Not to look a gift equine in the masticatory orifice, but what am I 
missing here? What went right, when I was expecting it to go wrong? Why 
didn't the "rewrite" lines break renewal?


--
JHHL

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



Re: Tomcat behind httpd, with Let's Encrypt and Certbot

2020-08-18 Thread James H. H. Lampert
Well, today, I brought the Tomcat server back up, and put the Virtual 
Host back into conf.d, and it worked.


Then I learned that my whole silly-go-round of a few months ago, trying 
to add the new subdomain to the existing certs, was completely 
unnecessary, that each subdomain's virtual host could point to its own 
cert file, and I also learned about "certbot renew --force-renewal" to 
test whether renewal would actually work (it does).


--
JHHL

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



Re: Tomcat behind httpd, with Let's Encrypt and Certbot

2020-08-16 Thread James H. H. Lampert

Permit me to clarify:

1. The existing httpd server on this box, and its certbot setup may be 
extended/expanded, but not otherwise disturbed.


2. Running Tomcat independently of httpd on this box is not an option, 
because *both* are to be visible to the outside world on port 443 of the 
same IP address. Doing so was not merely "an option," but *mandatory* on 
the other box, which has Tomcat and httpd on separate ports.


3. At this point, the concern is making certain that the httpd virtual 
host for the new subdomain provides for the needs of both Certbot and 
Tomcat. Then, I can worry about adding the new subdomain to Certbot.


--
JHHL



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



Tomcat behind httpd, with Let's Encrypt and Certbot

2020-08-14 Thread James H. H. Lampert

Now (as John Cleese would say) for something completely different.

I've got my indpendent Tomcat and httpd servers on the development box 
(the Amazon Linux "Not 2" instance) successfully obtaining, using and (I 
hope) auto-renewing a Let's Encrypt cert via Lego. (I'll know more on 
September 6th: the cron log shows it ran this past Sunday, but the 
auto-update script skips the actual renewal if it's not the first Sunday 
of the month.)


But now, I have a situation in which I *do* want Tomcat running behind 
httpd, on an Amazon Linux 2 instance that's already obtaining a Let's 
Encrypt cert via certbot. But the last time I experimented with this one 
(several months ago, like the one I finally got working with Lego), I 
had a fair amount of trouble getting it even partially functional, and 
something I did badly screwed up the auto-renewal, which we didn't find 
out about until the cert expired on us.


Here is the (actual names and IP addresses redacted) httpd conf file I 
added, to provide the virtual host for the new subdomain. It makes no 
difference to me whether browser requests sent to port 80 get redirected 
to https or not; the important part is that (1) Certbot and Let's 
Encrypt can see and do what they need to, (2) users can reach all webapp 
contexts on the Tomcat server, including ROOT, and (3) only the 
specified IP addresses can see manager and host-manager.


Is there anything obvious that I'm doing wrong?

 
 ServerName xyweb.frobozz.com
 DocumentRoot /var/www/html/test
 ServerAdmin i...@frobozz.com
 
 AllowOverride All
 
 # RewriteEngine on
 # RewriteCond %{HTTP_HOST} !^www\. [NC]
 # RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 

 
 
 ServerName xyweb.frobozz.com
 DocumentRoot /var/www/html/test
 ServerAdmin i...@frobozz.com
 
  Require ip ww.xx.yy.zz aa.bb.cc.dd ee.ff.gg.hh
 
 
  Require ip ww.xx.yy.zz aa.bb.cc.dd ee.ff.gg.hh
 
 ProxyPass "/" "http://127.0.0.1:8080/;
 ProxyPassReverse "/" "http://127.0.0.1:8080/;
 ProxyRequests Off
 Include /etc/letsencrypt/options-ssl-apache.conf
 SSLCertificateFile /etc/letsencrypt/live/fizmo.com/fullchain.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/fizmo.com/privkey.pem
 
 

--
JHHL

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



SSL debug?

2020-08-12 Thread James H. H. Lampert

Question:

We are once again having SSL difficulties with our webapp connecting 
with an outside web service: the java.security override that had solved 
the problem in the past (specifically, removing "DESede" from the 
"jdk.tls.disabledAlgorithms" in an override file) is now failing with 
certain Java 8 JVMs on AS/400s.


Somebody on the Midrange Java List suggested using


-Djavax.net.debug=ssl:handshake


in catalina.sh, to gather more information on the problem.

Would that actually help with our present situation? Or would it only 
cover problems with users connecting to Tomcat from their browsers?


--
JHHL

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



Final results of my Let's Encrypt project

2020-08-07 Thread James H. H. Lampert

Ladies and Gentlemen:

The server that had me tearing my hair out has now been entirely 
switched over to Let's Encrypt, and it's working quite well, so far. 
Thanks to everybody on this List, on the Orange County Linux User Group 
List, on Server Fault, and on the Bitnami support board, who assisted.


In particular, thanks to Christopher Schultz. It is always good to be 
able to stand upon the shoulders of a giant.


Some things I learned that may be of use to others:

1. If one is unable to get Certbot to work in a given situation, Lego 
may be a viable alternative. It does, however, require a brief server 
shutdown to run, as it does need to take over the ports while operating.


2. If one is having trouble getting Lego to work when you have ports 
mapped (e.g., 8443 appearing as 443 from the outside via iptables), 
adding "--http.port :80" and/or "--tls.port :8443" to the lego 
invocation may help.


3. If one is having trouble getting Tomcat to use .crt and .key files, 
it is not difficult to turn them into a PKCS12 keystore, which Tomcat 
can then use. (Again, thanks, Mr. Schultz!)


--
James H. H. Lampert


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



Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

2020-08-06 Thread James H. H. Lampert

On 8/6/20 10:10 AM, Christopher Schultz wrote:


$ openssl pkcs12 -export \ -in /etc/tomcat8/test.foo.net.crt \
-inkey /etc/tomcat8/test.foo.net.key \ -certfile
/etc/tomcat8/test.foo.net.issuer.crt \ -out
/etc/tomcat8/test.foo.net.p12 \ -chain

Then reconfigure your  to use your keystore.


Dear Mr. Schultz (et al):

It was a bit of a challenge to find out how to use a PKCS12 keystore in 
the Certificate clause, but not that difficult. And the "-chain" was not 
necessary.


At any rate, congratulations, you have just cut my proverbial Gordian knot!

In my case, there's obviously no need for the


curl https://localhost/manager/jmxproxy?invoke=Catalina%3Atype
%3DProtocolHandler%2Cport%3D8443%2Caddress%3D
%22127.0.0.1%22=reloadSslHostConfigs


in my renewal script, as given in your presentation, because it's 
already necessary to shut down Tomcat for the renewal: the known-good 
procedure for getting a Let's Encrypt on an Amazon Linux (not "2") 
instance with a Bitnami Trac/SVN stack uses Lego, rather than Certbot, 
and Lego needs to take over all the ports in order to do its magic 
(probably why Lego is not as popular as Certbot).


And likewise, since I'm generating a PKCS12 keystore, rather than using 
the certificate and key files directly, I was able to cut out making 
local copies of those files, and just reference the ones that Lego put 
in /opt/trac-1.2.3-11/letsencrypt/certificates/ directly.


--
James H. H. Lampert

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



Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

2020-08-06 Thread James H. H. Lampert

On 8/6/20 9:37 AM, Christopher Schultz wrote:

$ openssl pkcs12 -export \
-inkey /etc/tomcat8/test.foo.net.key \
-


Dear Mr. Schultz:

Is there supposed to be something after that last hyphen? When I type 
that command, I just get a terminal window full of helptext.



And if I try the second command,

$ openssl pkcs12 -export \
  -in /etc/tomcat8/test.foo.net.crt \
  -inkey /etc/tomcat8/test.foo.net.key \
  -certfile /etc/tomcat8/test.foo.net.issuer.crt \
  -out /etc/tomcat8/test.foo.net.p12 \
  -chain


without the first, I get:

Error unable to get local issuer certificate getting chain.


--
JHHL

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



Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

2020-08-06 Thread James H. H. Lampert

On 8/6/20 9:37 AM, Christopher Schultz wrote:
. . .

As a short-term workaround, you can load your stuff into a keystore
like this:

$ openssl pkcs12 -export \
-inkey /etc/tomcat8/test.foo.net.key \
-

$ openssl pkcs12 -export \
   -in /etc/tomcat8/test.foo.net.crt \
   -inkey /etc/tomcat8/test.foo.net.key \
   -certfile /etc/tomcat8/test.foo.net.issuer.crt \
   -out /etc/tomcat8/test.foo.net.p12 \
   -chain

Then reconfigure your  to use your keystore.


Dear Mr. Schultz:

Thanks.

That could even be a permanent workaround if it can be done 
non-interactively.


How, I wonder, is it that the PEM files work just fine after the 
"unwanted update" that bumped Tomcat up from 40 to 57, and pulled in a 
slightly newer Java 1.8?


--
JHHL

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



Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

2020-08-05 Thread James H. H. Lampert

On 8/5/20 5:04 PM, calder wrote:


Caused by: java.security.KeyStoreException:


Cannot store non-PrivateKeys



If you pasted the full stack trace, then here we have the last "caused by",
showing one issue

   at
sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)

   at

sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)

   at

sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)

   at

sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)

   at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
   at org.apache.tomcat.util.net

.SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)

   at org.apache.tomcat.util.net

.SSLUtilBase.createSSLContext(SSLUtilBase.java:239)

   at org.apache.tomcat.util.net

.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)

   ... 20 more


That is inded the full stack trace, or at least as much of it as went 
into catalina.out.


And all the differences in domain names and filenames are accounted for, 
canceling each other out, leaving only the "unwanted update" as the 
biggest single difference between the two instances. Looking at the 
Manager, I see that in addition to Tomcat being updated from 8.5.40 to 
8.5.57, the JVM was evidently updated from 1.8.0_201-b09 to 1.8.0_252-b09.


--
JHHL


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



Correction, Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

2020-08-05 Thread James H. H. Lampert

I wrote:
. . .
It seems that with the unwanted update to 7.0.57 that happened on 
launching the test spot instances, the Let's Encrypt certs worked just 
fine.


But applying the procedure to the *real* development instance (7.0.40) 
blew up in my face, failing to open the connectors. Here is an excerpt 
from catalina.out, showing the stacktraces.

. . .

Oops. I'm so used to installing and running 7.0.xx on AS/400s that I 
mistyped the above. Of course, I meant 8.5.57 and 8.5.40, respectively, 
as given in the subject line and the rest of my post.


--
JHHL

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



Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

2020-08-05 Thread James H. H. Lampert

Ladies and Gentlemen:

I've now proceeded to the "real" server, with the Tomcat portion of the 
procedure refined to give me plenty of "undo" capability. And it turns 
out I need it.


It seems that with the unwanted update to 7.0.57 that happened on 
launching the test spot instances, the Let's Encrypt certs worked just fine.


But applying the procedure to the *real* development instance (7.0.40) 
blew up in my face, failing to open the connectors. Here is an excerpt 
from catalina.out, showing the stacktraces.



05-Aug-2020 23:00:52.038 WARNING [main] 
org.apache.catalina.startup.SetAllPropertiesRule.begin 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'bufferSize' 
to '1024' did not find a matching property.
05-Aug-2020 23:00:52.085 WARNING [main] 
org.apache.catalina.startup.SetAllPropertiesRule.begin 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'bufferSize' 
to '1024' did not find a matching property.
05-Aug-2020 23:00:52.189 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version:
Apache Tomcat/8.5.40
05-Aug-2020 23:00:52.189 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server built:  
May 2 2019 18:02:51 UTC
05-Aug-2020 23:00:52.194 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server number: 
8.5.40.0
05-Aug-2020 23:00:52.194 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Name:   
Linux
05-Aug-2020 23:00:52.194 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
4.14.121-85.96.amzn1.x86_64
05-Aug-2020 23:00:52.194 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Architecture:  
amd64
05-Aug-2020 23:00:52.195 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Java Home: 
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.43.amzn1.x86_64/jre
05-Aug-2020 23:00:52.195 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   
1.8.0_201-b09
05-Aug-2020 23:00:52.195 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
Oracle Corporation
05-Aug-2020 23:00:52.195 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: 
/usr/share/tomcat8
05-Aug-2020 23:00:52.196 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: 
/usr/share/tomcat8
05-Aug-2020 23:00:52.196 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dcatalina.base=/usr/share/tomcat8
05-Aug-2020 23:00:52.196 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dcatalina.home=/usr/share/tomcat8
05-Aug-2020 23:00:52.197 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.endorsed.dirs=
05-Aug-2020 23:00:52.197 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.io.tmpdir=/var/cache/tomcat8/temp
05-Aug-2020 23:00:52.197 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.util.logging.config.file=/usr/share/tomcat8/conf/logging.properties
05-Aug-2020 23:00:52.197 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
05-Aug-2020 23:00:52.198 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]
05-Aug-2020 23:00:52.422 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing 
ProtocolHandler ["https-jsse-nio-8443"]
05-Aug-2020 23:00:52.848 SEVERE [main] 
org.apache.catalina.core.StandardService.initInternal Failed to initialize 
connector [Connector[HTTP/1.1-8443]]
 org.apache.catalina.LifecycleException: Failed to initialize component 
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
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:639)
at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at 

Re: Connector works fine with Firefox, but not on speaking terms with Chrome!

2020-08-05 Thread James H. H. Lampert

Jon Mcalexander wrote:


Most likely then you need to find a cypher list that is valid for TLSv1.2. Such 
as below:

ACCEPTABLE

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256

IDEAL
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256


I came up with a couple of things to try, while I was at lunch.

First, I did a quick SSLLabs scan on the server. That told me that 
"sslEnabledProtocols" in an SSLHostConfig was indeed wrong. And it told 
me that all simulated Chrome handshakes failed, but most other simulated 
handshakes were fine.


Then (directly violating the "change only one variable at a time" 
principle) I set it back to "protocols," *and* cut out the cipher list 
entirely.


That worked just fine.

The weird part is that so far as I can tell, the cipher list looks 
*exactly* like the cipher list in the original Java Keystore version of 
the connector


I compared the cipher lists given in the SSLLabs reports for three 
cases: the new connector with the old cipher list, the new connector 
with no cipher list at all, and (using the live version of the server) 
the old connector with the old cipher list, and the results were remarkable:


test, no cipher list
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)   WEAK 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	128

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)   WEAK   128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	128

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)   WEAK  128
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)   WEAK128
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS	128

TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) 128
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)   128
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)   WEAK 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	256

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)   WEAK   256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	256

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)   WEAK  256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)   WEAK256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS	256

TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e) 256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)   256


test, with old cipher list
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)   WEAK 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	128

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)   WEAK   128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	128

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)   WEAK  128
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)   WEAK128
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)   WEAK 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	256

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)   WEAK   256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	256

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)   WEAK  256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)   WEAK256


original connector, with old cipher list
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 
bits RSA)   FS   WEAK	128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	128

TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 
bits RSA)   FS   WEAK	256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp521r1 (eq. 
15360 bits RSA)   FS   WEAK	256


The test with no cipher list produced (I think) five matches with your 
"acceptable" list, two of which were also on your "ideal" list.


The test with the old cipher list on the new connector produced only 12 
of the 18 on the "no cipher list" test, none of which were on either of 
your lists.


And the original connector produced what appears to be a completely 
different list in the report, with nothing in common with the other two, 
or with your lists, and yet it is TLS 1.2-only, and it seems to get 
along just fine with 

Re: Connector works fine with Firefox, but not on speaking terms with Chrome!

2020-08-05 Thread James H. H. Lampert

On 8/5/20 10:43 AM, calder wrote:

certificateVerificationh="none"

there's one issue (misspelling), though may not be a contributing
factor.


Corrected; no effect.

Jon McAlexander wrote:

I believe that

protocols="TLSv1.2">

should be

sslEnabledProtocol="TLSv1.2"



My understanding of the instructions is that "protocols" is correct for
an SSLHostConfig, whereas "sslEnabledProtocols" is correct for a
Connector without an SSLHostConfig. At any rate, I tried "protocols," 
"sslEnabledProtocol," and "sslEnabledProtocols"; no effect. Firefox 
still likes it just fine (and so does Safari), but Chrome chokes on it 
(and if there's a diagnostic to tell me the gory details of WHY it's 
choking on it, I don't know where to find it). And both Chrome and 
Firefox like the new LE cert just fine in httpd.


If it will help, the real domain is
https://test.wintouch.net

--
JHHL


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



Connector works fine with Firefox, but not on speaking terms with Chrome!

2020-08-05 Thread James H. H. Lampert

I've now managed to get an experimental copy of our development AWS EC2
instance working with a cert from Let's Encrypt, and I've got Tomcat to
launch with a modified connector that uses the LE certs rather than a
Java Keystore file.

It looks great from Firefox (except for the still-unanswered riddle of
the unwanted Tomcat update), but from Chrome, I get (domain name 
"changed to protect the innocent"):



This site can’t provide a secure connection

test.foo.net 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.


The modified connector looks like this:

protocol="org.apache.coyote.http11.Http11NioProtocol"
   compression="on" compressionMinSize="2048" 
noCompressionUserAgents="gozilla, traviata"


compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json"
   maxThreads="1000" socket.appReadBufSize="1024" 
socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" 
scheme="https" secure="true">
   ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,


TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA"
 certificateVerificationh="none" sslProtocol="TLS" 
protocols="TLSv1.2">
 certificateFile="/etc/tomcat8/test.foo.net.crt" 
certificateKeyFile="/etc/tomcat8/test.foo.net.key"


certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/>
  



Can anybody shed any light on what I did wrong?

--
James H. H. Lampert

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



Weirdness going on with Tomcat on an AWS instance

2020-08-04 Thread James H. H. Lampert

Ladies and Gentlemen:

I am once again attempting to get our development AWS box switched over 
to Let's Encrypt.


This time, I've managed to get the httpd server working with the Let's 
Encrypt cert. And this time, I've even managed to get Tomcat 8.5 to use 
it without crashing on takeoff. It's not yet on speaking terms with 
Chrome, but Firefox can access it just fine. And that's when I noticed 
the weirdness:


The mere act of spinning up a spot instance from last night's backup 
caused Tomcat to update itself to the latest version (from 8.5.40 to 
8.5.57).


This would not be a bad thing in and of itself, except for two side effects:
First, the default ROOT context was overlaid onto our ROOT context!

Second, Manager was disabled!

I spun up a new spot instance, the same way I did the one I'm using for 
my experiments, and sure enough, the ROOT context was changed: eleven 
files were added, and an undetermined number were changed.


The other contexts appear to all be there, but the "examples" context, 
which we remove from all our working Tomcat installations, was added 
back in.


But our server.xml appears to be completely intact, and so does our 
tomcat-users.xml.


Yet, as I said, Manager is disabled.

Can anybody shed any light on what happened?

--
James H. H. Lampert

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



Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

2020-07-20 Thread James H. H. Lampert

Mark Thomas and Christopher Schultz wrote:


You want:

sslProtocol="TLS" sslEnabledProtocols="TLSv1.2"

And to answer my question above, because that is the way the JSSE
API has been written.


We should probably just merge these into a single attribute and "do
the right thing":

1. If not specified, do nothing unusual
2. If the value includes a ",", use it for sslEnabledProtocols, use
"TLS" as sslProtocol
3. Otherwise, use value for both sslProtocol AND sslEnabledProtocols

Practically speaking, the only useful value for sslProtocol today is
"TLS". You can specify e.g. "TLSv1.2" and I think it will restrict
sslEnabledProtocols to TLSv1.2 but using the same value for both has
the same effect, of course.

In the future, if anything other than "TLS" makes sense for
sslProtocol, we can change Tomcat to support that.

We should also probably have SSLEnabled="true" be the default if any
TLS-related configuration option is used on a connector.

WDYT?


Well, I think (from direct experience) that for Tomcat 7 running on an 
AS/400, "merge these into a single attribute and 'do the right thing'" 
*is* how it works, so the entirety of Christopher's suggestion makes 
perfect sense to me.


At any rate, thanks to both of you; it works.

Although it does raise the question of whether the observed behavior in 
Tomcat 7 on an AS/400 is a Tomcat 7 thing or an AS/400 thing.


--
JHHL

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



Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

2020-07-17 Thread James H. H. Lampert

On 7/17/20 2:36 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:

This looks like a cipher, not an alias

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256


As I said, of course it's a cipher. I said up front that the lines were 
truncated, in order to fit in an email.


I can't imagine why seeing the whole connector would make a difference, 
but if anybody wants to see it un-truncated, (albeit with the same 
redactions), it's now also on ServerFault, at

  https://serverfault.com/q/1025706/498231?sem=2

--
JHHL

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



Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

2020-07-17 Thread James H. H. Lampert

On 7/17/20 2:36 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:

This looks like a cipher, not an alias

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256


It is. The lines are truncated at 72 characters for the email.

--
JHHL

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



Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

2020-07-17 Thread James H. H. Lampert
Running two connectors seems to work just fine, but I'm having trouble 
getting one of them to only take TLS 1.2


In reply to my query:


Given all this, is it possible to (1) have Tomcat listen on two separate
HTTPS ports, and (2) have one of the ports require TLS 1.2, but the
other accept something our AS/400 can use?


On 7/17/20 10:03 AM, Mark Thomas wrote:


Yes. You need two Connector elements specifying different ports and
different protocols. They should be able to use the same certificate
configuration.


I just ran a test on our development Amazon EC2 instance, and verified 
that I could listen on two different ports (existing 8443 and now 7443), 
and I limited (or so I thought) 8443 (to which I have 443 rerouted 
through iptables) to TLS 1.2.


Except that SSLLabs tells me it's still accepting TLS 1.0 and 1.1!

I commented out the connector for 8443 and restarted Tomcat, but it's 
still giving the same report from SSLLabs.


The connector for 8443 in server.xml looks like this (lines truncated):




The 'sslProtocol="TLSv1.2"' clause is copied directly from the Tomcat 7 
installation on our most security-conscious customer's AS/400; this 
Tomcat is 8.5. Am I specifying it wrong?


--
JHHL

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



SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

2020-07-17 Thread James H. H. Lampert

I've got an issue here.

On the one hand, we have a Tomcat server running on Amazon (in a 
Beanstalk cluster). And we have an AS/400 running an old enough OS that, 
so far as I'm aware, cannot be configured to use TLS 1.2 at the current 
OS release level. And that AS/400 needs to access that Tomcat server 
(which it does, using Scott Klement's open source HTTPAPI product, which 
has become pretty much an industry standard for the purpose).


And on the other hand, we are getting a security report from SSLLabs, 
telling us that our security rating is capped at "B" because we allow 
TLS 1.0 and 1.1.


BUT, our entire office is on a static IP address, and we already know 
how to open a port on our Amazon firewall to only accept traffic from 
our office IP.


Given all this, is it possible to (1) have Tomcat listen on two separate 
HTTPS ports, and (2) have one of the ports require TLS 1.2, but the 
other accept something our AS/400 can use?


--
James H. H. Lampert

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



Re: Strange crash-on-takeoff, Tomcat 7.0.104

2020-06-22 Thread James H. H. Lampert

On 6/20/20 8:41 AM, Mark Thomas wrote:


7.0.105 hasn't been released yet. You can use catalina.sh from 7.0
103 or the latest version from source control.


Where would I find "the latest version from source control"?

--
JHHL

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



Re: Strange crash-on-takeoff, Tomcat 7.0.104

2020-06-19 Thread James H. H. Lampert

On 6/19/20 3:20 PM, Mark Thomas wrote:

https://bz.apache.org/bugzilla/show_bug.cgi?id=64501


Hmm. I'm now looking through the entire catalina.sh script in both 
versions. (First, I looked through the startup.sh script; that appears 
to be identical in both versions.)


First thing I noticed was that a few new environment variables were 
listed in the documentation section at the top.


Second thing I noticed was the section beginning
# Ensure that neither CATALINA_HOME nor CATALINA_BASE contains a colon 


Third thing I noticed was in the secetion marked "Bugzilla 37848 . . ."
old:

if [ "`tty`" != "not a tty" ]; then


new:

if [ -t 0 ]; then


Fourth thing I noticed was the section marked
# Check for the deprecated LOGGING_CONFIG 


This looks an awful lot like what's in the Bugzilla page. And I see that 
it is "Fixed in . . . 7.0.105 onwards."


But the download page for 7 is still at 7.0.104.

--
JHHL

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



Re: Strange crash-on-takeoff, Tomcat 7.0.104

2020-06-19 Thread James H. H. Lampert

On 6/19/20 2:27 PM, calder wrote:


a) it's worth asking the obvious ... are the file permissions correct for
the new TCp installation, i.e , such as read/write in "logs" subdir and
execute permissions for the TC scripts?


Unless something weird is going on with the apache-tomcat-7.0.104.zip 
file, it appears that all the authorities match between old and new 
versions.



b) are you using the same Java instance for both TC's ?


Normally, for native-command-line launches, or launches from native CL 
programs (like shell scripts, only compiled), we have a CL program 
("STRTOMCAT") that does a fair amount of advance setup, selects the 
first available JVM from a preference list, and then QShell's out 
startup.sh as a batch job. This CL program expects Tomcat to be in a 
particular place in the file system, in a directory called "tomcat." So 
to switch to a new Tomcat server, I shut the current one down, rename 
the current "tomcat" directory to something else (e.g., "tomcat93"), and 
rename the "apache-tomcat-7.0.104" directory to "tomcat" before starting 
it with STRTOMCAT.


So it would *have* to be the same JVM, because that's explicitly 
selected by the STRTOMCAT CL program.


--
JHHL

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



Re: Strange crash-on-takeoff, Tomcat 7.0.104 (Trying again)

2020-06-19 Thread James H. H. Lampert

On 6/19/20 1:24 PM, Christopher Schultz wrote:


My guess is that the system-property-setting part of catalina.sh (or
some other script) is getting fouled-up. What script(s) are you
running to start Tomcat?


Remember, we're talking about IBM Midrange systems, not *nix. So bash is 
entirely unknown to the OS; instead, startup.sh calls catalina.sh, with 
everything running under "QShell," a Linux-like front-end that was 
provided with Java.



If it's just catalina.sh, try running it like this:

$ bash -x $CATALINA_HOME/bin/catalina.sh

This will echo every command run to the console before running it,
including all expanded arguments and all that stuff. Most likely, the
last command run will (a) be the one which is interesting and (b) will
be clear from the command what went wrong.


Unfortunately, QShell doesn't appear to have anyplace to put "-x" as a 
parameter.


But it does appear to support "set -x" at the QShell command line. If I 
do that, then I get:

|$
|  > set -x
|+  set -x
|$
|  > catalina.sh
|+  catalina.sh
|*-D
|$


PS You really are a magnet for weird problems with Tomcat, aren't you?


Well, it comes with the territory of running Tomcat on AS/400s, I 
suppose. I'm thinking I should bring in the Java list over at 
Midrange.com as well.


--
JHHL

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



Re: Strange crash-on-takeoff, Tomcat 7.0.104

2020-06-19 Thread James H. H. Lampert

On 6/19/20 1:24 PM, Christopher Schultz wrote:


My guess is that the system-property-setting part of catalina.sh (or
some other script) is getting fouled-up. What script(s) are you
running to start Tomcat?


Remember, we're talking about IBM Midrange systems, not *nix. So bash is 
entirely unknown to the OS; instead, startup.sh calls catalina.sh, with 
everything running under "QShell," a Linux-like front-end that was 
provided with Java.



If it's just catalina.sh, try running it like this:

$ bash -x $CATALINA_HOME/bin/catalina.sh

This will echo every command run to the console before running it,
including all expanded arguments and all that stuff. Most likely, the
last command run will (a) be the one which is interesting and (b) will
be clear from the command what went wrong.


Unfortunately, QShell doesn't appear to have anyplace to put "-x" as a 
parameter.


But it does appear to support "set -x" at the QShell command line. If I 
do that, then I get:
   $
 > set -x   
   +  set -x
   $
 > catalina.sh  
   +  catalina.sh   
   *-D  
   $



PS You really are a magnet for weird problems with Tomcat, aren't you?


Well, it comes with the territory of running Tomcat on AS/400s, I 
suppose. I'm thinking I should bring in the Java list over at 
Midrange.com as well.


--
JHHL

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



Re: Strange crash-on-takeoff, Tomcat 7.0.104

2020-06-19 Thread James H. H. Lampert

On 6/19/20 1:26 PM, calder wrote:

a) are both Tomcat instances installed on that same server?


Yes


b) if yes, is the 7.0.93 instance running when you launch the 7.0.104
instance?


No.

We've done this procedure before: installing a new version, doing the 
setup in the new version, then shutting down the old version, renaming 
both the old and the new versions (so things are where they're expected 
to be), and starting up.


--
JHHL

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



Strange crash-on-takeoff, Tomcat 7.0.104

2020-06-19 Thread James H. H. Lampert

Ladies and Gentlemen:

In preparation for updating a customer box, I installed Tomcat 7.0.104 
on our own AS/400 (64-bit Java 6 JVM).


7.0.93 works just fine on our box, but 7.0.104 seems to crash on 
takeoff, producing no log files, just a spool file consisting of the 
single line


*-D

Any idea what could be going wrong?

--
JHHL

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



Strange occurrence with Tomcat running on an AWS EC2 instance

2020-05-18 Thread James H. H. Lampert
I'm hoping to get the one web server we still have on a cert we have to 
pay for switched over to Let's Encrypt, and so I cloned the server in 
question to a spot instance.


The server in question is an EC2 instance running Amazon Linux (not 
Amazon Linux 2), with a Bitnami Trac/SVN stack on it, and Tomcat 8 
installed independently of the Bitnami stack.


To clone it, I created an AMI from the most recent backup snapshot, and 
then launched a spot instance from that AMI.


Once the test instance spun up, when I was finally able to connect to 
the Tomcat server on it, I found that (1) it had been updated, (2) the 
ROOT context had been partially overwritten with the default ROOT 
context, and (3) the manager context had been returned to the "factory" 
disabled state.


To coin a phrase, "What just happened?"

Can anybody shed any light on this?

--
JHHL



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



Re: Removing Tomcat ROOT directory causes the server to hang on startup

2020-04-21 Thread James H. H. Lampert

On 4/21/20 6:20 AM, Clough, Don wrote:

Is it possible to remove the tomcat ROOT directory? We have several
applications running on a tomcat instance. I was asked to clean the
webapps directory up and remove any unused folders.
Of course it is. The ROOT that comes with Tomcat is simply a 
demonstration webapp, and can be removed and/or replaced like any other 
webapp. Our normal "new installation" procedure, for example, is to 
remove everything but manager and host-manager, and plug our own webapp 
in as the ROOT context.


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



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

2020-04-09 Thread James H. H. Lampert

Dear Mr. Schultz:

Delighted to hear from you, and delighted that you weighed in on this. 
You've already earned my undying respect and gratitude. This also allows 
us to drop one more cert that we have to pay for, and I think it could 
lead to an easy way to drop yet another.


On 4/9/20 3:31 PM, Christopher Schultz wrote:
. . .

First of all, definitely use mod_proxy and definitely use
mod_proxy_http (and not mod_proxy_ajp).


It seemed the more straightforward of the two options. And it was 
already there.



0. DO NOT TRY TO USE YOUR PROXY TO RE-WRITE URL-SPACES


And you still don't talk about Fight Club . . . ;P


If you have an application hosted on Tomcat in /foo then map it to
/foo on the proxy.


Done. That was also the advice I got from Mr. Eggers, and with multiple 
contexts, I saw no reason to copy that particular mistake that somewhat 
untrustworthy tutorial page.



1. Configure your Tomcat connector


I left it "stock"; given that I'm going to be removing the extra 
security group that temporarily gave me direct access to the Tomcat 
port, I saw no reason to go with a nonstandard port number.



2. Configure mod_proxy to act as a proxy

   ProxyRequests Off # this is to disable forward-proxying (!!)


Done, but that's the default anyway.


   ProxyPass /context1/ http://localhost:1234/context1/
   ProxyPassReverse /context1/ http://localhost:1234/context1/

3. Celebrate


Not much time for that: I'm still in the process of reconstructing a WAR 
file for one of the contexts. I had to reconstruct an Eclipse project in 
order to do so. And I'm not much more knowledgable about Eclipse than I 
am about httpd.



4. If localhost, use http; otherwise, use https. This requires a TLS
cert, which may be irritating to accomplish with an "internal" host.
Note that httpd isn't terribly picky about the signature on the TLS
certificate of the origin server (Tomcat), so you can self-sign if
you'd like.


It's localhost.


5. Without additional configuration on the Tomcat side, you'll find
that your access logs tell you that all visitors have the same IP
address (surprise! it's your reverse-proxy!). Have a look at the
RemoteIPValve[1] to get that all fixed up.


Not something we pay a lot of attention to.


6. If you have your static content files on the web server, you may be
able to improve performance a bit by NOT proxying requests to the
static content.

Not enough static content to bother with.


7. Adding more origin servers requires a slightly different
configuration.


Not even remotely enough traffic to warrant a load balancer. We have 
another product that's running behind a load balancer, in an Elastic 
Beanstalk stack; outside of torture-testing and some occasional early 
bugs, we haven't actually seen it spawn off a second node. Then again, 
that product is very new.


--
JHHL

-
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-09 Thread James H. H. Lampert

On 4/9/20 1:37 PM, Peter Kreuser wrote:

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


   Require 



Dear Herr Kreuser:

Thanks. I was beginning to wonder if Location might be the answer.

--
JHHL

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



  1   2   3   4   >