Re: JVM keystores and CA

[Jose María Zaragoza]

Hi

El mar., 16 oct. 2018 a las 1:49, Igor Cicimov () escribió:
>
> Hi all,
>
> I just want to clarify something that I've been seeing behave differently
> on various Java versions during the years. In case we have the following
> setting:
>
> -Djavax.net.ssl.trustStore=/keystore/truststore.jks"
>
> in Tomcat's default config file, is JVM suppose to fall back to the global
> CA store on the server under /etc/ssl/certs for verification in case *any*
> of the certificates returned by a trusted domain are not present in the
> above JKS store? By any I mean, all the certs in the chain returned by the
> SSL handshake.
>
> For example, lets say we have a situation like this:
>
> DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 -> CN=*.mydomain.com
>
> Lets say I have imported the *CN=*.mydomain.com *
> certificate in the truststore.jks, the question is is JVM going to look
> under /etc/ssl/certs for RapidSSL in order to validate the CN signature and
> then for DigiCert to validate the RapidSSL cert?
>
> As I said I had a mixed luck with this over the years, sometimes it works
> as (I) expect it to work i.e. verify the certs by looking at the system CA
> store and sometimes this is not the case.

My experience is that if you store a server certificate in the
truststore.jks , don't search anyone more.
This behaviour makes sense for me because you are saying that you
trust in that certificate because you verified ( by other means ) it
before
Even if certificate is expired ( and server send it expired too,
obviously ) , I think that is validated as trusted

Regards






>
> Thanks for any help/insites.
>
> Igor

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

Re: WebSockets and JSPs

[Shawn Heisey]

On 10/15/2018 9:16 PM, Jerry Malcolm wrote:
I have several webapps that do a significant amount of recursive loads 
of snippits of HTML utilizing XHR/http/ajax requests. These apps are 
all debugged and in production.   The server has no problem whatsoever 
in keeping up with the multiple concurrent requests.  However, the 
open-connection limits on the browsers that block more than 6 
concurrent connections to a server is killing me in performance.


I know pretty much nothing about the things you asked about after this 
paragraph.  But I do know about one thing that might help you -- 
HTTP/2.  It can execute many HTTP requests simultaneously over a single 
TCP connection.


Here's a demo:

https://http2.akamai.com/demo

I really have no idea how to enable HTTP/2 in Tomcat, but I know that it 
can be done if you have a new enough version. Browsers with HTTP/2 
support should automatically multiplex requests to the same server over 
fewer connections.


Another possibility is to put your web services behind a load balancer 
that supports HTTP/2 on the front end.  Haproxy is one that I am aware 
of with that support.


HTTP/2 promises to obsolete many of the development and software tricks 
used in the past for improving web performance. Designing applications 
for performance has typically involved combining code into fewer files 
instead of aspiring to a highly modular application.  With HTTP/2, you 
can split things up without killing performance.


If anything I have said above is wrong, I would appreciate the community 
informing me about my errors.


Thanks,
Shawn


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

WebSockets and JSPs

[Jerry Malcolm]

I have several webapps that do a significant amount of recursive loads 
of snippits of HTML utilizing XHR/http/ajax requests. These apps are all 
debugged and in production.   The server has no problem whatsoever in 
keeping up with the multiple concurrent requests.  However, the 
open-connection limits on the browsers that block more than 6 concurrent 
connections to a server is killing me in performance.


I've been looking into WebSockets which I understand does not incur the 
wrath of the browsers when I have a need for more than 6 concurrent 
connections.   I have no problem making a move to WebSockets if that 
will indeed help performance.  However, I have literally many hundreds 
of JSPs that are coded, tested, and working.  So I'd like to minimize 
the rip-up to the JSPs.


I've googled around trying to find answers about how (if) I can invoke 
JSPs via WebSockets.  From what I can tell, it appears it's possible.  
But no straightforward explanation.   A WebSocket servlet extends 
"WebSocketServlet", correct?  But JSPs extend HTTPServlet, at least by 
default, correct.  So that seems like an fairly big immediate problem.


Do I need to do some gyrations like writing a WebSocket router servlet 
object that turns around and creates/invokes a normal http call to 
invoke the desired JSP?  (BTW... I don't need any of the bi-directional 
capabilities of WebSockets currently simply an "http emulator" 
functionality for now).


I guess I could get multiple IP addresses for the server and set up 
multiple secondary domain names to 'fool' the browsers into thinking the 
requests aren't all going to the same server thereby getting 6 requests 
per 'server'.  But at best that's a total hack, and not an inviting 
solution.


Any other suggestions (short of changing up the architecture to no 
longer require multiple concurrent loads)  will be welcomed. Likewise, 
and corrections to any errant assumptions I have made so far are also 
welcome.


Thx.

Jerry


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

JVM keystores and CA

[Igor Cicimov]

Hi all,

I just want to clarify something that I've been seeing behave differently
on various Java versions during the years. In case we have the following
setting:

-Djavax.net.ssl.trustStore=/keystore/truststore.jks"

in Tomcat's default config file, is JVM suppose to fall back to the global
CA store on the server under /etc/ssl/certs for verification in case *any*
of the certificates returned by a trusted domain are not present in the
above JKS store? By any I mean, all the certs in the chain returned by the
SSL handshake.

For example, lets say we have a situation like this:

DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 -> CN=*.mydomain.com

Lets say I have imported the *CN=*.mydomain.com *
certificate in the truststore.jks, the question is is JVM going to look
under /etc/ssl/certs for RapidSSL in order to validate the CN signature and
then for DigiCert to validate the RapidSSL cert?

As I said I had a mixed luck with this over the years, sometimes it works
as (I) expect it to work i.e. verify the certs by looking at the system CA
store and sometimes this is not the case.

Thanks for any help/insites.

Igor

Re: [OT] Oracle Java 11 discussion?

[Igal Sapir]

On 10/15/2018 11:37 AM, Mark Thomas wrote:

On 15/10/18 18:53, Berneburg, Cris J. - US wrote:

Hi Folks

