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
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.
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
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
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?
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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".
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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,
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,
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.
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
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
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
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
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
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
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
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
43" 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!)
--
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.
--
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
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
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
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
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
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
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
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
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
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
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
equire 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
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
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
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
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
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
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
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
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?
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!
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
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
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 "gotchas" I need to be concerned w
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
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
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
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:
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
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
1 - 100 of 323 matches
Mail list logo
