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 W
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 mobil
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
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 probab
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
understan
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 cas
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
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
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 fai
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 it
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 a
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...@
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 sou
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'
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 b
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 fr
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
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,
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
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 bum
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 t
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
---
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
--
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
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, refus
thing 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.
--
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.
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 no
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 us
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
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 se
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,
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 cou
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
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
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
certai
s.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. Schu
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/cert
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 se
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
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)
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 e
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 E
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_W
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 in
;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
y 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
Is the war file being built with maven? ...gradle? ...or using Eclipse?
James
On Tue, Jul 28, 2020 at 9:34 PM Mohan T wrote:
> Dear All,
>
>
>
> In one of the environments we are using apache-tomcat-8.5.35.
>
>
>
> On server start we are getting this exception
>
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 specif
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 w
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
---
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 someth
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
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
-
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
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
fil
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 unknow
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 unknow
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 shutti
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 ide
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, 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 C
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,
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
-
On 4/6/20 2:13 PM, Mark Eggers wrote:
# Secure your proxy - localhost for now - this is IMPORTANT
Require ip 127
Dear Mr. Eggers:
It seems I was right about how what you said about this, and what the
docs say about it, appeared to contradict each other: with that in the
VirtualHost with
On 4/8/20 4:57 PM, Mark Eggers wrote:
See
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy
for some examples.
Yes. That's the very point in the documentation that has my head spinning:
For example, the following will allow only hosts in
yournetwork.example.com to access content via y
On 4/8/20 3:52 PM, Mark Eggers wrote:
Require ip 127
Dear Mr. Eggers (et al.):
I'm still not clear on what that even *does* (and the official docs
leave me even more confused: "only allow hosts in . . . to access
content via your proxy"); could you (or somebody else) explain it?
Remem
Dear Mr. Eggers, et al.:
Well, after running test installations of Tomcat on a whole string of
EC2 spot instances, I went ahead and installed it on the target server.
I've got it running, and enabled to start automatically, and I've added
a security group to temporarily open 8080 to my office
I don't have enough reputation points to comment on your question on
serverfault.
Is your DocumentRoot (/var/www/html/test) underneath the default
DocumentRoot (normally /var/www/html)?
I found the problem, and it wasn't a [profanity] server problem; it was
a [profanity] client problem!
This
As it happens, I'm now struggling with an issue just trying to get a new
virtual host up and running on the httpd server. I've put it on Server
Fault, at: https://preview.tinyurl.com/rr3rxwa
While it may not be necessary to solve this problem in order to get the
httpd server to proxy the Tomca
First of all, thank you, Mr. Malcom, Herr Kreuser, and Mr. Eggers.
One thing I will note is that near as I can tell, mod_proxy and
mod_proxy_http are already present on the system (I can find
"mod_proxy.so" and "mod_proxy_http.so"), but mod_jk does not appear to
be present (no sign of a "mod_j
l.com/vwnutqj
Is it any good?
Third, am I correct in assuming that all we need to do in order for the
existing Let's Encrypt setup to cover the new "qux" and "corge"
subdomains is to add them to the SANs already listed?
Finally, are there any &quo
Question:
I'm looking at the header of a "java.security" properties file. And I see:
# This is the "master security properties file".
#
# An alternate java.security properties file may be specified
# from the command line
place we can put the
classes?
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 3/24/20 2:25 PM, Christopher Schultz wrote:
I don't understand exactly how X-Frame-Options (which is what the
HttpHeaderSecurityFilter is configuring) is being used by your
application, but I believe X-Frame-Options is essentially being
replaced by various features of Content-Security-Policy.
On 3/24/20 2:25 PM, Christopher Schultz wrote:
. . .
Your problem may stem from the same, related issues we were having. . .
Dear Mr. Schultz:
Thank you very much. I've passed on your reply to our webapp and
mobile-app team.
--
JHHL
-
sights I
could pass on to our webapp/mobile app team.
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 3/18/20 4:03 AM, Mark Thomas replied to my questions:
But I'm not sure (1) how security constraints interact with other
security constraints, and
See section 13.8.1 of the Servlet 4.0 spec.
(2) whether they can go in the conf/web.xml as
well as individual webapps' web.xml files.
Yes the
On 3/19/20 12:26 PM, Christopher Schultz wrote:
In case(2) can you show us what certificates are present in your keystore?
Something like:
$ keytool -verbose -list -keystore server.jks
Dear Mr. Schultz, et al:
Actually, at least with the version of keytool I have, it would be more
like:
"k
We maintain a bunch of Tomcat 7 servers for various customers, all using
JSSE security, with a JKS.
All of them show a complete certificate chain when accessed from a
browser. Some (if TLSv1.2 is not enabled, and especially those running
on boxes that don't have Java 7 or Java 8) get complaint
On 3/18/20 1:16 AM, Olaf Kock wrote:
Are you sure that this is for tomcat, not for your own application?
Actually, since on-screen it looks like one of ours, I was already
leaning to that conclusion, and had brought it to the attention of our
webapp developer.
Thanks for all the responses
On 3/17/20 3:50 PM, Mark Thomas wrote:
The XXS might be valid. I assume the tool provided a sample URL you
could use to validate the finding. That should point you in the right
direction but feel free to ask here if more help is required.
Near as I can tell, it did but it didn't provide a sample
On 3/17/20 3:34 PM, Martin Grigorov wrote:
Reading the quoted text I'd suggest you to throw this tool in the bin.
I hope you didn't pay for it.
Are you suggesting that we throw a paying customer "in the bin?"
It is not OUR audit; it is the CUSTOMER's audit (the report
self-identifies as being
On 3/17/20 3:18 PM, Martynas Jusevičius wrote:
why should DELETE or OPTIONS not be enabled? They are standard HTTP methods.
True, but (quoting the audit report)
. . . [DELETE] may allow a remote attacker to delete arbitrary files . . . .
and (again quoting the report)
Web servers that resp
Ladies and Gentlemen:
One of our customers did a security audit on the Tomcat server we
maintain on their system, and it found a few issues:
First, it found a cross-site scripting vulnerability.
Second, it found the HTTP DELETE method enabled.
Third, it found a click-jacking vulnerability.
This was not a client box, nor one of our cloud boxes; it's our own
production box.
Shortly after I posted my query to the List, I was directed to re-IPL
the system. I initiated the requested restart, and went to lunch.
That worked. The Tomcat server is back up, with all contexts running.
--
Ladies and Gentlemen of the Tomcat List:
We have a situation.
Earlier today, something (we don't know what) caused the Tomcat (7.0.93)
server on our AS/400 to go crazy, producing a 70G+ catalina.out file,
and rendering the machine generally unresponsive.
Once I was able to get a terminal ses
Last night, we switched the customer box in question from running Tomcat
under Java 7 (64-bit) to Java 8 (64-bit), and all day today, the
processor load from the Tomcat server has been dramatically lighter. I
haven't seen the overall CPU over around 70% today, and haven't seen the
Tomcat's JVM
From the :
How many VPs does your partition have?
Hardware: Power7 vs Power8/Power9?
How many GC threads?
I wish I knew how to determine the answers to these. What I *do* know is
that the box in question self-IDs as model "22A" (which I've never heard
of, which in itself suggests Power9), wi
I've got some more detailed GC stats. The full report runs 600 pages for
just the last 300 GC cycles, so I've just included three cycles worth of
data:
GC Cycle Number : 1801
Basic GC Cycle Information:
Current
On 2/12/20 5:37 AM, Niranjan Babu Bommu wrote:
have you turned on codecahe , if that is true can you monitor codecahe?
known issue with codecache in java 7, when codecache fills up the compiler
may not get get restarted even after the codecache occupancy drops down to
half after the emergency flu
Would switching to Java 8 help? Would switching to 7.0.93 help?
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 1/9/20 1:24 AM, Mark Thomas wrote:
The moderators are aware of the situation. The subscriber in question
was blocked from making further posts an hour or so ago.
I'm glad to see that I'm not the only one who looked at those posts, and
found them less-than-helpful (I think every link he post
I wrote:
Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt"
and ".key" files directly, instead of the Java Keystore file?
On 12/30/19 1:41 PM, Peter Kreuser wrote:
Correct!
I tried an experiment this afternoon:
I made a copy of the existing server.xml file, and I changed th
On 1/8/20 5:18 AM, Christopher Schultz wrote:
. . .
Now the URL line becomes (for me, using a management port):
http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa
ndler,port%3D8215&op=reloadSslHostConfigs
. . .
Have you configured any elements, or are you using the
old-s
On 1/7/20 4:54 PM, Christopher Schultz wrote:
I have further confused you, because TCP packets+connections also have
state, and I misspoke.
Think nothing of it: at my age, I'm easily confused.
--
JHHL
-
To unsubscribe, e-mai
On 1/7/20 4:19 PM, Christopher Schultz wrote:
You probably "spelled" something incorrectly. It might be a
quoting/escaping issue. It might be a literal misspelling/typo.
The JMXProxyServlet shouldn't NPE like that, though.
I'll take a look and see if we can give you a better error message
than
On 1/7/20 4:17 PM, Christopher Schultz wrote:
iptables doesn't work on pipes, it works on packets. So you have to
redirect both incoming AND outgoing packets. That's why you have the
"output redirect" as well as the (more obvious) "input redirect".
Well, that just leaves me more puzzled than ev
This just gets weirder and weirder.
I added manager-jmx to the admin account. I continued to get "401
unauthorized."
I then tried setting up another user, temporarily, with a URL-friendly
user-ID and password. If I just gave that user "manager-gui," I got "403
access denied" instead, regardl
On 1/7/20 7:32 AM, Christopher Schultz wrote:
Hah, sorry about that. Nobody thought of specifying that only root can
view the iptables stuff. :)
Not your fault, nor that of anybody else here; I blame the author of
iptables and iptables-save: it should either (a) allow *anybody* to
*see* the i
101 - 200 of 767 matches
Mail list logo