What has anyone been thinking about the upcoming Oracle Java 11 release / 
support stuff?  Frankly,  I'm confused by it all and am still trying to wrap my 
brain around it.  I have concerns about the potential implications for my 
little project, and also wonder about Tomcat at large.

No JRE - huh?  How do we run Java apps w/o a Java runtime?  Wouldn't installing 
a JDK in production be kind of a security issue?  I can imagine security 
departments not being thrilled about that.  Does Tomcat support being run on an 
OpenJRE?

The argument for a JRE vs a JDK is that the JDK includes a compiler. The
only reason Tomcat can run on a JRE and still support JSPs (which
require compilation) is that Tomcat includes a Java compiler. I don't
think the security argument holds much water.

OpenJDK is very close to the Oracle JDK these days. I regularly run
Tomcat's unit tests with the latest OpenJDK and have yet to find an
issue that is OpenJDK specific.


I asked Gil Tene about this a couple of weeks ago.  Gil is a co-founder 
of Azul Systems, an OpenJDK committer, and on the Executive Committee of 
the JCP.  My understanding from him is that there is no JDK development 
outside of the OpenJDK.  The Oracle developers that work on the JDK 
commit directly to OpenJDK.  Oracle might add some other things when 
they package their edition of the JDK for distribution, but the JDK 
itself is the same one from OpenJDK.


The main problem with the rapid release cycle and six month support is 
that due to late adoption, many of the bugs in a given Java release are 
only discovered after more than six months of the release date.  That 
means that the free support will end while bugs and vulnerabilities are 
being discovered, forcing many organizations to pay for support.


Azul Systems provide their own packaging of the OpenJDK, under the name 
Azul Zulu [1].  They offer a longer support than the Oracle one, and add 
a Medium Term Support period.  I've been planning to test it out but 
haven't gotten a chance to do so yet.



Tomcat runs happily (and is supported) on a JRE.

If the JRE has passed the Java TCK then Tomcat should run on it. I don't
think there is an official Tomcat position but my expectation is if a
Tomcat bug (as opposed to a Java bug) appears when running on any Java
implementation that has passed the TCK then the Tomcat team would treat
that as a Tomcat bug and fix it. The caveat is that any such fix is a
lot easier if we have access to that particular version of Java and a
platform to run it on.


Are there any implications for Tomcat?

Not directly. Jakarta EE will need to make a decision about minimum Java
versions and the like for the next round of spec updates. I expect
they'll settle on Java 11 but that discussion hasn't really started yet.

I'd be more concerned that Oracle are starting to charge for production
usage. That alone would be enough for me to switch to OpenJDK.

I haven't yet got around to installing a Java 11 GA release. I'm still
using one of the final EA releases. I'm currently intending to only
install OpenJDK for Java 11 onwards. I'm not expecting this to cause me
any issues.


+1




I am imagining spending all my time being taken up by Java upgrades with 
subsequent builds, regression testing, red tape, and deployments, without 
delivering any actual new value to our customer.  :-\

I'd plan to stick to the LTS releases.


+1

Igal

[1] https://www.azul.com/downloads/zulu/


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

Re: [OT] Oracle Java 11 discussion?

[Johan Compagner]

Op ma 15 okt. 2018 20:37 schreef Mark Thomas :

>
>
> I'd be more concerned that Oracle are starting to charge for production
> usage. That alone would be enough for me to switch to OpenJDK.
>

Isnt that already the case?

You can't download any installer of java 11 from Oracle that can be used in
production, only for development and demos

There is no jre at all any more also from openjdk

