ou can understand
my concerns.
Do you understand why it was rated LOW by OpenSSL and why it was rated
CRITICAL by NVD?
Are you aware that CVE-2024-5535 does not affect tcnative? This is one
of several reasons we did not race to issue an updated version of
tcnative, etc.
In conclusi
calculator?name=CVE-2024-5535=AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H=3.1=CISA-ADP>
> from Source: CISA-ADP. With that, we could not underestimate such issue.
> Hope you can understand my concerns.
>
> In conclusion, we anticipate the upcoming release of Tomcat Native, which
>
timate such issue. Hope
you can understand my concerns.
In conclusion, we anticipate the upcoming release of Tomcat Native, which will
incorporate the latest OpenSSL version and be included in the new Tomcat
release. Thank you.
Best regards,
Peyton Zhong
From: Mark Thomas
Date: Sunday, 7 Jul
Chris, thanks for your comprehensive explanation about these various mitigation
measures.
Best regards,
Peyton Zhong
From: Christopher Schultz
Date: Sunday, 7 July 2024 at 1:23 AM
To: users@tomcat.apache.org
Subject: Re: Inquiry about CVE-2024-5535 Vulnerability in Tomcat 10.1.20 Version
0.1.20 version. According
to Black Duck Binary Analysis (BDBA) scans, this vulnerability has been identified
within the Tomcat 10.1.20 version. There are other detected vulnerabilities inside
OpenSSL on Tomcat, such as CVE-2024-4603
The detected file is: apache-tomcat-10.1.20/bin/tcnative-2.dll
Peyton,
On 7/6/24 00:08, Zhong, Peyton wrote:
I am writing to inquire about the potential impact of the recently detected critical
vulnerability: CVE-2024-5535<https://nvd.nist.gov/vuln/detail/CVE-2024-5535>
(9.1 CRITICAL / CVSS v3), in OpenSSL 3.0.13 on the Tomcat 10.1.20 version. Acc
Dear Tomcat Community,
I am writing to inquire about the potential impact of the recently detected
critical vulnerability:
CVE-2024-5535<https://nvd.nist.gov/vuln/detail/CVE-2024-5535> (9.1 CRITICAL /
CVSS v3), in OpenSSL 3.0.13 on the Tomcat 10.1.20 version. According to Black
Duck
Chaitanya,
On 6/5/24 09:11, Chaitanya Gopisetti wrote:
Also can you update on the End of life expected date for Tomcat 9.0.x version
-Original Message-
From: Christopher Schultz
Sent: Wednesday, June 5, 2024 6:37 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.xx JDK Version
On 05/06/2024 15:11, Chaitanya Gopisetti wrote:
Also can you update on the End of life expected date for Tomcat 9.0.x version
Best guess (based on the next major release being in ~3 years time)
right now is 31 March 2027 for 9.0.x noting that a 9.10.x will follow to
retain supoprt
Also can you update on the End of life expected date for Tomcat 9.0.x version
-Original Message-
From: Christopher Schultz
Sent: Wednesday, June 5, 2024 6:37 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.xx JDK Version Support and EOL
Chaitanya,
On 6/5/24 08:47, Chaitanya
Chaitanya,
On 6/5/24 08:47, Chaitanya Gopisetti wrote:
It was mentioned that Tomcat 9.0.x supports java 8 and later. So
wanted to know whether it supports Jdk 21? Also wanted to know the
End of life expected date for Tomcat 9.0.x version.
Tomcat 9 should run jut fine on any Java version from
Hi,
It was mentioned that Tomcat 9.0.x supports java 8 and later. So wanted to know
whether it supports Jdk 21?
Also wanted to know the End of life expected date for Tomcat 9.0.x version.
Regards,
Chaitanya
To the extent permitted by law, we may monitor electronic communications
On 25/01/2024 13:55, Tobias Blum (Fujitsu) wrote:
Hello together,
we have updated the Tomcat from Version 9.0.65 to Version 9.0.79.
We are running tomcat on Windows Server 2019
Our Tomcat Version is delivered with SAP BusinessObjects.
We have configured for our Web Application which runs
Hello together,
we have updated the Tomcat from Version 9.0.65 to Version 9.0.79.
We are running tomcat on Windows Server 2019
Our Tomcat Version is delivered with SAP BusinessObjects.
We have configured for our Web Application which runs on the Tomcat the SAML2
Authentication, after
Hi.
On 2023-10-13 (Fr.) 08:29, Navya wrote:
Thanks for the reply
Currently in tomcat 9 I am using Keycloak Adapter version of 21.1.2
KEYCLOAKSUBDIR = 21.1.2
KEYCLOAKVERSION = keycloak-oidc-tomcat-adapter-$(KEYCLOAKSUBDIR)
A fast search in the Internet shows that this adapter is Deprecated
Thanks for the reply
Currently in tomcat 9 I am using Keycloak Adapter version of 21.1.2
KEYCLOAKSUBDIR = 21.1.2
KEYCLOAKVERSION = keycloak-oidc-tomcat-adapter-$(KEYCLOAKSUBDIR)
On Fri, Oct 13, 2023 at 11:47 AM Bernd Schatz
wrote:
> Hi Navya,
>
>
> Am 13.10.23 um 07:49 schrieb Nav
Hi Navya,
Am 13.10.23 um 07:49 schrieb Navya:
I am trying to upgrade the tomcat 9 to 10 version, May I know which version
of the keycloak adapter is compatible with tomcat10?
Which or what kind of ,,keycloak adapter'' do you use with your
current tomcat9 version ?
--
Greets
Bernd
Hi,
I am trying to upgrade the tomcat 9 to 10 version, May I know which version
of the keycloak adapter is compatible with tomcat10?
Thanks,
Navya
Hi,
I am trying to upgrade the tomcat 9 to 10 version, May I know which version
of the keycloak adapter is compatible with tomcat10?
Thanks,
Navya
On Sun, Aug 20, 2023 at 4:25 PM wrote:
> Kaushal,
>
> please check the new configuration method with SSLHostConfig - your's is
> probably from an older version, right? In the working version you already
> use it.
>
> see my (redacted) config:
>
> protoco
Kaushal,
please check the new configuration method with SSLHostConfig - your's is
probably from an older version, right? In the working version you already use
it.
see my (redacted) config:
truststoreFile="${catalina.base}/conf/ssl/cacert
> >
>> > I have gone through
>> https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html.
>> > Is there a way to enable two way SSL (mutual) in Apache Tomcat 10
>> Version
>> > 10.0.27?
>> >
>> > Please guide me.
>> >
>>
there a way to enable two way SSL (mutual) in Apache Tomcat 10 Version
> > 10.0.27?
> >
> > Please guide me.
> >
> > Thanks in Advance.
>
> I see you have "gone through" the SSL Howto, but could you be specific
> about what you have actually don
Kaushal,
On 8/7/23 22:23, Kaushal Shriyan wrote:
Hi,
I have gone through https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html.
Is there a way to enable two way SSL (mutual) in Apache Tomcat 10 Version
10.0.27?
Please guide me.
Thanks in Advance.
I see you have "gone through&quo
Hi,
I have gone through https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html.
Is there a way to enable two way SSL (mutual) in Apache Tomcat 10 Version
10.0.27?
Please guide me.
Thanks in Advance.
Best Regards,
Kaushal
Hi-
I am resending my msg. in plain text wondering how to get tomcat to render my
servlet for hellworld from code I got at w3schools.
I am trying to follow the guidelines:
TOMCAT 10.1.10 + plain text email!
THANKS
code and configuration files:
import java.io.IOException;
import
to user different version of
commons-fileupload
On 25/02/2023 17:28, Ph. Dinh wrote:
> Hi,
>
> Is there a way to try different versions of commons-fileupload (i.e 1.3, 1.4,
> and 1.5) on a Tomcat server (either 9.0 or 10.x)?
Drop the necessary JARs (commons-dbcp, commons-pool) into
$CATAL
anced configuration" section will work.
If not possible, is there a version of Tomcat that has the latest security fix
in commons-fileupload 1.5?
https://lists.apache.org/thread/hfq0okgjr4h5qkjzp009jn8v1hs0430k
Mark
-
To unsubscri
://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html
"Advanced configuration" section will work.
If not possible, is there a version of Tomcat that has the latest security fix
in commons-fileupload 1.5?
Thanks,
PD.
List
Subject: Re: Receiving HTTP (any version but 3 prefered) over UDP
[...]
Due to my soon forthcoming project being a streaming media site, true real time
delivery is the most important thing, and from my past work as a protocol
designer, I can say without any qualification that TCP is absolu
Hi.
On 11.12.22 17:44, Shawn Heisey wrote:
On 12/10/22 15:15, Aryeh Friedman wrote:
Is there any browser support for direct UDP sockets in any browser
besides Chrome? I know WebRTC and Websockets force TCP. I know
Chrome does support UDP but can find no evidence one way for the other
browsers.
On 12/12/2022 01:16, Tim N wrote:
Will session fail-over work b/w minor versions? i.e. can you cycle through
upgrading Tomcat in a cluster from say 9.0.67 to 9.0.68?
Generally, yes. But always check the change log and the migration guide
in case we had to make a change that places some sort
Will session fail-over work b/w minor versions? i.e. can you cycle through
upgrading Tomcat in a cluster from say 9.0.67 to 9.0.68? Also, is there any
official documentation on this?
On 12/10/22 15:15, Aryeh Friedman wrote:
Is there any browser support for direct UDP sockets in any browser
besides Chrome? I know WebRTC and Websockets force TCP. I know
Chrome does support UDP but can find no evidence one way for the other
browsers.
I'm sure you know that if Chrome is doing
hat HTTP/3 *always* uses
> TLS. It's baked into the protocol and NOT optional as with earlier HTTP
> versions. As far as I know, HTTP/3 is the only version of HTTP that
> uses UDP transport.
Is there any browser support for direct UDP sockets in any browser
besides Chrome? I know WebRTC a
HTTP
versions. As far as I know, HTTP/3 is the only version of HTTP that
uses UDP transport.
Thanks,
Shawn
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h
On Fri, Dec 9, 2022 at 4:02 AM Mark Thomas wrote:
>
> On 08/12/2022 21:55, Aryeh Friedman wrote:
> > I just tried the following command to test if tomcat does in fact listen on
> > UDP:
> >
> > aryeh@sarek1024% nc -u localhost 8080
> > GET / HTTP/1.1
> >
> >
> > aryeh@sarek1024%
> >
> > Which is
On Fri, Dec 9, 2022 at 10:02 AM Mark Thomas wrote:
>
> On 08/12/2022 21:55, Aryeh Friedman wrote:
> > I just tried the following command to test if tomcat does in fact listen on
> > UDP:
> >
> > aryeh@sarek1024% nc -u localhost 8080
> > GET / HTTP/1.1
> >
> >
> > aryeh@sarek1024%
> >
> > Which
.
we could see support of OpenSSL 3.0. for tomcat native.
Yes, both Tomcat Native 1.2.x and 2.0.x can be compiled with OpenSSL
3.0.0. Tomcat Native 2.0.x requires OpenSSL 3.0.x as a minimum.
The current minimum OpenSSL version for Tomcat Native 1.2.x is OpenSSL
1.0.2 although that OpenSSL
On 08/12/2022 21:55, Aryeh Friedman wrote:
I just tried the following command to test if tomcat does in fact listen on UDP:
aryeh@sarek1024% nc -u localhost 8080
GET / HTTP/1.1
aryeh@sarek1024%
Which is nice to see tomcat is listening
That command doesn't do what you think it does.
UDP
-Original Message-
From: Mark Thomas
Sent: 07 December 2022 19:01
To: users@tomcat.apache.org
Subject: Re: Regarding Compilation Steps for Tomcat version 9 on RHEL8
On 07/12/2022 09:36, Vivek Naruka (EXT-NSB) wrote:
> Hi,
>
> We have downloaded Tomcat version 9 "apache-tomcat-9.0.7
I just tried the following command to test if tomcat does in fact listen on UDP:
aryeh@sarek1024% nc -u localhost 8080
GET / HTTP/1.1
aryeh@sarek1024%
Which is nice to see tomcat is listening but it is not apparently
processing any requests since doing the same on TCP yields:
aryeh@sarek1024%
On 07/12/2022 09:36, Vivek Naruka (EXT-NSB) wrote:
Hi,
We have downloaded Tomcat version 9 "apache-tomcat-9.0.70.tar.gz" from
https://tomcat.apache.org/download-90.cgi.
To check the compatibility of Tomcat version 9.0 with OpenSSL 3.0, we need to
compile source code of Tomcat
Hi,
We have downloaded Tomcat version 9 "apache-tomcat-9.0.70.tar.gz" from
https://tomcat.apache.org/download-90.cgi.
To check the compatibility of Tomcat version 9.0 with OpenSSL 3.0, we need to
compile source code of Tomcat version 9 on RHEL-8 with OpenSSL3.0.
We require compila
.x is stable (best guess ~April 2024). There should be a formal
announcement for 8.5.x soon.
Then, major releases are typically released every 3 to 3.5 years.
9.x is a special case since it is the last version that supports Java
EE. The exact plan is TBD but rather than 9.0.x being made EOL
Hi,
On Thu, Nov 24, 2022 at 10:54 AM Rathore, Rajendra wrote:
>
> Hi Team,
>
> Can you please share the timeline for retiring the individual tomcat release ?
>
> Tomcat retirement plan date(tentative)
> 8.5.x
> 9.x.x
> 10.0.x
> 10.1.x
>
> Based on above table we will plan which
Hi Team,
Can you please share the timeline for retiring the individual tomcat release ?
Tomcat retirement plan date(tentative)
8.5.x
9.x.x
10.0.x
10.1.x
Based on above table we will plan which tomcat is long term supported so that
we can use it for our software.
Thanks and
* that:
- Tomcat 8.5.x will no EOL no earlier than 31 March 2024
- Tomcat 9.0.x will be EOL no earlier than 31 March 2027
There is no need up update the specification version in your web
application to run on a newer version of Tomcat
Mark
Hi All,
We are currently using Tomcat 8 and want to upgrade as it has reached EOL.
Our project uses servlet spec 3.1. I understand upgrading to 8.5 from 8
will be very easy, but till when will 8.5 be supported? If we upgrade to 9
should we upgrade servlet spec in our application pom.xml from 3.1
ge
3. https://dlcdn.apache.org/tomcat/tomcat-10/
You might also be able to do something with a dummy Maven project and
a dependency on org.apache.tomcat:tomcat and an appropriate version
range.
Mark
On 03/09/2022 00:27, NH Rao wrote:
Greetings,
I am looking for a perma link or similar
something with a dummy Maven project and a
dependency on org.apache.tomcat:tomcat and an appropriate version range.
Mark
On 03/09/2022 00:27, NH Rao wrote:
Greetings,
I am looking for a perma link or similar which won't go away and point to
latest version of tomcat for the currently supported
Greetings,
I am looking for a perma link or similar which won't go away and point to
latest version of tomcat for the currently supported major versions.
Official downloads page points to latest minor release of the major version
e.g. https://tomcat.apache.org/download-90.cgi and download links
our application must not package any of the specification API jars
> provided by Tomcat. That includes annotation-api.jar
>
> Tomcat implements the specific version of the API defined by those jars.
> You can't drop in a different API version and expect Tomcat to magically
> implement that new
Your application must not package any of the specification API jars
provided by Tomcat. That includes annotation-api.jar
Tomcat implements the specific version of the API defined by those jars.
You can't drop in a different API version and expect Tomcat to magically
implement that new version
> java/Tomcat
> > startup these libraries are being loaded in a different order depending
> > on
> > the tomcat version. The order is reliably different and reproducible.
>
> Kudos for tracking this down.
>
> > The conclusion is that Tomcat indeed implements F
named JAR. Sometime during
java/Tomcat
startup these libraries are being loaded in a different order depending
on
the tomcat version. The order is reliably different and reproducible.
Kudos for tracking this down.
The conclusion is that Tomcat indeed implements Filter lifecycle
annotation
> -Ursprüngliche Nachricht-
> Von: Cherio
> Gesendet: Dienstag, 5. April 2022 17:17
> An: Tomcat Users List
> Betreff: Re: PostConstruct annotation in a filter since version 9.0.60
>
> I did ran the diffs between versions. With my naked eye I didn't spot
> any
at
startup these libraries are being loaded in a different order depending on
the tomcat version. The order is reliably different and reproducible.
The conclusion is that Tomcat indeed implements Filter lifecycle annotation
processing but it does not run when those annotations are loaded from the
a
em could come from
> there ?
>
> >
> > The code that adds the filter is super simple:
> >
> > FilterRegistration.Dynamic filterName =
> > servletContext.addFilter(FILTER_NAME, filterObject);
> >
> sessionContextFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherT
ontext.addFilter(FILTER_NAME, filterObject);
> sessionContextFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST),
> true, "/*");
>
> The filter is a Spring an annotated class. in version 9.0.59 and
> before @PostConstruct was only handled by Spring. Star
ode that adds the filter is super simple:
>
> FilterRegistration.Dynamic filterName =
> servletContext.addFilter(FILTER_NAME, filterObject);
> sessionContextFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST),
> true, "/*");
>
> The filter is a Spring a
The filter is a Spring an annotated class. in version 9.0.59 and
before @PostConstruct was only handled by Spring. Starting with version
9.0.60, Tomcat attempts to handle PostConstruct. It produces an exception
(see below) and fails to start the application.
12:34:56.789 ERROR o.a.c.c.C.[.[.[/pr
сб, 2 апр. 2022 г. в 00:02, Cherio :
>
> I observed an announced change in behavior in version 9.0.60 (and later).
>
> My application has a Spring class loaded as a javax.servlet.Filter. It has
> a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59
&
Fax: 0049 (0)30 / 6 29 33 29 6
Handy: 0049 (0)176 / 87 521 576
Handy: 0049 (0)176 / 47 876 303
Gesendet: Freitag, 01. April 2022 um 23:02 Uhr
Von: "Cherio"
An: users@tomcat.apache.org
Betreff: PostConstruct annotation in a filter since version 9.0.60
I observed an announced change i
I observed an announced change in behavior in version 9.0.60 (and later).
My application has a Spring class loaded as a javax.servlet.Filter. It has
a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59
the annotation was handled by Spring. Starting with Tomcat 9.0.60
the transition from Java EE to Jakarta EE is going to be a big mess
cs> and the version-numbering for Tomcat is the last of anyone's
cs> problems. Aligning to the Jakarta EE version will help everybody
cs> moving forward, so that's what we've chosen to do.
+1
To quote Patrick Star, "
boss...) must be changed or adapted. For me, this is
> > enough reason to force a mayor version change)
> >
> > If you see from a developer point of view:
> >
> > - Versión 10.0 (supports Jakarta EE 9) disappeared when Jakarta EE 10
> > released (a
> Christopher Schultz wrote:
> So we're sorry if our decisions about the version numbering scheme are
> disturbing you.
Just to add another data point:
I don’t care about the numbering scheme as long as the code does what
I need it to do. Tomcat works for me and does it very well
tty, jboss...) must be changed or adapted. For me, this is
enough reason to force a mayor version change)
If you see from a developer point of view:
- Versión 10.0 (supports Jakarta EE 9) disappeared when Jakarta EE 10
released (as proposed in your link)
- I prefer ignore the 10.0
is
enough reason to force a mayor version change)
If you see from a developer point of view:
- Versión 10.0 (supports Jakarta EE 9) disappeared when Jakarta EE 10
released (as proposed in your link)
- I prefer ignore the 10.0.X version (currently is latest and stable
release
On 13/03/2022 13:29, Jose Illescas wrote:
I think that Tomcat mayor version must be change when updateing some of
their specs (servlet/jsp7/websockets/...)
This strategy allow us to refer to tomcat with: Tomcat-9 or Tomcat-10
avoiding annoying names as tomcat-10.0.X or tomcat-10.1.X
IMHO
I think that Tomcat mayor version must be change when updateing some of
their specs (servlet/jsp7/websockets/...)
This strategy allow us to refer to tomcat with: Tomcat-9 or Tomcat-10
avoiding annoying names as tomcat-10.0.X or tomcat-10.1.X
IMHO I think that Tomcat 10.1.X version must
Java version
Hi,
we were affected - we use an AccessLogValve, which logs to Log4j2 and we use
Log4j as java.util.logging LogManager. We already patched, but only on Saturday.
In any case: in a lot of places I saw "recent JRE versions have a mitigation in
place", but I can't seem to
> From: Juri Berlanda
> Sent: 13 December 2021 15:03
> Subject: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs
> compile time Java version
> Hi,
> we were affected - we use an AccessLogValve, which logs to Log4j2 and we
> use Log4j as java.util.logging L
-44228 Log4j 2 Vulnerability - Runtime vs compile time
Java version
Hi,
we were affected - we use an AccessLogValve, which logs to Log4j2 and we use
Log4j as java.util.logging LogManager. We already patched, but only on Saturday.
In any case: in a lot of places I saw "recent JRE versions
There have been multiple Patches for RMI and LDAP over time in Java.
The first article states which attack (from the one the researcher analyzed)
was possible in which version.
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
https://github.com/mbechler/marshalsec
which JRE version
introduced which mitigation. Can anybody here point me to where I can
find that information? Googling for this only seems to bring up
everybody's security advisories, but nobody seems to bother to state
exact JRE versions.
Cheers,
Juri
On 12/13/21 2:13 PM, Christopher Schultz w
HI Mark,
Thank you. That clarifies something I was not quite getting.
Surely setting a system property “log4j2.formatMsgNoLookups” does not require a
particular JRE version?
And no, it doesn’t.
Yes – we’d need to upgrade log4j2 and/or add that parameter. Whilst the JRE
version might deliver
tion would be to upgrade log4j if possible, or use
one of the several other mitigations available for recent versions. If
you aren't running a recent version, RUN ONE.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.
version of the JRE that matters.
It is also correct that using the latest JDK is *not* sufficient to
protect against this issue.
Depending on what classes are on the class path, it may be possible to
trigger an LDAP call to a malicious LDAP server that, with a specially
crafted response, can
To: users@tomcat.apache.org
Subject: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java
version
Hi all,
Suspecting that someone here knows the answer immediately, I thought I’d ask.
If you do not know the answer, please don’t spend any time investigating: I’ll
do that later today
Hi all,
Suspecting that someone here knows the answer immediately, I thought I'd ask.
If you do not know the answer, please don't spend any time investigating: I'll
do that later today and update everyone whether or not I find an answer.
Our security team advise that "Certain versions of the
Thanks a lot Mark.
-Original Message-
From: Mark Thomas
Sent: Thursday, October 21, 2021 4:23 PM
To: users@tomcat.apache.org
Subject: Re: xsd version used for web.xml etc
On 21/10/2021 10:37, S Abirami wrote:
> Hi Thomas,
>
> How I can identify whether the schema validatio
-
From: Mark Thomas
Sent: Thursday, October 21, 2021 2:40 PM
To: users@tomcat.apache.org
Subject: Re: xsd version used for web.xml etc
On 21/10/2021 09:45, S Abirami wrote:
Hi All,
In web.xml, if we didn't define any xsd schema or dtd schema which version of
xsd will be loaded for Tomcat
: xsd version used for web.xml etc
On 21/10/2021 09:45, S Abirami wrote:
> Hi All,
>
> In web.xml, if we didn't define any xsd schema or dtd schema which version of
> xsd will be loaded for Tomcat 9.0.45.
By default none - whether a schema is defined or not. Schemas are
Thanks Thomas.
-Original Message-
From: Mark Thomas
Sent: Thursday, October 21, 2021 2:40 PM
To: users@tomcat.apache.org
Subject: Re: xsd version used for web.xml etc
On 21/10/2021 09:45, S Abirami wrote:
> Hi All,
>
> In web.xml, if we didn't define any xsd schema or dtd sch
On 21/10/2021 09:45, S Abirami wrote:
Hi All,
In web.xml, if we didn't define any xsd schema or dtd schema which version of
xsd will be loaded for Tomcat 9.0.45.
By default none - whether a schema is defined or not. Schemas are only
loaded if validation is enabled.
With validation
Hi All,
TOMCAT_BASE/conf/web.xml will be constructed by us during installation.
So that web.xml also will not have xsd definition.
Regards,
Abirami.S
-Original Message-
From: Jean-Pierre Urkens
Sent: Thursday, October 21, 2021 2:25 PM
To: Tomcat Users List
Subject: RE: xsd version
My guess, the one that is specified in TOMCAT_BASE/conf/web.xml
-Original Message-
From: S Abirami
Sent: donderdag 21 oktober 2021 10:46
To: Tomcat Users List
Subject: xsd version used for web.xml etc
Hi All,
In web.xml, if we didn't define any xsd schema or dtd schema which version
Hi All,
In web.xml, if we didn't define any xsd schema or dtd schema which version of
xsd will be loaded for Tomcat 9.0.45.
Regards,
Abirami.S
the
behavior OP is reporting, here.
All the evidence so far points to user error.
+1
-chris
-Original Message-
From: Christopher Schultz
Sent: Monday, October 18, 2021 10:14 PM
To: users@tomcat.apache.org
Subject: Re: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
Natraj
esday, October 19, 2021 2:11 PM
To: Tomcat Users List
Subject: AW: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
Hello,
I can recommend SSLScan for verifying your configuration:
https://protect2.fireeye.com/v1/url?k=b3c1d19c-ec5aebd9-b3c19107-867b36d1634c-7180cbae66c5853c=1=3a5
disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 enabled
Greetings,
Thomas
-Ursprüngliche Nachricht-
Von: Mark Thomas
Gesendet: Dienstag, 19. Oktober 2021 10:18
An: users@tomcat.apache.org
Betreff: Re: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
On 19/10/2021
: Christopher Schultz
Sent: Monday, October 18, 2021 10:14 PM
To: users@tomcat.apache.org
Subject: Re: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
Natraj,
On 10/18/21 01:19, Natraj Thekkan wrote:
@Mark
Thanks for your response.
We have tested by removing that line of code
of TLS version in HTTP2 over HTTPS with OpenSSL
Natraj,
On 10/18/21 01:19, Natraj Thekkan wrote:
> @Mark
> Thanks for your response.
>
> We have tested by removing that line of code, still client able to establish
> the connection with server using TLSv1 and TLS
Natraj,
On 10/18/21 01:19, Natraj Thekkan wrote:
@Mark
Thanks for your response.
We have tested by removing that line of code, still client able to establish
the connection with server using TLSv1 and TLSv1.1. Below one is configured in
java.security file.
=SSLv3,TLSv1,TLSv1.1,RC4,MD5withRSA,ADH,DH,DHE,
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
Please suggest the way to restrict the TLSv1,TLSv1.1 version when
OpenSSLImplementation is used.
The code you are using should be suff
,
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
Please suggest the way to restrict the TLSv1,TLSv1.1 version when
OpenSSLImplementation is used.
Regards,
Natraj
-Original Message-
From: Mark Thomas
Sent: Thursday, Octo
On 14/10/2021 10:28, Natraj Thekkan wrote:
Hi,
We are using tomcat version 9.0.46.
Could you please provide suggestion to restrict the TLS version in HTTP2 over
HTTPS with OpenSSL implementation?.
The code below is sufficient, assuming that is then the connector that
is being used
Hi,
We are using tomcat version 9.0.46.
Could you please provide suggestion to restrict the TLS version in HTTP2 over
HTTPS with OpenSSL implementation?.
Regards,
Natraj
From: Natraj Thekkan
Sent: Wednesday, October 13, 2021 10:15 AM
To: 'users@tomcat.apache.org'
Subject: Restriction of TLS
1 - 100 of 1407 matches
Mail list logo
