RE: OpenSSL config for Tomcat 7
Below are the two connector configs I have tested with. -John -Original Message- From: Mark Thomas Sent: Saturday, February 29, 2020 2:12 AM To: users@tomcat.apache.org Subject: Re: OpenSSL config for Tomcat 7 On 29/02/2020 00:22, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) wrote: > Hello, > > We're running Tomcat 7 and need to implement SSL. We are using > APR/OpenSSL, but I can't get the intermediate certificates pulled in when > starting Tomcat. The server certificate is recognized and used but not the > other two. I have tried the following in PEM format. > > > * Stacking them in one file and using the "SSLCertificateFile" directive > * Using the "SSLCertificateFile" directive for the server cert, and > "SSLCertificateChainFile" directive for the CA and root cert > > > * APR 1.4.8 > * Tomcat 7.0.39 > > Any additional information needed please let me know. Any insight would be > greatly appreciated. The exact connector configuration you are using for each test case along with a description of how you created the files referenced in each configuration. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OpenSSL config for Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 3/2/20 12:26, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) wrote: > Yes, that is what I have done. Can you please post your actual configuration? Also, please list the order of certificates in your SSLCertificateFile file. Maybe: $ grep '===' [SSLCertificateFile].pem and post that? - -chris > -Original Message- From: Jason Wee > Sent: Friday, February 28, 2020 11:29 PM To: Tomcat Users List > Subject: Re: OpenSSL config for Tomcat 7 > > when you stack them, do you mean you cat those certificates into > one pem file? > > On Sat, Feb 29, 2020 at 8:22 AM John Beaulaurier -X (jbeaulau - > ADVANCED NETWORK INFORMATION INC at Cisco) > wrote: >> >> Hello, >> >> We're running Tomcat 7 and need to implement SSL. We are using >> APR/OpenSSL, but I can't get the intermediate certificates pulled >> in when starting Tomcat. The server certificate is recognized and >> used but not the other two. I have tried the following in PEM >> format. >> >> >> * Stacking them in one file and using the "SSLCertificateFile" >> directive * Using the "SSLCertificateFile" directive for the >> server cert, and "SSLCertificateChainFile" directive for the CA >> and root cert >> >> >> * APR 1.4.8 * Tomcat 7.0.39 >> >> Any additional information needed please let me know. Any insight >> would be greatly appreciated. >> >> Regards -John >> >> > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5dRI8ACgkQHPApP6U8 pFg/YxAAix8Mjs9gKydKDMJGra5ltPx1J7VuTMeFaLCp35QwxlqJL1iPMsN7fjpH A/BAItqlIS6qPmOOwfe5PQMyr1FlQn73heimddpAu6WyuzPcOK6cLSY9cmEVUsJg qQ5D/UmL0hqSDA3jcfoq7MvPU5GxvkK8QpHcnCOjFzVSd1XkZ3WqvTAkMN3JdJbM tGdYHTyukCgvVcK0PtwGQvfOkxxFw/NaYJfzb0ka1D9Qt18OGQpEeZgJK48m72qN 0L681QG2grQZju50FZv+GCFLbNxBBfL1xV80B+q8+hzMc04T8s0HsVjtLJCAq08X +mrwt7RcGPW/1nQLNI+JRzR0a1Epd0R9mZRTZQYUpSsGliOFucPqgCL33R2zCukm /4X0ILEb73fGOfrzS9WhGJ18133jSCLAfrkW2zl0FfPTbliCw03kGOxcwOdbeY+w jt0W3+KISWGZXUj0hSCgvASH10mNRVKxNioPgHX7LMSG0eAoHpj6+wClRM4FX9ca 3kf10sI0kX13D2gVjFyaAQXnLogUmNRrd75HtXNFZ0PcGoNQIzSemm/8crVxUHKI jyWBaEpdRqX9H76D8YWaBwa7BaDYaU4amWB0jpGmcaUYTeoRW0w5KA4sOn7Q0ksV KNIDj1KkOM71kSskHoB04923ns/TF1jlQsZzMUioiAtMalctwRI= =rtZu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Proposal: Note on web site that Tomcat 10 is a milestone-release
And when you are at it, also mention there in big letters that they really should read the release notes... This tomcat will not work with all the major frameworks people use for quite some time... Op ma 2 mrt. 2020 18:23 schreef Christopher Schultz < ch...@christopherschultz.net>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All, > > If you go to tomcat.apache.org right now, you'll see documentation and > downloads for Tomcat 10. In the news section, it's shown as 10.0.0-M1 > so that might be an indication that it's not a "normal" release. > > Anyone going to the site and not reading the (current) top-item of > news might think that Tomcat 10 is the current best version to download. > > I propose the following: > > 1. Add a [beta] (or similar) badge to the [Tomcat 10] download and > [Tomcat 10.0] documentation links. > > 2. On the "which version" page, add a [beta] (or similar) badge to the > Tomcat 10 release > > 3. On the Tomcat 10 downloads page, in the summary section, add a very > prominent statement that says Tomcat 10 is in [beta] or similar. I > might even use a large font and/or red or some other > attention-grabbing text color. > > 4. Similar to [3] above, but on the Tomcat 10 documentation page > introduction. > > WDYT? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5dQOkACgkQHPApP6U8 > pFglHA//XKKCS260Hvx+gA5YshiPYOpKS7FOG/bDzef9Y+JqMpuFMrOt/7d2AG2/ > X7GqQ57mJ+aew5p+nncXWV5yXd3fGyhPCeDsdF5pNc3K87dYs0MZCt/5nB9D2mJK > 3uoRQjQscwo2pBuozpBViw19HoeoEjQGWHWrs60LTckODDQj1IcT6zZUgckGkMaP > sPu1x+kra+5psKWtK91S6KOERoYQ13gNhIAIlEgCavLzwOoyz3El5/9iXne2rP/w > tePV+1e9r7ltF6WBJtA72xMAS1mXvK+bW1Wpm/5dMicpnRF04vaOUlZularWgbvO > 8p67YCJ3keaVtKcfDVHxSUVUUbjroWX9beoOnTDujw6zUapoKzibtU9EEyEOQXIW > C946ZhyPjS6I+liRHGQHKkQgBMUpHC+WGmasC5RW6+hySJCTjp6TGKlr5vuDk0th > OtcuHgzaOoqqVjYOZwArQi96c0l5/RW/6wxseunvK5n8TzP/l3F5jP627dUodsWV > B1qQfP3aePMGaTnRDuookTBoS1FLANc2Fc0m6hpTJmVkgcrYSFo4vmlljSGUCSkB > rUzY10W3rLu467ipcoFEzMGgVmM0cO29qk35JqPj0DtZa5BbFQTQa95iERxnRx45 > izIC7Nz5+UUdjdcoMhIVMdq/oA1TC++MXpRMOoYlOpnOf7hT+yo= > =nLsr > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: OpenSSL config for Tomcat 7
Yes, that is what I have done. -Original Message- From: Jason Wee Sent: Friday, February 28, 2020 11:29 PM To: Tomcat Users List Subject: Re: OpenSSL config for Tomcat 7 when you stack them, do you mean you cat those certificates into one pem file? On Sat, Feb 29, 2020 at 8:22 AM John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) wrote: > > Hello, > > We're running Tomcat 7 and need to implement SSL. We are using > APR/OpenSSL, but I can't get the intermediate certificates pulled in when > starting Tomcat. The server certificate is recognized and used but not the > other two. I have tried the following in PEM format. > > > * Stacking them in one file and using the "SSLCertificateFile" directive > * Using the "SSLCertificateFile" directive for the server cert, and > "SSLCertificateChainFile" directive for the CA and root cert > > > * APR 1.4.8 > * Tomcat 7.0.39 > > Any additional information needed please let me know. Any insight would be > greatly appreciated. > > Regards > -John > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Proposal: Note on web site that Tomcat 10 is a milestone-release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, If you go to tomcat.apache.org right now, you'll see documentation and downloads for Tomcat 10. In the news section, it's shown as 10.0.0-M1 so that might be an indication that it's not a "normal" release. Anyone going to the site and not reading the (current) top-item of news might think that Tomcat 10 is the current best version to download. I propose the following: 1. Add a [beta] (or similar) badge to the [Tomcat 10] download and [Tomcat 10.0] documentation links. 2. On the "which version" page, add a [beta] (or similar) badge to the Tomcat 10 release 3. On the Tomcat 10 downloads page, in the summary section, add a very prominent statement that says Tomcat 10 is in [beta] or similar. I might even use a large font and/or red or some other attention-grabbing text color. 4. Similar to [3] above, but on the Tomcat 10 documentation page introduction. WDYT? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5dQOkACgkQHPApP6U8 pFglHA//XKKCS260Hvx+gA5YshiPYOpKS7FOG/bDzef9Y+JqMpuFMrOt/7d2AG2/ X7GqQ57mJ+aew5p+nncXWV5yXd3fGyhPCeDsdF5pNc3K87dYs0MZCt/5nB9D2mJK 3uoRQjQscwo2pBuozpBViw19HoeoEjQGWHWrs60LTckODDQj1IcT6zZUgckGkMaP sPu1x+kra+5psKWtK91S6KOERoYQ13gNhIAIlEgCavLzwOoyz3El5/9iXne2rP/w tePV+1e9r7ltF6WBJtA72xMAS1mXvK+bW1Wpm/5dMicpnRF04vaOUlZularWgbvO 8p67YCJ3keaVtKcfDVHxSUVUUbjroWX9beoOnTDujw6zUapoKzibtU9EEyEOQXIW C946ZhyPjS6I+liRHGQHKkQgBMUpHC+WGmasC5RW6+hySJCTjp6TGKlr5vuDk0th OtcuHgzaOoqqVjYOZwArQi96c0l5/RW/6wxseunvK5n8TzP/l3F5jP627dUodsWV B1qQfP3aePMGaTnRDuookTBoS1FLANc2Fc0m6hpTJmVkgcrYSFo4vmlljSGUCSkB rUzY10W3rLu467ipcoFEzMGgVmM0cO29qk35JqPj0DtZa5BbFQTQa95iERxnRx45 izIC7Nz5+UUdjdcoMhIVMdq/oA1TC++MXpRMOoYlOpnOf7hT+yo= =nLsr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 10.0.0-M1 can't get JSP taglib to work
Thanks Mark -Original Message- From: Mark Thomas Sent: Monday, March 2, 2020 12:11 PM To: users@tomcat.apache.org Subject: Re: Tomcat 10.0.0-M1 can't get JSP taglib to work On 02/03/2020 14:49, e...@wolfecomputerservices.com wrote: > Thanks for the reply Mark! > > Well, that stinks! It is new development and so it would only make > sense to use the latest server; however, if it is a step backward in > functionality (because supporting libraries are not available) then I > guess I'll have to use the previous version. Jakarta EE 9 is still in development - hence why the Tomcat 10 release is a Milestone. It isn't a given that libraries written to the Java EE 8 APIs will be updated for the Jakarta EE 9. If Jakarta EE 9 versions of libraries are not available then there are a couple of options: 1. Convert an existing JAR written for Java EE 8 to Jakarta EE 9 using the migration tool the Tomcat team has written for that purpose. 2. Stick with Tomcat 9. We will be producing versions of Tomcat (9.10.x, 9.11.x etc) that align with Tomcat 10, Tomcat 11, etc. apart from the fact they will continue to support the Java EE 8 APIs so there is an upgrade path for newer Tomcat functionality while retaining Java EE 8 compatibility, Mark > > -Original Message- > From: Mark Thomas > Sent: Monday, March 2, 2020 9:34 AM > To: users@tomcat.apache.org > Subject: Re: Tomcat 10.0.0-M1 can't get JSP taglib to work > > On 02/03/2020 14:16, e...@wolfecomputerservices.com wrote: >> I have tried everything in the multiple threads on this site (non of >> them were for Tomcat 10 and non of the solved problem. I am using >> Apache NetBeans 11.1 with Apache Tomcat 10.0.0-M1. Below is my >> configuration -- if I remove the taglib line from my jsp file, the >> error > goes away. > > From the Tomcat 10.0.0-M1 release announcement: > > > Users of Tomcat 10 onwards should be aware that, as a result of the > move from Java EE to Jakarta EE as part of the transfer of Java EE to > the Eclipse Foundation, the primary package for all implemented APIs > has changed from > javax.* to jakarta.*. This will almost certainly require code changes > to enable applications to migrate from Tomcat 9 and earlier to Tomcat > 10 and later. > > > >> >> >> javax >> >> javaee-web-api >> >> 8.0.1 >> >> provided >> >> > > That is never going to work on Tomact 10. You can't use Java EE 8 > libraries with a Jakarta EE 9 server. > >> >> >> javax.mail >> >> mail >> >> 1.4.7 >> >> jar >> >> > > That needs to be replaced with Jakarta Mail (there might be an RC for > that on Maven Central) > >> >> >> >> org.springframework >> >> spring-web >> >> 5.1.10.RELEASE >> >> > > That won't work and, as far as I am aware, there is no Jakarta EE 9 > version available (or even being worked on) yet. > >> >> >> javax.servlet >> >> jstl >> >> 1.2 >> >> >> >> > > You need the Jakarta Standard Tag Library 2.0 or later. I think that > is one of the Jakarta projects struggling for active committers. > > Tomcat 10 ships with an API and implementation for the Jakarta > Standard Tag Library 2.0 in the examples web application. It was > created by taking the JSTL 1.2 JARs and running them through Tomcat's > Java EE 8 to Jakarta EE 9 conversion / migration tool. > >> test.jsp > > > > Might sticking with Tomcat 9 be a better option for you for now? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 10.0.0-M1 can't get JSP taglib to work
On 02/03/2020 14:49, e...@wolfecomputerservices.com wrote: > Thanks for the reply Mark! > > Well, that stinks! It is new development and so it would only make sense to > use the latest server; however, if it is a step backward in functionality > (because supporting libraries are not available) then I guess I'll have to > use the previous version. Jakarta EE 9 is still in development - hence why the Tomcat 10 release is a Milestone. It isn't a given that libraries written to the Java EE 8 APIs will be updated for the Jakarta EE 9. If Jakarta EE 9 versions of libraries are not available then there are a couple of options: 1. Convert an existing JAR written for Java EE 8 to Jakarta EE 9 using the migration tool the Tomcat team has written for that purpose. 2. Stick with Tomcat 9. We will be producing versions of Tomcat (9.10.x, 9.11.x etc) that align with Tomcat 10, Tomcat 11, etc. apart from the fact they will continue to support the Java EE 8 APIs so there is an upgrade path for newer Tomcat functionality while retaining Java EE 8 compatibility, Mark > > -Original Message- > From: Mark Thomas > Sent: Monday, March 2, 2020 9:34 AM > To: users@tomcat.apache.org > Subject: Re: Tomcat 10.0.0-M1 can't get JSP taglib to work > > On 02/03/2020 14:16, e...@wolfecomputerservices.com wrote: >> I have tried everything in the multiple threads on this site (non of >> them were for Tomcat 10 and non of the solved problem. I am using >> Apache NetBeans 11.1 with Apache Tomcat 10.0.0-M1. Below is my >> configuration -- if I remove the taglib line from my jsp file, the error > goes away. > > From the Tomcat 10.0.0-M1 release announcement: > > > Users of Tomcat 10 onwards should be aware that, as a result of the move > from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse > Foundation, the primary package for all implemented APIs has changed from > javax.* to jakarta.*. This will almost certainly require code changes to > enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and > later. > > > >> >> >> javax >> >> javaee-web-api >> >> 8.0.1 >> >> provided >> >> > > That is never going to work on Tomact 10. You can't use Java EE 8 libraries > with a Jakarta EE 9 server. > >> >> >> javax.mail >> >> mail >> >> 1.4.7 >> >> jar >> >> > > That needs to be replaced with Jakarta Mail (there might be an RC for that > on Maven Central) > >> >> >> >> org.springframework >> >> spring-web >> >> 5.1.10.RELEASE >> >> > > That won't work and, as far as I am aware, there is no Jakarta EE 9 version > available (or even being worked on) yet. > >> >> >> javax.servlet >> >> jstl >> >> 1.2 >> >> >> >> > > You need the Jakarta Standard Tag Library 2.0 or later. I think that is one > of the Jakarta projects struggling for active committers. > > Tomcat 10 ships with an API and implementation for the Jakarta Standard Tag > Library 2.0 in the examples web application. It was created by taking the > JSTL 1.2 JARs and running them through Tomcat's Java EE 8 to Jakarta EE 9 > conversion / migration tool. > >> test.jsp > > > > Might sticking with Tomcat 9 be a better option for you for now? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 10.0.0-M1 can't get JSP taglib to work
Thanks for the reply Mark! Well, that stinks! It is new development and so it would only make sense to use the latest server; however, if it is a step backward in functionality (because supporting libraries are not available) then I guess I'll have to use the previous version. -Original Message- From: Mark Thomas Sent: Monday, March 2, 2020 9:34 AM To: users@tomcat.apache.org Subject: Re: Tomcat 10.0.0-M1 can't get JSP taglib to work On 02/03/2020 14:16, e...@wolfecomputerservices.com wrote: > I have tried everything in the multiple threads on this site (non of > them were for Tomcat 10 and non of the solved problem. I am using > Apache NetBeans 11.1 with Apache Tomcat 10.0.0-M1. Below is my > configuration -- if I remove the taglib line from my jsp file, the error goes away. >From the Tomcat 10.0.0-M1 release announcement: Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later. > > > javax > > javaee-web-api > > 8.0.1 > > provided > > That is never going to work on Tomact 10. You can't use Java EE 8 libraries with a Jakarta EE 9 server. > > > javax.mail > > mail > > 1.4.7 > > jar > > That needs to be replaced with Jakarta Mail (there might be an RC for that on Maven Central) > > > > org.springframework > > spring-web > > 5.1.10.RELEASE > > That won't work and, as far as I am aware, there is no Jakarta EE 9 version available (or even being worked on) yet. > > > javax.servlet > > jstl > > 1.2 > > > > You need the Jakarta Standard Tag Library 2.0 or later. I think that is one of the Jakarta projects struggling for active committers. Tomcat 10 ships with an API and implementation for the Jakarta Standard Tag Library 2.0 in the examples web application. It was created by taking the JSTL 1.2 JARs and running them through Tomcat's Java EE 8 to Jakarta EE 9 conversion / migration tool. > test.jsp Might sticking with Tomcat 9 be a better option for you for now? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 10.0.0-M1 can't get JSP taglib to work
On 02/03/2020 14:16, e...@wolfecomputerservices.com wrote: > I have tried everything in the multiple threads on this site (non of them > were for Tomcat 10 and non of the solved problem. I am using Apache > NetBeans 11.1 with Apache Tomcat 10.0.0-M1. Below is my configuration -- if > I remove the taglib line from my jsp file, the error goes away. >From the Tomcat 10.0.0-M1 release announcement: Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later. > > > javax > > javaee-web-api > > 8.0.1 > > provided > > That is never going to work on Tomact 10. You can't use Java EE 8 libraries with a Jakarta EE 9 server. > > > javax.mail > > mail > > 1.4.7 > > jar > > That needs to be replaced with Jakarta Mail (there might be an RC for that on Maven Central) > > > > org.springframework > > spring-web > > 5.1.10.RELEASE > > That won't work and, as far as I am aware, there is no Jakarta EE 9 version available (or even being worked on) yet. > > > javax.servlet > > jstl > > 1.2 > > > > You need the Jakarta Standard Tag Library 2.0 or later. I think that is one of the Jakarta projects struggling for active committers. Tomcat 10 ships with an API and implementation for the Jakarta Standard Tag Library 2.0 in the examples web application. It was created by taking the JSTL 1.2 JARs and running them through Tomcat's Java EE 8 to Jakarta EE 9 conversion / migration tool. > test.jsp Might sticking with Tomcat 9 be a better option for you for now? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 10.0.0-M1 can't get JSP taglib to work
I have tried everything in the multiple threads on this site (non of them were for Tomcat 10 and non of the solved problem. I am using Apache NetBeans 11.1 with Apache Tomcat 10.0.0-M1. Below is my configuration -- if I remove the taglib line from my jsp file, the error goes away. web.xml: http://xmlns.jcp.org/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"; version="4.0"> pom.xml dependencies: javax javaee-web-api 8.0.1 provided com.google.code.gson gson 2.8.5 org.json json 20190722 javax.mail mail 1.4.7 jar com.zaxxer HikariCP 3.3.1 compile org.springframework spring-context 5.1.10.RELEASE org.springframework spring-web 5.1.10.RELEASE javax.servlet jstl 1.2 test.jsp <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> <%@page contentType="text/html" pageEncoding="UTF-8"%> JSP Page Test Results error displayed: org.apache.jasper.JasperException: The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be resolved in either web.xml or the jar files deployed with this application org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler. java:55) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:294 ) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:81) org.apache.jasper.compiler.TagLibraryInfoImpl.generateTldResourcePath(TagLib raryInfoImpl.java:251) org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java :122) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:431) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:489) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1445) org.apache.jasper.compiler.Parser.parse(Parser.java:144) org.apache.jasper.compiler.ParserController.doParse(ParserController.java:24 4) org.apache.jasper.compiler.ParserController.parse(ParserController.java:105) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:206) org.apache.jasper.compiler.Compiler.compile(Compiler.java:386) org.apache.jasper.compiler.Compiler.compile(Compiler.java:362) org.apache.jasper.compiler.Compiler.compile(Compiler.java:346) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:6 05) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:4 00) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) jakarta.servlet.http.HttpServlet.service(HttpServlet.java:741) org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:9 55) org.apache.jsp.index_jsp._jspService(index_jsp.java:128) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:71) jakarta.servlet.http.HttpServlet.service(HttpServlet.java:741) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:4 77) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) jakarta.servlet.http.HttpServlet.service(HttpServlet.java:741) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
Re: Client cert auth on demand
My bad - I was looking in the catalina log, not the localhost log...
Now I see the config being parsed:
01-Mar-2020 21:12:49.147 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.startInternal Read
configuration from: /WEB-INF/rewrite.config
01-Mar-2020 21:12:49.155 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.parse Add rule with
pattern ^(.*)(localhost\%3A5443)(.*)$ and substitution $1localhost$3
01-Mar-2020 21:12:49.155 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.parse Add condition
localhost%3A5443 test %{QUERY_STRING} to rule with pattern
^(.*)(localhost\%3A5443)(.*)$ and substitution $1localhost$3
On Mon, Mar 2, 2020 at 11:51 AM Martynas Jusevičius
wrote:
>
> No matter where I place the rewrite.config, cannot get the
> RewriteValve to find it.
>
> I tried:
> * /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml and
> /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
> * /usr/local/tomcat/conf/context.xml and
> /usr/local/tomcat/conf/localhost/rewrite.config
>
> The only log output I get is:
>
> 01-Mar-2020 18:45:50.647 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [INITIALIZING]
> 01-Mar-2020 18:45:50.650 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [INITIALIZED]
> 01-Mar-2020 18:45:50.651 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [STARTING_PREP]
> 01-Mar-2020 18:45:50.652 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTING]
> 01-Mar-2020 18:45:50.654 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTED]
>
>
>
> On Sun, Mar 1, 2020 at 2:15 PM Martynas Jusevičius
> wrote:
> >
> > I hit a snag with the query string. In some cases it contains the
> > webapp base URI in a query parameter, such as:
> >
> >
> > /admin/acl/authorizations/?forClass=https%3A//localhost%3A5443/admin/ns%23Authorization
> >
> > So I'm trying to rewrite those as well, from
> > https%3A//localhost%3A5443/ to https%3A//localhost/ (remove the port
> > number).
> >
> > RewriteValve seems to do what I need:
> > https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
> >
> > I have mounted the following under
> > /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
> >
> >
> >
> >
> >
> >
> > and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
> >
> > RewriteCond %{QUERY_STRING} localhost%3A5443
> > RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
> >
> > However I'm not seeing any output re. RewriteValve in the Tomcat log.
> > The rewrite is not happening and it doesn't look like the config is
> > even read.
> >
> > On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
> > wrote:
> > >
> > > Thanks! I actually needed proxyPort="443" to make the URL
> > > https://localhost, but your suggestion did the trick.
> > >
> > > On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas wrote:
> > > >
> > > >
> > > >
> > > > On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > > > > Yes the clients connect only directly to nginx.
> > > > >
> > > > > So the proxy config within 2 pairs of containers is like this:
> > > > >
> > > > > # website service; clientAuth=false
> > > > > nginx:80 -> tomcat:8080
> > > > > nginx:443 -> tomcat:8443
> > > > >
> > > > > # API service; clientAuth=true
> > > > > nginx-api:90 -> tomcat-api:8080
> > > > > nginx-api:5443 -> tomcat-api:8443
> > > >
> > > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > > > instance. That should do the trick.
> > > >
> > > > Mark
> > > >
> > > >
> > > > >
> > > > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > > > where the clients access them, therefore the host name the webapp sees
> > > > > is localhost (as in my rewrite example).
> > > > >
> > > > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > > > thinking it's being accessed on localhost:80/443 instead of
> > > > > localhost:90/5443.
> > > > >
> > > > > Absolute URIs matter in this case because they are used for direct
> > > > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > > > >
> > > > >
> > > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote:
> > > > >>
> > > > >> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> > > > >>> Setting up a second container with a different port was easy enough.
> > > > >>>
> > > > >>> However I got stuck on the URL mapping/rewriting. Using nginx as a
> > > > >>> proxy, I don't
Re: Client cert auth on demand
No matter where I place the rewrite.config, cannot get the
RewriteValve to find it.
I tried:
* /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml and
/usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
* /usr/local/tomcat/conf/context.xml and
/usr/local/tomcat/conf/localhost/rewrite.config
The only log output I get is:
01-Mar-2020 18:45:50.647 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[INITIALIZING]
01-Mar-2020 18:45:50.650 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[INITIALIZED]
01-Mar-2020 18:45:50.651 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[STARTING_PREP]
01-Mar-2020 18:45:50.652 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTING]
01-Mar-2020 18:45:50.654 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTED]
On Sun, Mar 1, 2020 at 2:15 PM Martynas Jusevičius
wrote:
>
> I hit a snag with the query string. In some cases it contains the
> webapp base URI in a query parameter, such as:
>
>
> /admin/acl/authorizations/?forClass=https%3A//localhost%3A5443/admin/ns%23Authorization
>
> So I'm trying to rewrite those as well, from
> https%3A//localhost%3A5443/ to https%3A//localhost/ (remove the port
> number).
>
> RewriteValve seems to do what I need:
> https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
>
> I have mounted the following under
> /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
>
>
>
>
>
>
> and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
>
> RewriteCond %{QUERY_STRING} localhost%3A5443
> RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
>
> However I'm not seeing any output re. RewriteValve in the Tomcat log.
> The rewrite is not happening and it doesn't look like the config is
> even read.
>
> On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
> wrote:
> >
> > Thanks! I actually needed proxyPort="443" to make the URL
> > https://localhost, but your suggestion did the trick.
> >
> > On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas wrote:
> > >
> > >
> > >
> > > On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > > > Yes the clients connect only directly to nginx.
> > > >
> > > > So the proxy config within 2 pairs of containers is like this:
> > > >
> > > > # website service; clientAuth=false
> > > > nginx:80 -> tomcat:8080
> > > > nginx:443 -> tomcat:8443
> > > >
> > > > # API service; clientAuth=true
> > > > nginx-api:90 -> tomcat-api:8080
> > > > nginx-api:5443 -> tomcat-api:8443
> > >
> > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > > instance. That should do the trick.
> > >
> > > Mark
> > >
> > >
> > > >
> > > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > > where the clients access them, therefore the host name the webapp sees
> > > > is localhost (as in my rewrite example).
> > > >
> > > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > > thinking it's being accessed on localhost:80/443 instead of
> > > > localhost:90/5443.
> > > >
> > > > Absolute URIs matter in this case because they are used for direct
> > > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > > >
> > > >
> > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote:
> > > >>
> > > >> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> > > >>> Setting up a second container with a different port was easy enough.
> > > >>>
> > > >>> However I got stuck on the URL mapping/rewriting. Using nginx as a
> > > >>> proxy, I don't think it's possible to rewrite headers with the
> > > >>> upstream module:
> > > >>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> > > >>>
> > > >>> As I understand it just forwards raw traffic, so the URL rewriting
> > > >>> would have to be done on the Tomcat's side. Basically I want to
> > > >>> rewrite:
> > > >>>
> > > >>> https://localhost:5443/ => https://localhost/
> > > >>>
> > > >>> which requires rewriting the Host request header, I think.
> > > >>>
> > > >>> I was looking at the RewriteValve, but it says:
> > > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > > >>> automatically support absolute URLs (the specific redirect flag must
> > > >>> be used to be able to specify an absolute URLs, see below) or direct
> > > >>> file serving."
> > > >>>
> > > >>> Is there a way to rewrite the hostname/port in configuration?
> > > >>> Something placed in context.xml would be ideal.
> > > >>
> > > >>
> > > >> What port is n
[ANN] End of life for Apache Tomcat 7.0.x
The Apache Tomcat team announces that support for Apache Tomcat 7.0.x will end on 31 March 2021. This means that after 31 March 2021: - releases from the 7.0.x branch are highly unlikely - bugs affecting only the 7.0.x branch will not be addressed - security vulnerability reports will not be checked against the 7.0.x branch Three months later (i.e. after 30 June 2021) - the 7.0.x download pages will be removed - the latest 7.0.x release will be removed from the mirror system - the 7.0.x branch will be made read-only - the links to the 7.0.x documentation will be removed from tomcat.apache.org - The bugzilla project for 7.0.x will be made read-only Note that all 7.0.x releases will always be available from the archive. It is anticipated that the final 7.0.x release will be made shortly before 31 March 2021. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution
On 02/03/2020 10:12, js84 wrote: > Hello! > > Proposed work-arounds don’t cover possible vulnerability over a reverse proxy: Correct. > Can an attacker abuse AJP vulnerability when access is mapped by mod_jk or > mod_proxy_ajp? No. Mark > > Kind regards, > Johann > > Von: Mark Thomas > Gesendet: Montag, 2. März 2020 10:11 > An: users@tomcat.apache.org > Betreff: Re: [SECURITY] CVE-2020-1938 AJP Request Injection and > potentialRemote Code Execution > > On 01/03/2020 23:34, Stefan Mayr wrote: >> Am 24.02.2020 um 13:47 schrieb Mark Thomas: >>> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution >>> >>> Severity: High >>> >>> ... >>> - returning arbitrary files from anywhere in the web application >>> including under the WEB-INF and META-INF directories or any other >>> location reachable via ServletContext.getResourceAsStream() >>> - processing any file in the web application as a JSP >>> Further, if the web application allowed file upload and stored those >>> files within the web application (or the attacker was able to control >>> the content of the web application by some other means) then this, along >>> with the ability to process a file as a JSP, made remote code execution >>> possible. >> >> Is this a bug which is or will be fixed or is this a fundamental design >> flaw of AJP which cannot be fixed? So to trust or not to trust are the >> only options? > > Not really. > > The ability for an AJP client to obtain arbitrary files from the web > application has been blocked by default. > > The ability for an AJP client to trigger the processing of any file from > the web application as a JSP has been blocked by default. > > The above two points are, essentially, CVE-2020-1928. > > If the web application depends on knowing the true user IP address then > Tomcat has to trust the AJP client to provide that data. > > If the web application depends on the reverse proxy (the AJP client) > performing authentication and passing the authenticated identify to > Tomcat then Tomcat has to trust that the reverse proxy does this correctly. > > And so on for all the other user information that the AJP protocol can > pass to Tomcat. > > How Tomcat decides to trust the AJP client is a decision for the system > administrator. Options include: > > - have the AJP Connector listen on a non-public IP address that only the > reverse proxy can access > - use firewall rules to limit connections to the AJP port to trusted > hosts > - configure a shared secret in the reverse proxy and the AJP Connector > > Mark > > > > >> >> Thanks, >> >> Stefan Mayr >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution
Hello! Proposed work-arounds don’t cover possible vulnerability over a reverse proxy: Can an attacker abuse AJP vulnerability when access is mapped by mod_jk or mod_proxy_ajp? Kind regards, Johann Von: Mark Thomas Gesendet: Montag, 2. März 2020 10:11 An: users@tomcat.apache.org Betreff: Re: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution On 01/03/2020 23:34, Stefan Mayr wrote: > Am 24.02.2020 um 13:47 schrieb Mark Thomas: >> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution >> >> Severity: High >> >> ... >> - returning arbitrary files from anywhere in the web application >> including under the WEB-INF and META-INF directories or any other >> location reachable via ServletContext.getResourceAsStream() >> - processing any file in the web application as a JSP >> Further, if the web application allowed file upload and stored those >> files within the web application (or the attacker was able to control >> the content of the web application by some other means) then this, along >> with the ability to process a file as a JSP, made remote code execution >> possible. > > Is this a bug which is or will be fixed or is this a fundamental design > flaw of AJP which cannot be fixed? So to trust or not to trust are the > only options? Not really. The ability for an AJP client to obtain arbitrary files from the web application has been blocked by default. The ability for an AJP client to trigger the processing of any file from the web application as a JSP has been blocked by default. The above two points are, essentially, CVE-2020-1928. If the web application depends on knowing the true user IP address then Tomcat has to trust the AJP client to provide that data. If the web application depends on the reverse proxy (the AJP client) performing authentication and passing the authenticated identify to Tomcat then Tomcat has to trust that the reverse proxy does this correctly. And so on for all the other user information that the AJP protocol can pass to Tomcat. How Tomcat decides to trust the AJP client is a decision for the system administrator. Options include: - have the AJP Connector listen on a non-public IP address that only the reverse proxy can access - use firewall rules to limit connections to the AJP port to trusted hosts - configure a shared secret in the reverse proxy and the AJP Connector Mark > > Thanks, > > Stefan Mayr > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution
Hello! Proposed work-arounds don’t cover possible vulnerability over a reverse proxy: Can an attacker abuse AJP vulnerability when access is mapped by mod_jk or mod_proxy_ajp? Kind regards, Johann Von: Mark Thomas Gesendet: Montag, 2. März 2020 10:11 An: users@tomcat.apache.org Betreff: Re: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution On 01/03/2020 23:34, Stefan Mayr wrote: > Am 24.02.2020 um 13:47 schrieb Mark Thomas: >> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution >> >> Severity: High >> >> ... >> - returning arbitrary files from anywhere in the web application >> including under the WEB-INF and META-INF directories or any other >> location reachable via ServletContext.getResourceAsStream() >> - processing any file in the web application as a JSP >> Further, if the web application allowed file upload and stored those >> files within the web application (or the attacker was able to control >> the content of the web application by some other means) then this, along >> with the ability to process a file as a JSP, made remote code execution >> possible. > > Is this a bug which is or will be fixed or is this a fundamental design > flaw of AJP which cannot be fixed? So to trust or not to trust are the > only options? Not really. The ability for an AJP client to obtain arbitrary files from the web application has been blocked by default. The ability for an AJP client to trigger the processing of any file from the web application as a JSP has been blocked by default. The above two points are, essentially, CVE-2020-1928. If the web application depends on knowing the true user IP address then Tomcat has to trust the AJP client to provide that data. If the web application depends on the reverse proxy (the AJP client) performing authentication and passing the authenticated identify to Tomcat then Tomcat has to trust that the reverse proxy does this correctly. And so on for all the other user information that the AJP protocol can pass to Tomcat. How Tomcat decides to trust the AJP client is a decision for the system administrator. Options include: - have the AJP Connector listen on a non-public IP address that only the reverse proxy can access - use firewall rules to limit connections to the AJP port to trusted hosts - configure a shared secret in the reverse proxy and the AJP Connector Mark > > Thanks, > > Stefan Mayr > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2020-1938 AJP Request Injection and potential Remote Code Execution
On 01/03/2020 23:34, Stefan Mayr wrote: > Am 24.02.2020 um 13:47 schrieb Mark Thomas: >> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution >> >> Severity: High >> >> ... >> - returning arbitrary files from anywhere in the web application >> including under the WEB-INF and META-INF directories or any other >> location reachable via ServletContext.getResourceAsStream() >> - processing any file in the web application as a JSP >> Further, if the web application allowed file upload and stored those >> files within the web application (or the attacker was able to control >> the content of the web application by some other means) then this, along >> with the ability to process a file as a JSP, made remote code execution >> possible. > > Is this a bug which is or will be fixed or is this a fundamental design > flaw of AJP which cannot be fixed? So to trust or not to trust are the > only options? Not really. The ability for an AJP client to obtain arbitrary files from the web application has been blocked by default. The ability for an AJP client to trigger the processing of any file from the web application as a JSP has been blocked by default. The above two points are, essentially, CVE-2020-1928. If the web application depends on knowing the true user IP address then Tomcat has to trust the AJP client to provide that data. If the web application depends on the reverse proxy (the AJP client) performing authentication and passing the authenticated identify to Tomcat then Tomcat has to trust that the reverse proxy does this correctly. And so on for all the other user information that the AJP protocol can pass to Tomcat. How Tomcat decides to trust the AJP client is a decision for the system administrator. Options include: - have the AJP Connector listen on a non-public IP address that only the reverse proxy can access - use firewall rules to limit connections to the AJP port to trusted hosts - configure a shared secret in the reverse proxy and the AJP Connector Mark > > Thanks, > > Stefan Mayr > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: issue faced in tomcat 8.5.51
On 02.03.2020 07:38, Rathore, Rajendra wrote: Hi Calder/Team, I set the below flag as false but still it will giving the same error. If you really changed that attribute in the right place, and you restarted tomcat, it is quite unlikely that you would have the same error in the log. But if you really do, could you please copy the latest Connector configuration here, and another new extract of the log showing the error ? (Just copy/paste here please, not in an attachmemnt) I am using Apache http server(with AJP worker) and tomcat configuration, Is am I missing something in configuration, please let me know? Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: calder Sent: Friday, February 28, 2020 7:41 PM To: Tomcat Users List Subject: Re: issue faced in tomcat 8.5.51 External email from: users-return-269823-rarathore=ptc@tomcat.apache.org On Fri, Feb 28, 2020, 07:39 Rathore, Rajendra wrote: Hi Team, I am using below configuration in server.xml for tomcat but I got below exception in start up time < snip > Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid Please let me know what should I put to fix the issue, it will be very helpful for me. I am stuck because of the above issue, we are using Apache and tomcat for serving the request. Let me know if anything else required from my side. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