And open jdk doesnt have an installer at all, so it is all up to the
package managers to get it (rpm/yum) so good luck on Windows with that
(There is really just unzipping and setting paths you're self)

Java on the desktop is really dead now (and we have quite a few customers
using that through webstart)

Johan


>

Re: [OT] Oracle Java 11 discussion?

[Mark Thomas]

On 15/10/18 18:53, Berneburg, Cris J. - US wrote:
> Hi Folks
> 
> What has anyone been thinking about the upcoming Oracle Java 11 release / 
> support stuff?  Frankly,  I'm confused by it all and am still trying to wrap 
> my brain around it.  I have concerns about the potential implications for my 
> little project, and also wonder about Tomcat at large.
> 
> No JRE - huh?  How do we run Java apps w/o a Java runtime?  Wouldn't 
> installing a JDK in production be kind of a security issue?  I can imagine 
> security departments not being thrilled about that.  Does Tomcat support 
> being run on an OpenJRE?

The argument for a JRE vs a JDK is that the JDK includes a compiler. The
only reason Tomcat can run on a JRE and still support JSPs (which
require compilation) is that Tomcat includes a Java compiler. I don't
think the security argument holds much water.

OpenJDK is very close to the Oracle JDK these days. I regularly run
Tomcat's unit tests with the latest OpenJDK and have yet to find an
issue that is OpenJDK specific.

Tomcat runs happily (and is supported) on a JRE.

If the JRE has passed the Java TCK then Tomcat should run on it. I don't
think there is an official Tomcat position but my expectation is if a
Tomcat bug (as opposed to a Java bug) appears when running on any Java
implementation that has passed the TCK then the Tomcat team would treat
that as a Tomcat bug and fix it. The caveat is that any such fix is a
lot easier if we have access to that particular version of Java and a
platform to run it on.

> Are there any implications for Tomcat?

Not directly. Jakarta EE will need to make a decision about minimum Java
versions and the like for the next round of spec updates. I expect
they'll settle on Java 11 but that discussion hasn't really started yet.

I'd be more concerned that Oracle are starting to charge for production
usage. That alone would be enough for me to switch to OpenJDK.

I haven't yet got around to installing a Java 11 GA release. I'm still
using one of the final EA releases. I'm currently intending to only
install OpenJDK for Java 11 onwards. I'm not expecting this to cause me
any issues.

> I am imagining spending all my time being taken up by Java upgrades with 
> subsequent builds, regression testing, red tape, and deployments, without 
> delivering any actual new value to our customer.  :-\

I'd plan to stick to the LTS releases.

Mark

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

RE: [OT] Oracle Java 11 discussion?

[Tony Esposito]

Hi Cris,
For what it's worth, I am not a big fan of these frequent releases of 
Java by Oracle.  One can barely get one's head around Java version 'X' then 
Java version 'Y' is out...

Tony


-Original Message-
From: Berneburg, Cris J. - US [mailto:cberneb...@caci.com] 
Sent: Monday, October 15, 2018 12:53 PM
To: users@tomcat.apache.org
Subject: [OT] Oracle Java 11 discussion?

Hi Folks

What has anyone been thinking about the upcoming Oracle Java 11 release / 
support stuff?  Frankly,  I'm confused by it all and am still trying to wrap my 
brain around it.  I have concerns about the potential implications for my 
little project, and also wonder about Tomcat at large.

No JRE - huh?  How do we run Java apps w/o a Java runtime?  Wouldn't installing 
a JDK in production be kind of a security issue?  I can imagine security 
departments not being thrilled about that.  Does Tomcat support being run on an 
OpenJRE?

Are there any implications for Tomcat?

I am imagining spending all my time being taken up by Java upgrades with 
subsequent builds, regression testing, red tape, and deployments, without 
delivering any actual new value to our customer.  :-\

--
Cris Berneburg
CACI Lead Software Engineer


-
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

[OT] Oracle Java 11 discussion?

[Berneburg, Cris J. - US]

Hi Folks

What has anyone been thinking about the upcoming Oracle Java 11 release / 
support stuff?  Frankly,  I'm confused by it all and am still trying to wrap my 
brain around it.  I have concerns about the potential implications for my 
little project, and also wonder about Tomcat at large.

No JRE - huh?  How do we run Java apps w/o a Java runtime?  Wouldn't installing 
a JDK in production be kind of a security issue?  I can imagine security 
departments not being thrilled about that.  Does Tomcat support being run on an 
OpenJRE?

Are there any implications for Tomcat?

I am imagining spending all my time being taken up by Java upgrades with 
subsequent builds, regression testing, red tape, and deployments, without 
delivering any actual new value to our customer.  :-\

--
Cris Berneburg
CACI Lead Software Engineer


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

Re: OCSP stapling in tomcat 7 with APR

[Coty Sutherland]

On Mon, Oct 15, 2018 at 11:39 AM Mark Thomas  wrote:

> On 15/10/18 16:20, Усманов Азат Анварович wrote:
> > how do I make sure ocsp is enabled on tomcat native
> >
> > when I try to pass --enable-ocsp to tomcat native configure i get
> unrecognized option warning
>
> As far as I can tell, you'd need to explicitly define OPENSSL_NO_OCSP to
> disable OCSP when building on Linux so you should be good with a
> standard build.
>

+1, just build it and as long as the openssl version you're using supports
it you're good.


>
> Mark
>
>
> >
> >
> >   ./configure  --with-apr=/usr/local/apr
> --with-java-home=/usr/java/jdk1.7.0_79 -with-ssl=/usr/local/openssl
> --enable-ocsp
> > configure: WARNING: unrecognized options: --enable-ocsp
> > checking build system type... x86_64-pc-linux-gnu
> > checking host system type... x86_64-pc-linux-gnu
> > checking target system type... x86_64-pc-linux-gnu
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking for working mkdir -p... yes
> > Tomcat Native Version: 1.2.17
> > checking for chosen layout... tcnative
> > checking for APR... yes
> > configure: APR 1.6.5 detected.
> >   setting CC to "gcc"
> >   setting CPP to "gcc -E"
> >   setting LIBTOOL to "/usr/local/apr/build-1/libtool"
> > checking JAVA_HOME... /usr/java/jdk1.7.0_79
> >   adding "-I/usr/java/jdk1.7.0_79/include" to TCNATIVE_PRIV_INCLUDES
> > checking for JDK os include directory...  linux
> >   adding "-I/usr/java/jdk1.7.0_79/include/linux" to
> TCNATIVE_PRIV_INCLUDES
> > checking for gcc... gcc
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables...
> > checking whether we are cross compiling... no
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether gcc accepts -g... yes
> > checking for gcc option to accept ISO C89... none needed
> > checking for OpenSSL library... using openssl from
> /usr/local/openssl/${exec_prefix}/lib and /usr/local/openssl/include
> > checking OpenSSL library version >= 1.0.2... ok
> > checking for OpenSSL DSA support... yes
> >   adding "-I/usr/local/openssl/include" to TCNATIVE_PRIV_INCLUDES
> >   setting TCNATIVE_LDFLAGS to "-L/usr/local/openssl/lib
> -Wl,-rpath,/usr/local/openssl/lib -lssl -lcrypto"
> >   adding "-DHAVE_OPENSSL" to CFLAGS
> >   setting TCNATIVE_LIBS to ""
> >   setting TCNATIVE_LIBS to " /usr/local/apr/lib/libapr-1.la -lrt
> -lcrypt  -lpthread"
> > checking for apr_pollset_wakeup in -lapr-1... yes
> >   adding "-DHAVE_POLLSET_WAKEUP" to CFLAGS
> > configure: creating ./config.status
> > config.status: creating tcnative.pc
> > config.status: creating Makefile
> > config.status: executing default commands
> > configure: WARNING: unrecognized options: --enable-ocsp
> >
> >
> >
> > 
> > От: Mark Thomas 
> > Отправлено: 15 октября 2018 г. 15:01:58
> > Кому: users@tomcat.apache.org
> > Тема: Re: OCSP stapling in tomcat 7 with APR
> >
> > On 14/10/18 18:45, Усманов Азат Анварович wrote:
> >> Hello everyone! I have  an java 7 web app running on tomcat 7 with
> APR/tomcat-native ON Linux .(OpenSSL 1.1.1) I would like to enable OCSP
> stapling on tomcat
> >> so that
> >> When OCSP is enabled, a server will pre-fetch the OCSP response for its
> own certificate and deliver the response to the user's browser during the
> TLS handshake. This eliminates the need to make a separate connection to
> the CA's revocation service before the Web page is displayed, improving the
> page's performance and reliability.
> >> I did search the mailing list and found this question
> >> https://www.mail-archive.com/users@tomcat.apache.org/msg129303.html
> >> but that user  is using  JSSE implementation for TLS not APR
> >>  documentation for tomcat7 does have an example
> >>
> >> Connector port="8443"
> >>protocol="org.apache.coyote.http11.Http11AprProtocol"
> >>secure="true" scheme="https"
> >>SSLEnabled="true" SSLCertificateFile="/path/to/ocsp-cert.crt"
> >>SSLCertificateKeyFile="/path/to/ocsp-cert.key"
> >>SSLCACertificateFile="/path/to/ca.pem"
> >>SSLVerifyClient="require"
> >>SSLVerifyDepth="10"
> >>clientAuth="true"/>
> >>
> >>
> >> but that is for client-cert verification, Can we do it on server side?
> or do I miss something on how ocsp is supposed to work in the first place?
> >
> > If you build an OCSP enabled version of the APR/native connector, OCSP
> > stapling should just happen without any additional configuration.
> > Assuming you use an appropriate certificate etc.
> >
> > 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
>

Re: OCSP stapling in tomcat 7 with APR

[Mark Thomas]

On 15/10/18 16:20, Усманов Азат Анварович wrote:
> how do I make sure ocsp is enabled on tomcat native
> 
> when I try to pass --enable-ocsp to tomcat native configure i get 
> unrecognized option warning

As far as I can tell, you'd need to explicitly define OPENSSL_NO_OCSP to
disable OCSP when building on Linux so you should be good with a
standard build.

Mark


> 
> 
>   ./configure  --with-apr=/usr/local/apr 
> --with-java-home=/usr/java/jdk1.7.0_79 -with-ssl=/usr/local/openssl 
> --enable-ocsp
> configure: WARNING: unrecognized options: --enable-ocsp
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking target system type... x86_64-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for working mkdir -p... yes
> Tomcat Native Version: 1.2.17
> checking for chosen layout... tcnative
> checking for APR... yes
> configure: APR 1.6.5 detected.
>   setting CC to "gcc"
>   setting CPP to "gcc -E"
>   setting LIBTOOL to "/usr/local/apr/build-1/libtool"
> checking JAVA_HOME... /usr/java/jdk1.7.0_79
>   adding "-I/usr/java/jdk1.7.0_79/include" to TCNATIVE_PRIV_INCLUDES
> checking for JDK os include directory...  linux
>   adding "-I/usr/java/jdk1.7.0_79/include/linux" to TCNATIVE_PRIV_INCLUDES
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for OpenSSL library... using openssl from 
> /usr/local/openssl/${exec_prefix}/lib and /usr/local/openssl/include
> checking OpenSSL library version >= 1.0.2... ok
> checking for OpenSSL DSA support... yes
>   adding "-I/usr/local/openssl/include" to TCNATIVE_PRIV_INCLUDES
>   setting TCNATIVE_LDFLAGS to "-L/usr/local/openssl/lib 
> -Wl,-rpath,/usr/local/openssl/lib -lssl -lcrypto"
>   adding "-DHAVE_OPENSSL" to CFLAGS
>   setting TCNATIVE_LIBS to ""
>   setting TCNATIVE_LIBS to " /usr/local/apr/lib/libapr-1.la -lrt -lcrypt  
> -lpthread"
> checking for apr_pollset_wakeup in -lapr-1... yes
>   adding "-DHAVE_POLLSET_WAKEUP" to CFLAGS
> configure: creating ./config.status
> config.status: creating tcnative.pc
> config.status: creating Makefile
> config.status: executing default commands
> configure: WARNING: unrecognized options: --enable-ocsp
> 
> 
> 
> 
> От: Mark Thomas 
> Отправлено: 15 октября 2018 г. 15:01:58
> Кому: users@tomcat.apache.org
> Тема: Re: OCSP stapling in tomcat 7 with APR
> 
> On 14/10/18 18:45, Усманов Азат Анварович wrote:
>> Hello everyone! I have  an java 7 web app running on tomcat 7 with 
>> APR/tomcat-native ON Linux .(OpenSSL 1.1.1) I would like to enable OCSP 
>> stapling on tomcat
>> so that
>> When OCSP is enabled, a server will pre-fetch the OCSP response for its own 
>> certificate and deliver the response to the user's browser during the TLS 
>> handshake. This eliminates the need to make a separate connection to the 
>> CA's revocation service before the Web page is displayed, improving the 
>> page's performance and reliability.
>> I did search the mailing list and found this question
>> https://www.mail-archive.com/users@tomcat.apache.org/msg129303.html
>> but that user  is using  JSSE implementation for TLS not APR
>>  documentation for tomcat7 does have an example
>>
>> Connector port="8443"
>>protocol="org.apache.coyote.http11.Http11AprProtocol"
>>secure="true" scheme="https"
>>SSLEnabled="true" SSLCertificateFile="/path/to/ocsp-cert.crt"
>>SSLCertificateKeyFile="/path/to/ocsp-cert.key"
>>SSLCACertificateFile="/path/to/ca.pem"
>>SSLVerifyClient="require"
>>SSLVerifyDepth="10"
>>clientAuth="true"/>
>>
>>
>> but that is for client-cert verification, Can we do it on server side? or do 
>> I miss something on how ocsp is supposed to work in the first place?
> 
> If you build an OCSP enabled version of the APR/native connector, OCSP
> stapling should just happen without any additional configuration.
> Assuming you use an appropriate certificate etc.
> 
> 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: OCSP stapling in tomcat 7 with APR

[Усманов Азат Анварович]

how do I make sure ocsp is enabled on tomcat native

when I try to pass --enable-ocsp to tomcat native configure i get unrecognized 
option warning


  ./configure  --with-apr=/usr/local/apr --with-java-home=/usr/java/jdk1.7.0_79 
-with-ssl=/usr/local/openssl --enable-ocsp
configure: WARNING: unrecognized options: --enable-ocsp
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
Tomcat Native Version: 1.2.17
checking for chosen layout... tcnative
checking for APR... yes
configure: APR 1.6.5 detected.
  setting CC to "gcc"
  setting CPP to "gcc -E"
  setting LIBTOOL to "/usr/local/apr/build-1/libtool"
checking JAVA_HOME... /usr/java/jdk1.7.0_79
  adding "-I/usr/java/jdk1.7.0_79/include" to TCNATIVE_PRIV_INCLUDES
checking for JDK os include directory...  linux
  adding "-I/usr/java/jdk1.7.0_79/include/linux" to TCNATIVE_PRIV_INCLUDES
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for OpenSSL library... using openssl from 
/usr/local/openssl/${exec_prefix}/lib and /usr/local/openssl/include
checking OpenSSL library version >= 1.0.2... ok
checking for OpenSSL DSA support... yes
  adding "-I/usr/local/openssl/include" to TCNATIVE_PRIV_INCLUDES
  setting TCNATIVE_LDFLAGS to "-L/usr/local/openssl/lib 
-Wl,-rpath,/usr/local/openssl/lib -lssl -lcrypto"
  adding "-DHAVE_OPENSSL" to CFLAGS
  setting TCNATIVE_LIBS to ""
  setting TCNATIVE_LIBS to " /usr/local/apr/lib/libapr-1.la -lrt -lcrypt  
-lpthread"
checking for apr_pollset_wakeup in -lapr-1... yes
  adding "-DHAVE_POLLSET_WAKEUP" to CFLAGS
configure: creating ./config.status
config.status: creating tcnative.pc
config.status: creating Makefile
config.status: executing default commands
configure: WARNING: unrecognized options: --enable-ocsp




От: Mark Thomas 
Отправлено: 15 октября 2018 г. 15:01:58
Кому: users@tomcat.apache.org
Тема: Re: OCSP stapling in tomcat 7 with APR

On 14/10/18 18:45, Усманов Азат Анварович wrote:
> Hello everyone! I have  an java 7 web app running on tomcat 7 with 
> APR/tomcat-native ON Linux .(OpenSSL 1.1.1) I would like to enable OCSP 
> stapling on tomcat
> so that
> When OCSP is enabled, a server will pre-fetch the OCSP response for its own 
> certificate and deliver the response to the user's browser during the TLS 
> handshake. This eliminates the need to make a separate connection to the CA's 
> revocation service before the Web page is displayed, improving the page's 
> performance and reliability.
> I did search the mailing list and found this question
> https://www.mail-archive.com/users@tomcat.apache.org/msg129303.html
> but that user  is using  JSSE implementation for TLS not APR
>  documentation for tomcat7 does have an example
>
> Connector port="8443"
>protocol="org.apache.coyote.http11.Http11AprProtocol"
>secure="true" scheme="https"
>SSLEnabled="true" SSLCertificateFile="/path/to/ocsp-cert.crt"
>SSLCertificateKeyFile="/path/to/ocsp-cert.key"
>SSLCACertificateFile="/path/to/ca.pem"
>SSLVerifyClient="require"
>SSLVerifyDepth="10"
>clientAuth="true"/>
>
>
> but that is for client-cert verification, Can we do it on server side? or do 
> I miss something on how ocsp is supposed to work in the first place?

If you build an OCSP enabled version of the APR/native connector, OCSP
stapling should just happen without any additional configuration.
Assuming you use an appropriate certificate etc.

Mark

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

RE: Tomcat 8 and authenticating Basic Auth users

[Tony Esposito]

Hello André,
  Thank you.  I would be curious to see what they come up with as a response.

Tony 

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Monday, October 15, 2018 9:13 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8 and authenticating Basic Auth users

Hi.
I put this question to the tomcat devs in a previous post, but it was somewhat 
lost in the volume I guess, so here it goes again :

@ tomcat devs :

If a HTTP request to Tomcat 8.0/8.5, in an unsollicited way (meaning without a 
previous
401 response), were to provide a "Authorization: Basic" header, would this 
trigger any Basic Auth code in Tomcat ? (I mean, even if the target app (not 
one of the ones below) does not seem to have any security-constraints or 
 like stated below ?)

We're trying to figure out why an app seems to be going through a Basic Auth 
(and rejecting it), although the app's web.xml contains no directives to that 
effect.



On 15.10.2018 16:01, Tony Esposito wrote:
> Hello André,
>Yes, you understand the issue correctly.
>Once again an excellent explanation.
>
>Using grep -rnw '/opt/apache-tomcat-8.0.22/' -e 'auth-method' and logged 
> in as 'root', I have only been able to find auth-method in the following 
> files:
>
> /opt/apache-tomcat-8.0.22/webapps/host-manager/WEB-INF/web.xml:110:
> BASIC
> /opt/apache-tomcat-8.0.22/webapps/examples/WEB-INF/web.xml:272:  
> FORM
> /opt/apache-tomcat-8.0.22/webapps/manager/WEB-INF/web.xml:165:
> BASIC
>
>Absent that, I am going to toss around the Realm versus Valve approaches 
> and give 1 (or maybe both) a try.
>Thank you.
>
> Tony
>
> -Original Message-
> From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
> Sent: Sunday, October 14, 2018 3:58 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 8 and authenticating Basic Auth users
>
> On 14.10.2018 18:44, Tony Esposito wrote:
>> Hello André,
>> As always I appreciate your detailed response.
>>
>> The web server is indeed setup in this simplified, "basic" configuration 
>> (i.e. the tomcat-users.xml file and server.xml file are configured as you 
>> described).
>> The password is always the same.  However, the users (hence, the user 
>> names) are unknown and only over time will they we known.
>>
>> How does this change your suggestion?  Could a database realm be the 
>> answer (as opposed to the tomcat-users.xml file)?
>>
>
> Whether the back-end is a file or a database, to make it work you would need 
> to have the corresponding userid/password pairs anyway.
> So no, my suggestion does not work in that case.
>
> As I understand it now :
> - the Basic authentication is active, somehow, for your webapp
> - the requests which come in for that webapp always have a Basic 
> "Authorization:" header, always with the same password part, but with a 
> user-id which varies
> - you cannot modify the front-end application part, which sends these headers 
> in the first place
> - you do not really care about the user-id, and (in a way) the password only 
> serves
> (possibly) to distinguish requests which are valid (iow coming from the 
> front-end server), from those that are not (coming from elsewhere, if that is 
> possible)
> - you want to avoid having and managing any kind of back-end database or file 
> which would have to contain all the users/passwords pairs
>
> In such circumstances, the real thing to do would be to disable the Basic 
> authentication for the webapp (which means you still need to find where it is 
> specified), and protect the access by some other means, for example by 
> blocking all requests which do NOT come from your front-end server (by IP 
> address e.g.). (There exists a Valve for that, which can be configured just 
> for that webapp if need be. See :
> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Remote_Address_Valve)
>
> Barring that, another way that I can imagine would be to create your own 
> Realm for the Basic auth. It could be totally dummy and have no users file 
> back-end at all, since you only want to compare the password to some known 
> fixed value.
> Like all Tomcat code, the code for the existing Realms is open-source and 
> available, so you could take one of them and modify it for that.
> I am not really a Java programmer, so I would not try that myself, but I 
> would imagine that for any Real Java Programmer that would not be a big 
> problem.
>
> You could even think about creating your own Valve, which would 
> (subrepticiously) modify the incoming requests' Authorization headers, to 
> replace the varying user-id part by a single user-id, which would then be the 
> single one you need in the tomcat-users.xml file (or whatever other back-end 
> is in use).
>
> Now all of these things are somewhat flaky, and certainly weaken the security 
> of your server. That may impact not only /your/ webapp, but also everything 
> else that runs on that same server. If that server i

Re: Tomcat 8 and authenticating Basic Auth users

[tomcat]

Hi.
I put this question to the tomcat devs in a previous post, but it was somewhat lost in the 
volume I guess, so here it goes again :


@ tomcat devs :

If a HTTP request to Tomcat 8.0/8.5, in an unsollicited way (meaning without a previous 
401 response), were to provide a "Authorization: Basic" header, would this trigger any 
Basic Auth code in Tomcat ? (I mean, even if the target app (not one of the ones below) 
does not seem to have any security-constraints or  like stated below ?)


We're trying to figure out why an app seems to be going through a Basic Auth (and 
rejecting it), although the app's web.xml contains no directives to that effect.




On 15.10.2018 16:01, Tony Esposito wrote:

Hello André,
   Yes, you understand the issue correctly.
   Once again an excellent explanation.

   Using grep -rnw '/opt/apache-tomcat-8.0.22/' -e 'auth-method' and logged in 
as 'root', I have only been able to find auth-method in the following files:

/opt/apache-tomcat-8.0.22/webapps/host-manager/WEB-INF/web.xml:110:
BASIC
/opt/apache-tomcat-8.0.22/webapps/examples/WEB-INF/web.xml:272:  
FORM
/opt/apache-tomcat-8.0.22/webapps/manager/WEB-INF/web.xml:165:
BASIC

   Absent that, I am going to toss around the Realm versus Valve approaches and 
give 1 (or maybe both) a try.
   Thank you.

Tony

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Sunday, October 14, 2018 3:58 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8 and authenticating Basic Auth users

On 14.10.2018 18:44, Tony Esposito wrote:

Hello André,
As always I appreciate your detailed response.

The web server is indeed setup in this simplified, "basic" configuration 
(i.e. the tomcat-users.xml file and server.xml file are configured as you described).
The password is always the same.  However, the users (hence, the user 
names) are unknown and only over time will they we known.

How does this change your suggestion?  Could a database realm be the answer 
(as opposed to the tomcat-users.xml file)?



Whether the back-end is a file or a database, to make it work you would need to 
have the corresponding userid/password pairs anyway.
So no, my suggestion does not work in that case.

As I understand it now :
- the Basic authentication is active, somehow, for your webapp
- the requests which come in for that webapp always have a Basic 
"Authorization:" header, always with the same password part, but with a user-id 
which varies
- you cannot modify the front-end application part, which sends these headers 
in the first place
- you do not really care about the user-id, and (in a way) the password only 
serves
(possibly) to distinguish requests which are valid (iow coming from the 
front-end server), from those that are not (coming from elsewhere, if that is 
possible)
- you want to avoid having and managing any kind of back-end database or file 
which would have to contain all the users/passwords pairs

In such circumstances, the real thing to do would be to disable the Basic 
authentication for the webapp (which means you still need to find where it is 
specified), and protect the access by some other means, for example by blocking 
all requests which do NOT come from your front-end server (by IP address e.g.). 
(There exists a Valve for that, which can be configured just for that webapp if 
need be. See :
http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Remote_Address_Valve)

Barring that, another way that I can imagine would be to create your own Realm 
for the Basic auth. It could be totally dummy and have no users file back-end 
at all, since you only want to compare the password to some known fixed value.
Like all Tomcat code, the code for the existing Realms is open-source and 
available, so you could take one of them and modify it for that.
I am not really a Java programmer, so I would not try that myself, but I would 
imagine that for any Real Java Programmer that would not be a big problem.

You could even think about creating your own Valve, which would 
(subrepticiously) modify the incoming requests' Authorization headers, to 
replace the varying user-id part by a single user-id, which would then be the 
single one you need in the tomcat-users.xml file (or whatever other back-end is 
in use).

Now all of these things are somewhat flaky, and certainly weaken the security 
of your server. That may impact not only /your/ webapp, but also everything 
else that runs on that same server. If that server is on the Internet, you 
should really think twice.
(I would at least consider running this connection over HTTPS, if you can).




Tony

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Sunday, October 14, 2018 5:55 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8 and authenticating Basic Auth users

On 14.10.2018 02:29, Tony Esposito wrote:

Hello André,

It's routed through a server...
A co-worker noticed a Tomcat valve that migh

RE: Tomcat 8 and authenticating Basic Auth users

[Tony Esposito]

Hello André,
  Yes, you understand the issue correctly.
  Once again an excellent explanation.  

  Using grep -rnw '/opt/apache-tomcat-8.0.22/' -e 'auth-method' and logged in 
as 'root', I have only been able to find auth-method in the following files:

/opt/apache-tomcat-8.0.22/webapps/host-manager/WEB-INF/web.xml:110:
BASIC
/opt/apache-tomcat-8.0.22/webapps/examples/WEB-INF/web.xml:272:  
FORM
/opt/apache-tomcat-8.0.22/webapps/manager/WEB-INF/web.xml:165:
BASIC

  Absent that, I am going to toss around the Realm versus Valve approaches and 
give 1 (or maybe both) a try.
  Thank you.

Tony

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Sunday, October 14, 2018 3:58 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8 and authenticating Basic Auth users

On 14.10.2018 18:44, Tony Esposito wrote:
> Hello André,
>As always I appreciate your detailed response.
>
>The web server is indeed setup in this simplified, "basic" configuration 
> (i.e. the tomcat-users.xml file and server.xml file are configured as you 
> described).
>The password is always the same.  However, the users (hence, the user 
> names) are unknown and only over time will they we known.
>
>How does this change your suggestion?  Could a database realm be the 
> answer (as opposed to the tomcat-users.xml file)?
>

Whether the back-end is a file or a database, to make it work you would need to 
have the corresponding userid/password pairs anyway.
So no, my suggestion does not work in that case.

As I understand it now :
- the Basic authentication is active, somehow, for your webapp
- the requests which come in for that webapp always have a Basic 
"Authorization:" header, always with the same password part, but with a user-id 
which varies
- you cannot modify the front-end application part, which sends these headers 
in the first place
- you do not really care about the user-id, and (in a way) the password only 
serves
(possibly) to distinguish requests which are valid (iow coming from the 
front-end server), from those that are not (coming from elsewhere, if that is 
possible)
- you want to avoid having and managing any kind of back-end database or file 
which would have to contain all the users/passwords pairs

In such circumstances, the real thing to do would be to disable the Basic 
authentication for the webapp (which means you still need to find where it is 
specified), and protect the access by some other means, for example by blocking 
all requests which do NOT come from your front-end server (by IP address e.g.). 
(There exists a Valve for that, which can be configured just for that webapp if 
need be. See : 
http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Remote_Address_Valve)

Barring that, another way that I can imagine would be to create your own Realm 
for the Basic auth. It could be totally dummy and have no users file back-end 
at all, since you only want to compare the password to some known fixed value.
Like all Tomcat code, the code for the existing Realms is open-source and 
available, so you could take one of them and modify it for that.
I am not really a Java programmer, so I would not try that myself, but I would 
imagine that for any Real Java Programmer that would not be a big problem.

You could even think about creating your own Valve, which would 
(subrepticiously) modify the incoming requests' Authorization headers, to 
replace the varying user-id part by a single user-id, which would then be the 
single one you need in the tomcat-users.xml file (or whatever other back-end is 
in use).

Now all of these things are somewhat flaky, and certainly weaken the security 
of your server. That may impact not only /your/ webapp, but also everything 
else that runs on that same server. If that server is on the Internet, you 
should really think twice.
(I would at least consider running this connection over HTTPS, if you can).



> Tony
>
> -Original Message-
> From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
> Sent: Sunday, October 14, 2018 5:55 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 8 and authenticating Basic Auth users
>
> On 14.10.2018 02:29, Tony Esposito wrote:
>> Hello André,
>>
>> It's routed through a server...
>> A co-worker noticed a Tomcat valve that might do the trick...
>> https://github.com/lokechenlin/tomcat-auto-login-valve
>>
>> Your thoughts?
>>
>
> They are as follows :
> If that works, fine.
> But as per Occam's razor principle, one should not introduce more complexity 
> than necessary. One additional dependency risks adding additional burdens in 
> terms of debugging, support, maintenance etc.
>
> And there shouldn't really be a need for anything additional.
>
> Assuming that indeed the intermediate routing server adds this Basic Auth 
> header, with a certain user-id/password pair, and that this user/password is 
> always the same.
> (That's a big if of course).
> And assuming that indeed somethin

Re: OCSP stapling in tomcat 7 with APR

[Mark Thomas]

On 14/10/18 18:45, Усманов Азат Анварович wrote:
> Hello everyone! I have  an java 7 web app running on tomcat 7 with 
> APR/tomcat-native ON Linux .(OpenSSL 1.1.1) I would like to enable OCSP 
> stapling on tomcat
> so that
> When OCSP is enabled, a server will pre-fetch the OCSP response for its own 
> certificate and deliver the response to the user's browser during the TLS 
> handshake. This eliminates the need to make a separate connection to the CA's 
> revocation service before the Web page is displayed, improving the page's 
> performance and reliability.
> I did search the mailing list and found this question
> https://www.mail-archive.com/users@tomcat.apache.org/msg129303.html
> but that user  is using  JSSE implementation for TLS not APR
>  documentation for tomcat7 does have an example
> 
> Connector port="8443"
>protocol="org.apache.coyote.http11.Http11AprProtocol"
>secure="true" scheme="https"
>SSLEnabled="true" SSLCertificateFile="/path/to/ocsp-cert.crt"
>SSLCertificateKeyFile="/path/to/ocsp-cert.key"
>SSLCACertificateFile="/path/to/ca.pem"
>SSLVerifyClient="require"
>SSLVerifyDepth="10"
>clientAuth="true"/>
> 
> 
> but that is for client-cert verification, Can we do it on server side? or do 
> I miss something on how ocsp is supposed to work in the first place?

If you build an OCSP enabled version of the APR/native connector, OCSP
stapling should just happen without any additional configuration.
Assuming you use an appropriate certificate etc.

Mark

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

Re: To Support at Tomcat, Got an issue Finding Maths.

[Luis Rodríguez Fernández]

Hello Ian,

Perhaps you are trying something like this? <%@ page
import="java.lang.Math" %>

You have very nice and simple jsp examples inside the examples application
of any tomcat distribution. E.g.
${CATALINA_BASE}webapps/examples/jsp/tagplugin/foreach.jsp

Hope it helps,

Luis


El vie., 12 oct. 2018 a las 20:19, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Ian,
>
> On 10/12/18 06:15, Ian Burton wrote:
> > On 10 Oct 2018 15:18, "Christopher Schultz"
> >  wrote: On 10/10/18 06:19, Ian Burton
> > wrote:
>  I have spent many hours searching for a organised way to ask
>  for a
> 
>  Public void setter(double value){
> 
>  Value = Maths.sin(param1);
> 
>  }
> 
>  Here is an example of files used from Java to JSP.
> 
>  [Calculus Beanjava – Measures.jsp]
> 
>  Nothing has been compatible, is there a licence restriction?
> >>
> >> It's unclear what you're asking, here.
> >>
> >> Can you explain a little more what you are trying to do?
> >>
> >
> > Expressing my problem, with JSP plugins think
> > java.lang.math.(import) is neither working or available.
> >
> > I've looked at different approaches &, Program scripted best
> > displayed.
>
> I'm sorry, I still don't understand. Can you provide an example of a
> JSP file that does _not_ work on a fresh Tomcat install, but /should/
> work?
>
> Please note that this mailing strips attachments, so you'll need to
> copy/paste into your message.
>
> What version of Tomcat are you trying to use?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvA5bAACgkQHPApP6U8
> pFinsQ//fF6EMDFJb/qqGAV5GkwIkjldqwndfewyi76C5fFNcWrFOWesUrU+55fP
> ovOuY7zsU9/hQtthhCQPtKOm3AcjLHd6CBy6bRn0GhDIuzvqXZU6TUO0OfNgzbUX
> BF+AQwM0ckJb7RvDI3oIQpMmyLzIxPW1SsAtLfgZqAc9TUvKzMIinlUcCPxZ0g+x
> yszSuAHkKBG9T0TYRyRXVRJPpw1NMWbqr0b2iD0So8vdn2GERAfI126I9PHAuSkn
> gPb7wCiMz9Y1zon3QBcoU+jl1ayXtxznFGMhVfME9TNR114s/OByMVU7gVZ5F6GI
> gu57pxbl028PCKqwIsbKDkroL8fkz11JKlRTgbYZR4ruVgQT7ktpJNyg52NvfEHu
> E9Us/7sckhBP0nzEHoJW3KsBEmVe+lQNVI+jlpo+dLG9puvWyZAW96jK4fQSD/CI
> gK2613CS8o5EdmEz2FpSsOKJMuD1urNaMzKhcNRAqq90JaknGdAeUNhTlZAkmxHv
> tL8UgijLPUHM4SAtfJJn/SeuTe9b9n9MvFPRl4g4jbSgXSh6Y9XwIy9S24y1jNjX
> zJroRxlPDiTucnrPBGnioaUVR6Id+1PbTmXrr6VQS9GEDc6FSJfUrWfOdwW/mLNG
> qlewsxhqQBUC4fxBvQbsxAUC+Dt3vN5ffA9C1UCe7C4YECl/vXg=
> =S1NH
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

[ANN] Apache Tomcat JK Connectors 1.2.46 released

[Mark Thomas]

The Apache Tomcat Project is proud to announce the release of version
1.2.46 of the Apache Tomcat Connectors.
This version fixes a number of bugs found in previous releases.

Full details of these changes and new features,
are available in the Apache Tomcat Connectors changelog:
https://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html

In addition to the usual source release, this release includes Windows
binaries for the JK ISAPI connector for IIS.

Downloads:
https://tomcat.apache.org/download-connectors.cgi

Thank you,
--
The Apache Tomcat Team

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

RE: Tomcat embedded with Apache Solr

[Jäkel , Guido]

Dear Christopher,

my 5ct on that: We're using Solr for years like (and together with) all other 
Webapps on Tomcat (and since some month on Wildfly) in a "classic" (non-cloud) 
setup without any the need for special tweaks.

There is no official support for an webapp artifact since some Versions, but 
one just have to extract the web application tree from the release.

I have no experience with embedded tomcat, but it should be also straight 
forward. Said that, I can't imagine the advantage of such an approach against 
the currently used, which just start the Web Application Server (Jetty, Tomcat 
or whatever) with the preinstalled Solr application.

We even have used it in the other way round: We used an embedded Solr Server as 
a SolrMaster instead of a SolrClient within an Ingest application to avoid the 
"serialization/network overhead" of big Solr documents. This Application was 
also hosted together with others on our Tomcat plattform


With greetings

Guido

>-Original Message-
>From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>Sent: Sunday, October 14, 2018 3:41 AM
>To: Tomcat Users List 
>Subject: Tomcat embedded with Apache Solr
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>All,
>
>I've posted a question to the Solr mailing list[1] about why Jetty is
>being used instead of Tomcat, and it seems that it's just "always the
>way it's been" for the most part.
>
>These seems to be some interest in moving from their existing model
>(Jetty launches, then hosts Solr as a web application) to an embedded
>model where a Solr-agent launches and then launches the app server
>(e.g. tc) hosting itself.
>
>Is anyone familiar enough with Solr to whip-up a quick-and-dirty POC
>for Tomcat-embedded-hosting-Solr?

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

Re: Tomcat/manager/ disable redirect from HTTPS to HTTP

[Hans Schou]

On Fri, 12 Oct 2018 at 14:12, Mark Thomas  wrote:

>
> For the HTTP connector processing proxied traffic originally received
> over HTTPS you want:
> SSLEnabled="false"
> scheme="https"
> secure="true"
>

Thanks, this one is working exactly as expected:

   

A bonus is that I now got forced use of SSL.

-- 
Venlig hilsen - best regards

Hans Schou