Re: Get Client Certificate Information

[Martynas Jusevičius]

Sorry, getHttpServletRequest() came from my code :) It’s not a Jakarta
method.

In JAX-RS frameworks such as Jersey you can use @Context or @Inject
annotations to get request and servlet context objects (such as
HttpServletRequest):
https://jakarta.ee/specifications/dependency-injection/2.0/apidocs/jakarta/inject/inject


On Wed, 21 Jun 2023 at 20.32, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Timothy,
>
> On 6/21/23 13:55, Timothy Ward wrote:
> > Not sure it's lined up right, lost in copy/paste I think, the ^ seems to
> be
> > initially under the (X509Certificate[]) right before the
> > getHttpServletRequest(), so I thought it didn't like the
> > getHttpServletRequest itself, maybe it doesn't like the getAttribute
> method.
>
> The compiler tells you 100% it's getHttpServletRequest.
>
> You didn't post the rest of the code, so we have no idea what kind of
> class this code exists in. My guess is that whatever class this code is
> in does not have a getHttpServletRequest() method to call.
>
> If you can post more code, we may be able to help.
>
> -chris
>
> > On Wed, Jun 21, 2023 at 1:52 PM Rob Sargent 
> wrote:
> >
> >>
> >>
> >>> On Jun 21, 2023, at 11:29 AM, Timothy Ward 
> >> wrote:
> >>>
> >>> I tried the following:
> >>>
> >>> import javax.servlet.http.HttpServletRequest;
> >>> import javax.security.cert.Certificate;
> >>> import javax.security.cert.X509Certificate;
> >>>
> >>> X509Certificate[] certs = (X509Certificate[])
> >>>
> >>
> getHttpServletRequest().getAttribute("jakarta.servlet.request.X509Certificate");
> >>>
> >>> and I'm getting:
> >>>
> >>> [Error]  (1: 0): GrabCert:33: error: cannot find symbol,
> >>> [Error]  (1: 0):   X509Certificate[] certs = (X509Certificate[])
> >>>
> >>
> getHttpServletRequest().getAttribute("jakarta.servlet.request.X509Certificate");,
> >>> [Error]  (1: 0): ^,
> >>> [Error]  (1: 0):   symbol:   method getHttpServletRequest(),
> >>> [Error]  (1: 0):   location: class GrabCert, [Error]  (1: 0): 1 error
> >>>
> >>
> >> If I lined that up correctly, it seems to be pointing at “getAttribute”.
> >> Is your getHttpServletRequest giving you what you expect?
> >>
> >>
> >> -
> >> 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: Get Client Certificate Information

[Martynas Jusevičius]

You can get client certificates from ServletRequest:

X509Certificate[] certs =
(X509Certificate[])getHttpServletRequest().getAttribute("jakarta.servlet.request.X509Certificate");

https://jakarta.ee/specifications/servlet/5.0/apidocs/jakarta/servlet/servletrequest#getAttribute(java.lang.String)

On Sun, Jun 11, 2023 at 11:20 PM Timothy Ward  wrote:
>
> Tomcat 10.1 setup using certificateVerification="required" on Windows
> Server 2019, is there a way to get the SSL_CLIENT_S_DN and SSL_CLIENT_I_DN
> via a CGI perl script?  I think I have the SSLValve valve implemented, but
> there is nothing for sure that tells me that it is.
>
> The browser prompts for the pin and authenticates just fine, I just need a
> way to get some of the client certificate information.
>
> Thanks,
> Tim

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

Re: [10.1.4] Dots in URL

[Martynas Jusevičius]

Thanks.

On Mon, 6 Mar 2023 at 13.32, Mark Thomas  wrote:

> On 06/03/2023 12:24, Martynas Jusevičius wrote:
> > Hi,
> >
> > I have a JAX-RS application deployed on Tomcat.
> >
> > When a URL contains dots, I get a 422 Unprocessable Entity response
> > which looks like it's coming from Tomcat.
> >
> > When I remove the dots, the request works fine and reaches my
> application.
> >
> > Is that Tomcat's behavior?
>
> No. The Tomcat code never returns a 422 response. It must be coming from
> the application or some other component in the stack (e..g a reverse
> proxy).
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

[10.1.4] Dots in URL

[Martynas Jusevičius]

Hi,

I have a JAX-RS application deployed on Tomcat.

When a URL contains dots, I get a 422 Unprocessable Entity response
which looks like it's coming from Tomcat.

When I remove the dots, the request works fine and reaches my application.

Is that Tomcat's behavior?

Martynas

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

Re: [10.1.4] If-None-Match does not conform to RFC 7230 and has been ignored

[Martynas Jusevičius]

Thanks. The error was on my end -- the header value included a trailing newline.

On Thu, Dec 15, 2022 at 10:59 PM Mark Thomas  wrote:
>
> Got it thanks.
>
> I can see what the problem is now.
>
> The line ending for the If-None-Match header is CR. It should be CRLF.
>
> RFC 7230 does allow servers to accept just LF (Tomcat does) but a bare
> CR is not acceptable. It Tomcat sees a CR followed by anything other
> than a LF that will trigger a 400 response.
>
> Earlier Tomcat versions were more lenient but we have tightened things
> up over time - usually in response to request smuggling concerns.
>
> CR 0x0d carriage return
> LF 0x0a line fine
>
> HTH,
>
> Mark
>
>
> On 15/12/2022 21:23, Mark Thomas wrote:
> > Sounds good. Could you send it directly to me again please.
> >
> > Thanks.
> >
> > Mark
> >
> >
> > On 15/12/2022 20:15, Martynas Jusevičius wrote:
> >> OK, I think I got them.
> >>
> >> GET /default-subject is the request with the If-None-Match header.
> >>
> >> On Thu, Dec 15, 2022 at 9:11 PM Mark Thomas  wrote:
> >>>
> >>> Thanks, I have the pcap file.
> >>>
> >>> It looks to be the right network connection as it shows the start of a
> >>> connection to port 8080.
> >>>
> >>> However, it only contains the first packet. I need at least all the
> >>> packets up to the point the HTTP request is sent and ideally all the
> >>> packets from the connection.
> >>>
> >>> If you can capture more packets, I think we'll have what we need.
> >>>
> >>> Mark
> >>>
> >>>
> >>>
> >>> On 15/12/2022 20:03, Mark Thomas wrote:
> >>>> Hi Martynas,
> >>>>
> >>>> The list strips (nearly all) attachments. Please send it to me directly
> >>>> and I'll let you know if it is what we need.
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>> On 15/12/2022 19:51, Martynas Jusevičius wrote:
> >>>>> Hi Mark,
> >>>>>
> >>>>> I've captured something using
> >>>>> https://github.com/nicolaka/netshoot#tcpdump (attached as a .pcap
> >>>>> file), but I'm not sure it's correct and/or what you need.
> >>>>>
> >>>>> If you gave me some instructions, that would be easier. My app is
> >>>>> running in a Docker container, the request comes from a script on WSL
> >>>>> 2 Ubuntu.
> >>>>>
> >>>>> Martynas
> >>>>>
> >>>>> On Thu, Dec 15, 2022 at 6:45 PM Mark Thomas  wrote:
> >>>>>>
> >>>>>> Hard to tell from the data posted.
> >>>>>>
> >>>>>> What we really need to see are the bytes on the wire for a failed
> >>>>>> request. Can you capture that with wireshark (or similar) and post
> >>>>>> what
> >>>>>> you find?
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>>
> >>>>>> On 15/12/2022 16:17, Martynas Jusevičius wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> After upgrading from 9.0.59 to 10.1.4, I've started getting these
> >>>>>>> kind
> >>>>>>> of errors:
> >>>>>>>
> >>>>>>> java.lang.IllegalArgumentException: The HTTP header line
> >>>>>>> [if-none-match:"e76590d5""] does not conform to RFC 7230 and has
> >>>>>>> been
> >>>>>>> ignored.
> >>>>>>>at
> >>>>>>> org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1093)
> >>>>>>>at
> >>>>>>> org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:991)
> >>>>>>>at
> >>>>>>> org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
> >>>>>>>at
> >>>>>>> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:295)
> >>>>>>>at
> >>>>>>> org.apache.coyote.AbstractProcessorLight.proces

Re: [10.1.4] If-None-Match does not conform to RFC 7230 and has been ignored

[Martynas Jusevičius]

OK, I think I got them.

GET /default-subject is the request with the If-None-Match header.

On Thu, Dec 15, 2022 at 9:11 PM Mark Thomas  wrote:
>
> Thanks, I have the pcap file.
>
> It looks to be the right network connection as it shows the start of a
> connection to port 8080.
>
> However, it only contains the first packet. I need at least all the
> packets up to the point the HTTP request is sent and ideally all the
> packets from the connection.
>
> If you can capture more packets, I think we'll have what we need.
>
> Mark
>
>
>
> On 15/12/2022 20:03, Mark Thomas wrote:
> > Hi Martynas,
> >
> > The list strips (nearly all) attachments. Please send it to me directly
> > and I'll let you know if it is what we need.
> >
> > Mark
> >
> >
> > On 15/12/2022 19:51, Martynas Jusevičius wrote:
> >> Hi Mark,
> >>
> >> I've captured something using
> >> https://github.com/nicolaka/netshoot#tcpdump (attached as a .pcap
> >> file), but I'm not sure it's correct and/or what you need.
> >>
> >> If you gave me some instructions, that would be easier. My app is
> >> running in a Docker container, the request comes from a script on WSL
> >> 2 Ubuntu.
> >>
> >> Martynas
> >>
> >> On Thu, Dec 15, 2022 at 6:45 PM Mark Thomas  wrote:
> >>>
> >>> Hard to tell from the data posted.
> >>>
> >>> What we really need to see are the bytes on the wire for a failed
> >>> request. Can you capture that with wireshark (or similar) and post what
> >>> you find?
> >>>
> >>> Mark
> >>>
> >>>
> >>> On 15/12/2022 16:17, Martynas Jusevičius wrote:
> >>>> Hi,
> >>>>
> >>>> After upgrading from 9.0.59 to 10.1.4, I've started getting these kind
> >>>> of errors:
> >>>>
> >>>> java.lang.IllegalArgumentException: The HTTP header line
> >>>> [if-none-match:"e76590d5""] does not conform to RFC 7230 and has been
> >>>> ignored.
> >>>>   at
> >>>> org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1093)
> >>>>   at
> >>>> org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:991)
> >>>>   at
> >>>> org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
> >>>>   at
> >>>> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:295)
> >>>>   at
> >>>> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> >>>>   at
> >>>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:859)
> >>>>   at
> >>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1734)
> >>>>   at
> >>>> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
> >>>>   at
> >>>> org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
> >>>>   at
> >>>> org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
> >>>>   at
> >>>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> >>>>   at java.base/java.lang.Thread.run(Thread.java:833)
> >>>>
> >>>> Request headers look like this:
> >>>>
> >>>> GET /default-subject HTTP/1.1
> >>>> Host: localhost:8080
> >>>> User-Agent: curl/7.58.0
> >>>> Accept: application/n-triples
> >>>> If-None-Match: "e76590d5"
> >>>>
> >>>> Can someone please explain to me what the problem is here? I guess the
> >>>> Tomcat doesn't like the ETag value, but why?
> >>>>
> >>>> Thanks.
> >>>>
> >>>> Martynas
> >>>>
> >>>> -
> >>>> 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
> >
>
> -
> 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: [10.1.4] If-None-Match does not conform to RFC 7230 and has been ignored

[Martynas Jusevičius]

Hi Mark,

I've captured something using
https://github.com/nicolaka/netshoot#tcpdump (attached as a .pcap
file), but I'm not sure it's correct and/or what you need.

If you gave me some instructions, that would be easier. My app is
running in a Docker container, the request comes from a script on WSL
2 Ubuntu.

Martynas

On Thu, Dec 15, 2022 at 6:45 PM Mark Thomas  wrote:
>
> Hard to tell from the data posted.
>
> What we really need to see are the bytes on the wire for a failed
> request. Can you capture that with wireshark (or similar) and post what
> you find?
>
> Mark
>
>
> On 15/12/2022 16:17, Martynas Jusevičius wrote:
> > Hi,
> >
> > After upgrading from 9.0.59 to 10.1.4, I've started getting these kind
> > of errors:
> >
> > java.lang.IllegalArgumentException: The HTTP header line
> > [if-none-match:"e76590d5""] does not conform to RFC 7230 and has been
> > ignored.
> >  at 
> > org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1093)
> >  at 
> > org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:991)
> >  at 
> > org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
> >  at 
> > org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:295)
> >  at 
> > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> >  at 
> > org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:859)
> >  at 
> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1734)
> >  at 
> > org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
> >  at 
> > org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
> >  at 
> > org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
> >  at 
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> >  at java.base/java.lang.Thread.run(Thread.java:833)
> >
> > Request headers look like this:
> >
> > GET /default-subject HTTP/1.1
> > Host: localhost:8080
> > User-Agent: curl/7.58.0
> > Accept: application/n-triples
> > If-None-Match: "e76590d5"
> >
> > Can someone please explain to me what the problem is here? I guess the
> > Tomcat doesn't like the ETag value, but why?
> >
> > Thanks.
> >
> > Martynas
> >
> > -
> > 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

[10.1.4] If-None-Match does not conform to RFC 7230 and has been ignored

[Martynas Jusevičius]

Hi,

After upgrading from 9.0.59 to 10.1.4, I've started getting these kind
of errors:

java.lang.IllegalArgumentException: The HTTP header line
[if-none-match:"e76590d5""] does not conform to RFC 7230 and has been
ignored.
at 
org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1093)
at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:991)
at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:295)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:859)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1734)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)

Request headers look like this:

GET /default-subject HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.58.0
Accept: application/n-triples
If-None-Match: "e76590d5"

Can someone please explain to me what the problem is here? I guess the
Tomcat doesn't like the ETag value, but why?

Thanks.

Martynas

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

Re: Publishing Tomcat webapp

[Martynas Jusevičius]

Hi,

Wouldn’t this setup be easier to deploy as a Docker container?
We have an image with SSL server cert support:
https://github.com/AtomGraph/letsencrypt-tomcat


On Mon, 18 Jul 2022 at 16.09, Aryeh Friedman 
wrote:

> Here are the steps to installing a SSL cert (it varies slightly based
> on who your certificate authority [CA] is):
>
> Generate a CSR with keytool (it must be key tool despite what the
> tomcat docs say since for whatever reason it refuses to import from
> any other SSL tool):
>
> keytool –keystore clientkeystore –genkey –alias mykey
>
> Submit the above to your CA (they will give you directions on how to
> submit it) and have them issued a signed cert for it
>
> The signed cert usually comes with some intermediate files (this is
> the part that varies by CA) which you have to apply in order to the
> keystore (the following is the set of files I use):
>
> keytool -noprompt -importcert -alias AAACertificateServices -file
> AAACertificateServices.crt -keystore sslStore
>
> keytool -importcert -trustcacerts -keystore sslStore -file
> USERTrustRSCA.crt -alias USERTrustRSCA
>
> keytool -importcert -trustcacerts -keystore sslStore -file
> /SectigoRSAOrganizationValidationSecureServerCA.crt -alias
> SectigoRSAOrganizationValidationSecureServerCA
>
> keytool -importcert -trustcacerts -alias mykey (this *MUST* match the
> alias of the CSR you submitted to the CA)
> -file 1008013344repl_2.crt -keystore sslStore
>
> Modify the tomcat server.xml to uncomment out the right https line in
> the config and tell it where to find the sslStore (some OS's force you
> to put it in $TOMCAT_HOME)... for example I do the following:
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>port="443" maxThreads="200"
>scheme="https" secure="true" SSLEnabled="true"
>keystoreFile="/usr/local/apache-tomcat-9.0/keystore"
> keystorePass="mySuperSecretPassword"
>clientAuth="false" sslProtocol="TLS"
> sslEnabledProtocols="TLSv1.2"/>
>
> Restart tomcat and you should have SSL how if you go to https if you
> on port 8080 you will likely want to put in 8443 not 443
>
>
> References:
> https://docs.oracle.com/cd/E19509-01/820-3503/ggezu/index.html
>
>
> On Mon, Jul 18, 2022 at 8:11 AM Jasmin Ćatić 
> wrote:
> >
> > Now I have another setback.
> > I have my tomcat running on the domain name www.mydomain.com and I have
> an
> > SSL certificate on this domain (CA_BUNDLE, Certificate and Key) in my
> > CPanel.
> > How to configure Tomcat to use this SSL and HTTPS protocol.
> >
> > Thanks again for your help
> >
> > pon, 18. srp 2022. u 08:24 Jasmin Ćatić 
> napisao
> > je:
> >
> > > Thank you very much. I have done it successfully.
> > > Best regards
> > > JC
> > >
> > > ned, 17. srp 2022. u 09:08 Thomas Hoffmann (Speed4Trade GmbH)
> > >  napisao je:
> > >
> > >> Hello,
> > >>
> > >> > -Ursprüngliche Nachricht-
> > >> > Von: Aryeh Friedman 
> > >> > Gesendet: Sonntag, 17. Juli 2022 08:43
> > >> > An: Tomcat Users List 
> > >> > Betreff: Re: Publishing Tomcat webapp
> > >> >
> > >> > On Sun, Jul 17, 2022 at 2:39 AM Aryeh Friedman
> > >> > 
> > >> > wrote:
> > >> > > Once you have it pointing to that domain just upload the war file
> to
> > >> > > it
> > >> > and give people the link.
> > >> >
> > >> > Small wording correction... I mean upload the war file as being a
> part
> > >> of the
> > >> > webapp and/or a part of an other webapp you have for downloading...
> > >> > take a look at the download section of the site I list in my
> signature.
> > >> >
> > >> > --
> > >> > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
> > >>
> > >> Usually you need 2 things:
> > >> 1) A webserver or webspace. This includes a public IP address
> > >> 2) A domain. You can buy it online.
> > >>
> > >> When you own a domain, you have access to the DNS settings. Create an
> > >> A-Record with the domain-name and point it to the IP address of your
> server.
> > >> If an A-records already exists, modify it to point to the IP address
> of
> > >> the server.
> > >>
> > >> Install tomcat on the webserver and install your web-application.
> > >> Tomcat listens per default on all ports, so no special configuration
> > >> needed (only if you host multiple domains on that server).
> > >>
> > >
>
>
>
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat fails to start in Docker on Amazon ECS

[Martynas Jusevičius]

My bad :) CATALINA_OPTS was malformed.

On Sat, May 15, 2021 at 10:19 AM Martynas Jusevičius
 wrote:
>
> Hi,
>
> I have a Docker image that extends tomcat:9.0.39-jdk11 and at the very
> end of the entrypoint script calls 'catalina.sh run'.
>
> This has worked fine both on my local Windows and on a CentOS server.
> However when I start a container on Amazon ECS with AMI Linux, I get
> the error below when catalina.sh is called.
> This has obviously to do with the java command, but why? Has anyone
> experienced something similar?
>
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> Usage: java [options]  [args...]
>(to execute a class)
>or  java [options] -jar  [args...]
>(to execute a jar file)
>or  java [options] -m [/] [args...]
>java [options] --module [/] [args...]
>(to execute the main class in a module)
>or  java [options]  [args]
>(to execute a single source-file program)
> " Arguments following the main class, source file, -jar ,"
>  -m or --module / are passed as the arguments to
>  main class.
>  where options include:
> -cp 
> -classpath 
> --class-path 
> "  A : separated list of directories, JAR archives,"
>   and ZIP archives to search for class files.
> -p 
> --module-path ...
> "  A : separated list of directories, each directory"
>   is a directory of modules.
> --upgrade-module-path ...
> "  A : separated list of directories, each directory"
>   is a directory of modules that replace upgradeable
>   modules in the runtime image
> "--add-modules [,...]"
>   root modules to resolve in addition to the initial module.
> "   can also be ALL-DEFAULT, ALL-SYSTEM,"
>   ALL-MODULE-PATH.
> --list-modules
>   list observable modules and exit
> -d 
> --describe-module 
>   describe a module and exit
> --dry-run create VM and load main class but do not execute main 
> method.
>   The --dry-run option may be useful for validating the
>   command-line options such as the module system 
> configuration.
> --validate-modules
>   validate all modules and exit
>   The --validate-modules option may be useful for finding
>   conflicts and other errors with modules on the module path.
> -D=
>   set a system property
> -verbose:[class|module|gc|jni]
>   enable verbose output
> -version  print product version to the error stream and exit
> --version print product version to the output stream and exit
> -showversion  print product version to the error stream and continue
> --show-version
>   print product version to the output stream and continue
> --show-module-resolution
>   show module resolution output during startup
> -? -h -help
>   print this help message to the error stream
> --helpprint this help message to the output stream
> -Xprint help on extra options to the error stream
> --help-extra  print help on extra options to the output stream
> -ea[:...|:]
> -enableassertions[:...|:]
>   enable assertions with specified granularity
> -da[:...|:]
> -disableassertions[:...|:]
>   disable assertions with specified granularity
> -esa | -enablesystemassertions
>   enable system assertions
> -dsa | -disablesystemassertions
>   disable system assertions
> -agentlib:[=]
> "  load native agent library , e.g. -agentlib:jdwp"
>   see also -agentlib:jdwp=help
> -agentpath:[=]
>   load native agent library by full pathname
> -javaagent:[=]
> "  load Java programming language agent, see
> java.lang.instrument"
> -splash:
>   show splash screen with specified image
>   HiDPI scaled images are automatically supported and used
> "  if available. The unscaled image filename, e.g. image.ext,"
>   should always be passed as the argument to the -splash 
> option.
>   The most appropriate scaled image provided will be picked up
&

Tomcat fails to start in Docker on Amazon ECS

[Martynas Jusevičius]

Hi,

I have a Docker image that extends tomcat:9.0.39-jdk11 and at the very
end of the entrypoint script calls 'catalina.sh run'.

This has worked fine both on my local Windows and on a CentOS server.
However when I start a container on Amazon ECS with AMI Linux, I get
the error below when catalina.sh is called.
This has obviously to do with the java command, but why? Has anyone
experienced something similar?

NOTE: Picked up JDK_JAVA_OPTIONS:
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
Usage: java [options]  [args...]
   (to execute a class)
   or  java [options] -jar  [args...]
   (to execute a jar file)
   or  java [options] -m [/] [args...]
   java [options] --module [/] [args...]
   (to execute the main class in a module)
   or  java [options]  [args]
   (to execute a single source-file program)
" Arguments following the main class, source file, -jar ,"
 -m or --module / are passed as the arguments to
 main class.
 where options include:
-cp 
-classpath 
--class-path 
"  A : separated list of directories, JAR archives,"
  and ZIP archives to search for class files.
-p 
--module-path ...
"  A : separated list of directories, each directory"
  is a directory of modules.
--upgrade-module-path ...
"  A : separated list of directories, each directory"
  is a directory of modules that replace upgradeable
  modules in the runtime image
"--add-modules [,...]"
  root modules to resolve in addition to the initial module.
"   can also be ALL-DEFAULT, ALL-SYSTEM,"
  ALL-MODULE-PATH.
--list-modules
  list observable modules and exit
-d 
--describe-module 
  describe a module and exit
--dry-run create VM and load main class but do not execute main method.
  The --dry-run option may be useful for validating the
  command-line options such as the module system configuration.
--validate-modules
  validate all modules and exit
  The --validate-modules option may be useful for finding
  conflicts and other errors with modules on the module path.
-D=
  set a system property
-verbose:[class|module|gc|jni]
  enable verbose output
-version  print product version to the error stream and exit
--version print product version to the output stream and exit
-showversion  print product version to the error stream and continue
--show-version
  print product version to the output stream and continue
--show-module-resolution
  show module resolution output during startup
-? -h -help
  print this help message to the error stream
--helpprint this help message to the output stream
-Xprint help on extra options to the error stream
--help-extra  print help on extra options to the output stream
-ea[:...|:]
-enableassertions[:...|:]
  enable assertions with specified granularity
-da[:...|:]
-disableassertions[:...|:]
  disable assertions with specified granularity
-esa | -enablesystemassertions
  enable system assertions
-dsa | -disablesystemassertions
  disable system assertions
-agentlib:[=]
"  load native agent library , e.g. -agentlib:jdwp"
  see also -agentlib:jdwp=help
-agentpath:[=]
  load native agent library by full pathname
-javaagent:[=]
"  load Java programming language agent, see
java.lang.instrument"
-splash:
  show splash screen with specified image
  HiDPI scaled images are automatically supported and used
"  if available. The unscaled image filename, e.g. image.ext,"
  should always be passed as the argument to the -splash option.
  The most appropriate scaled image provided will be picked up
  automatically.
  See the SplashScreen API documentation for more information
@argument files
  one or more argument files containing options
-disable-@files
  prevent further argument file expansion
--enable-preview
  allow classes to depend on preview features of this release
"To specify an argument for a long option, you can use --= or"
-- .

Martynas
atomgraph.com

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

Re: Defining environment variables for a webapp ?

[Martynas Jusevičius]

Rony,

you might want to look into containerizing your webapps. We use an
XSLT stylesheet (invoked by the entrypoint script) that transforms env
params into context.xml params:
https://github.com/AtomGraph/LinkedDataHub/blob/master/platform/context.xsl


Martynas

On Wed, Apr 14, 2021 at 2:16 PM Rony G. Flatscher (Apache)
 wrote:
>
> On 14.04.2021 13:25, Mark Thomas wrote:
> > On 14/04/2021 12:22, Rony G. Flatscher (Apache) wrote:
> >> Not finding any pointers, asking here: is it possible to define 
> >> environment variables for a webapp?
> >> If so, how?
> >
> > You can only set them globally, for the Java process - not per web 
> > application.
> >
> > CGI creates a new process so can have a completely different set of 
> > environment variables.
> >
> > How about using the per web application JNDI context?
>
> Well the idea was to adjust PATH to have it point to a webapp based directory 
> containing the
> binaries. :)
>
> ---rony
>
> P.S.: The aim would be to make it simple and easy for deploying webapps that 
> also need to have
> access to non-Java binaries (executables and/or shared libraries).
>
>
>
> -
> 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: Dynamic Configuration on TC startup

[Martynas Jusevičius]

I think this is where you need to wrap your apps into Docker images :)

See this base image for example:
https://hub.docker.com/r/atomgraph/letsencrypt-tomcat
It configures server.xml by using an XSLT stylesheet and environmental
parameters: 
https://github.com/AtomGraph/letsencrypt-tomcat/blob/master/entrypoint.sh#L134

And this image extends it and adds the webapp (as ROOT) in a two-stage
build: https://github.com/AtomGraph/LinkedDataHub/blob/master/Dockerfile#L139

Hope it helps.

On Wed, Feb 24, 2021 at 12:45 AM Jerry Malcolm  wrote:
>
> The server solution I am developing is split across multiple Amazon Web
> Services EC2 instances.  They all use the same TC WAR images.  But each
> server handles a different portion of the functionality
> aaa.mydomain.com is called for one set of function, and bbb.mydomain.com
> is called for another set of function.  This is not load balancing the
> same server.  It's two separate TC "hosts" with two different server
> names, but the same code base.
>
> It hugely simplifies maintenance if I can create one EC2 server image
> (AWS AMI) and clone it to both aaa.mydomain and bbb.mydomain servers.
> But the one issue is the TC configuration.  The TC host name on aaa
> needs to be configured as aaa.mydomain.com and bbb TC host name needs to
> be configured as bbb.mydomain.com.
>
> I figure the brute force method is to clone the AMI to both and then
> scp/ftp one TC config directory to aaa and a different TC config
> directory to bbb.  That will work.  But in my mind it's not elegant, and
> until I write automation scripts, it requires manual intervention.
>
> This may be a short thread if you say that's the way to do it. Fine.
> But I do want to ask if there's any better ways to do this that I'm not
> aware of, such as using RDNS or something at TC boot to identify if I'm
> aaa or bbb based on my ip address and then boot the appropriate Tomcat
> config accordingly.  Ok, maybe I'm just blue skying  But I would
> like a few opinions from people a lot closer to this area than I am.
>
> One other fly in the ointment is that a few of the hosts currently have
> light activity, but may grow.  So in a couple of cases, I have multiple
> virtual TC hosts (ccc.mydomain, ddd.mydomain, and eee.mydomain) on one
> single EC2 instance allowing for the capability to split any one of
> those out to its own EC2 instance in the future as needed.
>
> So EC2-a has aaa, EC2-b has bbb, and EC2-c has ccc, ddd, and eee hosts.
> But again, all of TC hosts run the same WAR packages.
>
> Thanks.
>
> Jerry
>
>
> -
> 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: Not able to connect to Tomcat 9.0.39 instance using jconsole/jvisualvm

[Martynas Jusevičius]

Not sure if related, but JPDA address config changed from -
JPDA_ADDRESS=8000 on Tomcat 8 to - JPDA_ADDRESS=*:8000 on Tomcat 9
(i.e. host needs to be included, or a wildcard).

On Tue, Feb 2, 2021 at 12:22 PM Suvendu Sekhar Mondal  wrote:
>
> Hello Everyone,
>
> We recently migrated Tomcat from 7.0.55 to 9.0.39. Everything is
> working as expected except accessing exposed MBeans via JMX clients
> like jconsole/jvisualvm. While troubleshooting the issue, I enabled
> debug logging for both of those tools and it is throwing following
> error:
> java.rmi.ConnectIOException: non-JRMP server at remote endpoint
> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:248)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338)
> at sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112)
> at sun.tools.jconsole.ProxyClient.checkSslConfig(ProxyClient.java:234)
> at sun.tools.jconsole.ProxyClient.(ProxyClient.java:127)
> at sun.tools.jconsole.ProxyClient.getProxyClient(ProxyClient.java:475)
> at sun.tools.jconsole.JConsole$3.run(JConsole.java:524)
>
> We are using org.apache.catalina.mbeans.JmxRemoteLifecycleListener to
> specify RMI registry and server port like this:
>className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> rmiRegistryPortPlatform="8181" rmiServerPortPlatform="8282" />
>
> And we can see that TC is registering properly to those ports:
>  2021-02-02 05:07:08,541 INFO
> org.apache.catalina.mbeans.JmxRemoteLifecycleListener - The JMX Remote
> Listener has configured the registry on port [8181] and the server on
> port [8282] for the [Platform] server
>
> We use remote JMX with no authentication or SSL:
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=false
>
> Workaround is to add following options in JVM arguments and then I was
> able to use JMX on port 8181:
> -Dcom.sun.management.jmxremote
> -Dcom.sun.management.jmxremote.port=8181
>
> But I am not sure why it broke in Tomcat 9.0.39 in the first place
> because with a similar configuration we are able to access JMX on
> Tomcat 7.0.55. I noticed that JmxRemoteLifecycleListener has been
> deprecated and will be removed in future[1] but we are on a version
> which was released 3-4 months ago. So, could this be a bug or
> something else?
>
> [1] 2021-02-02 05:07:07,447 WARNING
> org.apache.catalina.mbeans.JmxRemoteLifecycleListener - The
> JmxRemoteLifecycleListener is deprecated as as the features it
> provides are now available in the remote JMX capability included with
> the JRE. This listener will be removed in Tomcat 10 and may be removed
> from Tomcat 9 some time after 2020-12-31.
>
> JDK version: jdk1.8.0_192
> OS: Windows Server 2016
>
> Thanks & Regards,
> Suvendu
>
> -
> 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

Rate limiting

[Martynas Jusevičius]

Hi,

How do I limit request rates using Tomcat 9.0.x?

Something similar to limit_req in nginx:
https://www.nginx.com/blog/rate-limiting-nginx/


Martynas
atomgraph.com

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

Re: Max heap size when using -XX:MaxRAMPercentage

[Martynas Jusevičius]

Christopher,

thanks for your reply. Answers inline.

> > What I see in the profiler is Max Heap Size 310378496 B, which is only 0.28 
> > GiB.
>
> This is probably the maximum size of the /used/ heap. Can you confirm that?

Nope. Netbeans profiler says: Max Heap Size 310378496 B, Max Used Heap
261052168 B

> Try running your application without *any* memory parameters and run it
> through a reasonable exercise. Then look at everything with your
> profiles *and also* make sure you look at the OS's report of the
> allocated memory for the process. That will give you a sense for how
> much "native memory" versus heap memory your application actually needs.
> You may find that the native memory requirements are roughly the same
> size as the Java heap requirements. That means you can't even reasonably
> approach a 50% heap size because you still need to be about to run the
> OS which takes a bit of memory.

I'll try that now. I've seen people recommending up to 80% RAM though:
https://dev.to/focusedlabs/the-no-nonsense-guide-to-jvm-14-memory-on-kubernetes-508m

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

Max heap size when using -XX:MaxRAMPercentage

[Martynas Jusevičius]

Hi,

I am attempting to make my webapps that run in Tomcat to take
advantage of the Docker container-specific JVM options such as
-XX:MaxRAMPercentage:
https://www.eclipse.org/openj9/docs/xxinitialrampercentage/
TL;DR It allows specifying JVM heap as % of the container memory limit
rather than using the default 25%.

Running tomcat:9.0.39-jdk11, what I did is specify

CATALINA_OPTS=-XX:MaxRAMPercentage=75

which should use 75% of the container memory limit which is 3.702GiB
in this case.

So I login into the container and execute ps aux to see Tomcat's
command arguments:

/usr/local/openjdk-11/bin/java
-Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
-XX:MaxRAMPercentage=75.0 -Duser.timezone=Europe/Copenhagen
-Dignore.endorsed.dirs= -classpath
/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
-Dcatalina.base=/usr/local/tomcat -Dcatalina.home=/usr/local/tomcat
-Djava.io.tmpdir=/usr/local/tomcat/temp
org.apache.catalina.startup.Bootstrap start

If I replace "org.apache.catalina.startup.Bootstrap start" with
"-XshowSettings:vm -version" and run, this is what I get:

Max. Heap Size (Estimated): 2.78G
Using VM: OpenJDK 64-Bit Server VM

Where 2.78G is 75% of 3.7GiB -- so far so good, the MaxRAMPercentage
setting seems to have worked here.

But I'm still getting "Cannot allocate memory" exceptions that kill
the container when importing large datasets. So I attached a profiler.

What I see in the profiler is Max Heap Size 310378496 B, which is only 0.28 GiB.

So how much max heap does my webapp have access to -- is it 2.78G or
0.28G? If it's 0.28, why? How do I enforce the 75% RAM setting for the
webapp?


Martynas
atomgraph.com

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

Re: completely automated (for real) Let's Encrypt on embedded Tomcat

[Martynas Jusevičius]

https://github.com/AtomGraph/letsencrypt-tomcat

On Sun, Oct 4, 2020 at 8:04 PM Garret Wilson  wrote:
>
> Hi, everyone. I'm back already. (I had intended to leave the list to
> focus my efforts elsewhere, but … here I am again.)
>
> I just realized there is a big SSL problem for small applications, and I
> want to fix it. First a little review of where we are.
>
> Servlet containers are becoming less important and less desirable in
> today's world, because we don't want to deploy and maintain some sort of
> high-level container infrastructure (in the Java EE container sense, not
> the Docker sense) just to deploy an application in it. Modern
> distributed micrososervice applications have a bunch of
> service/worker/agent application that are identical and redundant. You
> spin up as many as you need; if some go down, you (or an orchestrator)
> spins up others.
>
> For this reason libraries like Spring Boot allow you to deploy your Java
> application as a standalone JAR with embedded Tomcat. The JAR represents
> the completely independent application. You just throw it on a node and
> it runs and provides a web server or whatever. So we we should be able
> to throw a Spring Boot JAR on something like AWS Elastic Beanstalk and
> it just runs. I found out it is far from that simple, and SSL is one of
> the major problems.
>
> There seem to be two ways to get SSL support. On something like AWS
> Elastic Beanstalk, you deploy a load balancer in front of your EC
> instances. Elastic Beanstalk will (using the AWS Route 53 DNS) configure
> SSL to the load balancer, spin up EC instances as needed (each running
> your standalone JAR), and connect the load balancer to the EC instances,
> all in a (sort of) automated fashion. But note that the SSL endpoint is
> the load balancer, and the load balancer costs money! Even if you're
> just running just a single standalone JAR instance requiring a single EC
> instance, that load balancer sits there and drains cash. Significant
> cash if you just want to run a little program with SSL support.
>
> What's the other option to deploy a standalone JAR? Configure an AWS EC
> instance (or a VM with another provider), configure certbot, configure
> Tomcat, save some files locally on the machine, etc. All this manual
> work. I just want to run the standalone JAR! In short, if I have a
> standalone program I want to run, I either have to configure and
> maintain a VM like I did in the year 2000, or get into the nightmare of
> Kubernetes-like orchestration with the endless configurations and/or the
> high costs.
>
> I propose to create a module that integrates with embedded Tomcat that:
>
>  1. You indicate what domain you're hosting for (as part of the
> application configuration or as an environment variable when
> deployed, for example).
>  2. When your application starts running, it automatically connects to
> Let's Encrypt using RFC 8555 (or whatever is needed) and requests a
> certificate, based upon the IP address it's running on.
>  3. The module exposes the correct HTTP paths and/or connects to a
> configured DNS as needed for validation.
>  4. The module receives the certificates and caches them in memory or in
> a temporary file as needed and provides them to Tomcat; Tomcat now
> is serving using SSL/TLS.
>  5. If the application dies, who cares? You start up another one. It
> automatically does the same thing (on another machine or wherever it
> is running) and the application is running SSL/TLS. It's that
> simple. You don't need to run certbot. You don't need to manually
> copy files on the system. You don't even need to know where the
> application is going to run. You just need an executable JAR with
> this new module, and you run it. Done.
>  6. (Many variations exists where multiple JARs are running but one is
> the "leader" for Let's Encrypt, and they communicate and share the
> cashed certificate until the node dies. Or there are variations
> using Docker. The first step is the radical one, and then all sorts
> of possibilities open up.)
>
>  From glancing over the Let's Encrypt docs and having had hands-on
> experience embedding Tomcat, that seems completely doable to me. And I'm
> ready to start.
>
> But first, what work has been done in this area already? I'm aware of
> Chris' slides from 2018, but those techniques require some combination
> of certbot, keytool, non-embedded Tomcat, symlinks,OS scripts, manually
> file system manipulation, etc. I think at ApacheCon 2019 Chris mentioned
> some more work has been done on this, but I don't recall where it was.
>
> Please point me to the latest work and ideas for Tomcat+Let's Encrypt so
> that I don't spend two months doing something that is already been done,
> or before I find out it is impossible.
>
> As it stands I want fully automated SSL/TLS configuration just by
> running a standalone JAR, and I don't see that existing anywhere. I'm
> not pre

Connector compressibleMimeType

[Martynas Jusevičius]

Hi,

I enabled GZip compression on  using 8.0.44.

Then I noticed that text/html documents are getting compressed, but
others were not.

I guess this is due to the default compressibleMimeType? Which is
"text/html,text/xml,text/plain,text/css,text/javascript,application/javascript".
https://tomcat.apache.org/tomcat-8.0-doc/config/http.html

What would be the downside if I specified compressibleMimeType to
compress all media types? Including binary files etc.
I guess that would be compressibleMimeType="*/*".

Thanks.


Martynas

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

Re: Security audit raises questions (Tomcat 7.0.93)

[Martynas Jusevičius]

Tomcat does not allow DELETE by default? I’m using 8.0.x with Jersey and I
don’t think I used any config to enable it.

On Tue, 17 Mar 2020 at 23.50, Mark Thomas  wrote:

> On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" <
> jam...@touchtonecorp.com> wrote:
> >
> >On 3/17/20 3:18 PM, Martynas Jusevičius wrote:
> >> why should DELETE or OPTIONS not be enabled? They are standard HTTP
> >methods.
> >
> >True, but (quoting the audit report)
> >> . . . [DELETE] may allow a remote attacker to delete arbitrary files
> >. . . .
>
> There is a big difference between supporting a method (recognising it is a
> known HTTP method) and allowing it.
>
> Tomcat does not allow DELETE by default. Your app might but one assumes if
> it does the developers know what they were doing and secured it
> appropriately...
>
> Tomcat takes the view that OPTIONS should list all supported methods, not
> just methods allowed, for a given resource.
>
> >and (again quoting the report)
> >> Web servers that respond to the OPTIONS HTTP method expose what other
> >> methods are supported by the web server, allowing attackers to narrow
> >> and intensify their efforts.
>
> That is a security by obscurity argument. The Tomcat devs have never given
> much ,(any?) weight to arguments made on that basis.
>
> The XXS might be valid. I assume the tool provided a sample URL you could
> use to validate the finding. That should point you in the right direction
> but feel free to ask here if more help is required.
>
> Mark
>
>
> >--
> >JHHL
> >
> >-
> >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 audit raises questions (Tomcat 7.0.93)

[Martynas Jusevičius]

Hi,

why should DELETE or OPTIONS not be enabled? They are standard HTTP methods.

On Tue, Mar 17, 2020 at 11:05 PM James H. H. Lampert
 wrote:
>
> Ladies and Gentlemen:
>
> One of our customers did a security audit on the Tomcat server we
> maintain on their system, and it found a few issues:
>
> First, it found a cross-site scripting vulnerability.
>
> Second, it found the HTTP DELETE method enabled.
>
> Third, it found a click-jacking vulnerability.
>
> Fourth, it found the HTTP OPTIONS method enabled.
>
> Back in October, the click-jacking vulnerability came up on another
> customer box; I've found the thread, and just now set up the filter and
> filter-mapping in conf/web.xml, so that is hopefully taken care of in
> the next restart.
>
> But I have no idea what to do about the cross-site scripting
> vulnerability, or the DELETE and OPTIONS methods, and I'm having trouble
> understanding the materials I've found.
>
> --
> JHHL
>
> -
> 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: Client cert auth on demand

[Martynas Jusevičius]

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 s

Re: Client cert auth on demand

[Martynas Jusevičius]

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 t

Re: Client cert auth on demand

[Martynas Jusevičius]

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 nginx listening on?
> > >>
> > >> What port is Tomcat listening on?
> > >>
> > >> I assume the client connects directly to nginx.
> > >>
> > >> 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: Client cert auth on demand

[Martynas Jusevičius]

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 nginx listening on?
> >>
> >> What port is Tomcat listening on?
> >>
> >> I assume the client connects directly to nginx.
> >>
> >> 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: Client cert auth on demand

[Martynas Jusevičius]

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

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 nginx listening on?
>
> What port is Tomcat listening on?
>
> I assume the client connects directly to nginx.
>
> 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: Client cert auth on demand

[Martynas Jusevičius]

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.

On Thu, Feb 27, 2020 at 11:52 AM Martynas Jusevičius
 wrote:
>
> Tomcat is deep within the Docker image configured with a single
> connector and a single ROOT webapp, so it's easier to deploy a second
> container than to add a second connector or context :)
>
> Thanks for your help.
>
>
> On Thu, Feb 27, 2020 at 11:36 AM Mark Thomas  wrote:
> >
> > On 27/02/2020 10:28, Martynas Jusevičius wrote:
> > > Yes, that could be an option. Or, since we're on Docker, a second
> > > instance of the webapp on a different port would be easier.
> > >
> > > But we would need to add some URL rewriting proxy before that
> > > connector to strip that port number to make the webapp see the
> > > canonical URLs. That should be doable with nginx which we are using
> > > anyway.
> > >
> > > So essentially 2 webapps on different ports, one configured without
> > > the clientAuth for the end-users, and one with clientAuth for the API
> > > access, correct?
> >
> > It depends on what you can / want to change.
> >
> > The approach you describe should work.
> >
> > If you can change the clients, a second Connector for the same
> > Service/Engine/Host/Context is all that should be required.
> >
> > Depending on the URLs used, you might be able to deploy two versions of
> > the web application to different Contexts, remap the internal servlets
> > and still have clients see the same URLs. In that case you could move
> > the client auth requirement to the web application.
> >
> > There are quite a few options. It really comes down to want you can
> > control, and what is easiest for you to change.
> >
> > Mark
> >
> >
> > >
> > > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas  wrote:
> > >>
> > >> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> > >>> Hi list,
> > >>>
> > >>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> > >>> end-user facing webapp but also as a REST API which authenticates
> > >>> using client certificates. The same URLs serve both purposes, however
> > >>> only administrators are using the API.
> > >>>
> > >>> The Connector is configured using clientAuth="want".
> > >>> This works fine with API calls which are run from shell scripts.
> > >>> In the browser however it prompts a certificate selection (if there
> > >>> are any client certs). This would not be a problem if the webapp would
> > >>> not be user-facing, but since it is the certificate prompt can be
> > >>> confusing to many users and increase our bounce rate.
> > >>>
> > >>> I'm looking for some workaround that would not require changing the
> > >>> whole design. For example asking for the client cert only when a
> > >>> certain flag is set, such as a query param or request header.
> > >>> Or somehow not asking for it but still accepting it :) But I guess
> > >>> that's not how TLS works...
> > >>>
> > >>> Any ideas? Thanks.
> > >>
> > >> Can you configure a separate connector on a different port for the shell
> > >> scripts to use?
> > >>
> > >> 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: Client cert auth on demand

[Martynas Jusevičius]

Tomcat is deep within the Docker image configured with a single
connector and a single ROOT webapp, so it's easier to deploy a second
container than to add a second connector or context :)

Thanks for your help.


On Thu, Feb 27, 2020 at 11:36 AM Mark Thomas  wrote:
>
> On 27/02/2020 10:28, Martynas Jusevičius wrote:
> > Yes, that could be an option. Or, since we're on Docker, a second
> > instance of the webapp on a different port would be easier.
> >
> > But we would need to add some URL rewriting proxy before that
> > connector to strip that port number to make the webapp see the
> > canonical URLs. That should be doable with nginx which we are using
> > anyway.
> >
> > So essentially 2 webapps on different ports, one configured without
> > the clientAuth for the end-users, and one with clientAuth for the API
> > access, correct?
>
> It depends on what you can / want to change.
>
> The approach you describe should work.
>
> If you can change the clients, a second Connector for the same
> Service/Engine/Host/Context is all that should be required.
>
> Depending on the URLs used, you might be able to deploy two versions of
> the web application to different Contexts, remap the internal servlets
> and still have clients see the same URLs. In that case you could move
> the client auth requirement to the web application.
>
> There are quite a few options. It really comes down to want you can
> control, and what is easiest for you to change.
>
> Mark
>
>
> >
> > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas  wrote:
> >>
> >> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> >>> Hi list,
> >>>
> >>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> >>> end-user facing webapp but also as a REST API which authenticates
> >>> using client certificates. The same URLs serve both purposes, however
> >>> only administrators are using the API.
> >>>
> >>> The Connector is configured using clientAuth="want".
> >>> This works fine with API calls which are run from shell scripts.
> >>> In the browser however it prompts a certificate selection (if there
> >>> are any client certs). This would not be a problem if the webapp would
> >>> not be user-facing, but since it is the certificate prompt can be
> >>> confusing to many users and increase our bounce rate.
> >>>
> >>> I'm looking for some workaround that would not require changing the
> >>> whole design. For example asking for the client cert only when a
> >>> certain flag is set, such as a query param or request header.
> >>> Or somehow not asking for it but still accepting it :) But I guess
> >>> that's not how TLS works...
> >>>
> >>> Any ideas? Thanks.
> >>
> >> Can you configure a separate connector on a different port for the shell
> >> scripts to use?
> >>
> >> 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: Client cert auth on demand

[Martynas Jusevičius]

Yes, that could be an option. Or, since we're on Docker, a second
instance of the webapp on a different port would be easier.

But we would need to add some URL rewriting proxy before that
connector to strip that port number to make the webapp see the
canonical URLs. That should be doable with nginx which we are using
anyway.

So essentially 2 webapps on different ports, one configured without
the clientAuth for the end-users, and one with clientAuth for the API
access, correct?

On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas  wrote:
>
> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> > Hi list,
> >
> > I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> > end-user facing webapp but also as a REST API which authenticates
> > using client certificates. The same URLs serve both purposes, however
> > only administrators are using the API.
> >
> > The Connector is configured using clientAuth="want".
> > This works fine with API calls which are run from shell scripts.
> > In the browser however it prompts a certificate selection (if there
> > are any client certs). This would not be a problem if the webapp would
> > not be user-facing, but since it is the certificate prompt can be
> > confusing to many users and increase our bounce rate.
> >
> > I'm looking for some workaround that would not require changing the
> > whole design. For example asking for the client cert only when a
> > certain flag is set, such as a query param or request header.
> > Or somehow not asking for it but still accepting it :) But I guess
> > that's not how TLS works...
> >
> > Any ideas? Thanks.
>
> Can you configure a separate connector on a different port for the shell
> scripts to use?
>
> 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

Client cert auth on demand

[Martynas Jusevičius]

Hi list,

I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
end-user facing webapp but also as a REST API which authenticates
using client certificates. The same URLs serve both purposes, however
only administrators are using the API.

The Connector is configured using clientAuth="want".
This works fine with API calls which are run from shell scripts.
In the browser however it prompts a certificate selection (if there
are any client certs). This would not be a problem if the webapp would
not be user-facing, but since it is the certificate prompt can be
confusing to many users and increase our bounce rate.

I'm looking for some workaround that would not require changing the
whole design. For example asking for the client cert only when a
certain flag is set, such as a query param or request header.
Or somehow not asking for it but still accepting it :) But I guess
that's not how TLS works...

Any ideas? Thanks.


Martynas
atomgraph.com

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

Re: Tomcat app within docker container

[Martynas Jusevičius]

Why build the webapp outside Docker? It means that docker build is not
enough to give you an image, it needs some extra steps beforehand.

On Fri, Jan 10, 2020 at 12:47 PM Alex K  wrote:
>
> Just to follow-up on this in case it will be useful to anyone, I managed to
> use also the official tomcat image. I had to amend my .war files and use
> the openjdk:8-jdk version instead of openjdk:11-jdk.
>
> I have used the following Docker files to prepare my custom tomcat image
> (so as to have tomcat home at /opt/tomcat) and then deployed the final app
> as following:
>
> Got openjdk:8-jdk Docker file from:
> https://github.com/docker-library/tomcat/blob/807a2b4f219d70f5ba6f4773d4ee4ee155850b0d/8.5/jdk8/openjdk/Dockerfile
> Amended the tomcat home to /opt/tomcat.
>
> Then deployed the app using the following Docker file:
>
> FROM tomcat:custom
> USER root
> ENV CATALINA_HOME /opt/tomcat
> ENV PATH $CATALINA_HOME/bin:$PATH
> RUN mkdir -p "$CATALINA_HOME"
> WORKDIR $CATALINA_HOME
> ADD iforms_files/app.war $CATALINA_HOME/webapps/
> ADD iforms_files/orbeon.war $CATALINA_HOME/webapps/
> ADD iforms_files/server.xml $CATALINA_HOME/conf/
> ADD iforms_files/mariadb-java-client-2.4.1.jar $CATALINA_HOME/lib
> ADD iforms_files/setenv.sh $CATALINA_HOME/bin/
> EXPOSE 8443
> CMD ["catalina.sh", "run"]
>
> I also tried the alpine versions:
> https://hub.docker.com/layers/openjdk/library/openjdk/8-jre-alpine3.9/images/sha256-ea81da311d33e052eeea34336018434bdc50596100f9c623193867faa291b284
>
> by using the same Dockerfile (by pointing to the custom built image FROM
> tomcat:alpine) I was able to deploy same app successfully reaching image
> size 281MB instead of 660MB with the default tomcat image.
>
>
>
>
> On Fri, Jan 10, 2020 at 11:52 AM Alex K  wrote:
>
> > Hi,
> >
> > On Thu, Jan 9, 2020 at 7:50 PM Mark Eggers 
> > wrote:
> >
> >> Alex,
> >>
> >> On 1/9/2020 8:51 AM, Alex K wrote:
> >> > Hi all,
> >> >
> >> > I have two .war files that when deployed at a plain Debian 9 VM are
> >> working
> >> > fine.
> >> > I have prepared a docker file so as to deploy the same apps within a
> >> docker
> >> > container and for some reason one of the apps is not loading due to some
> >> > error.
> >> >
> >> > Dockerfile:
> >> > FROM debian:latest
> >> > USER root
> >> >
> >> > ENV CATALINA_HOME /opt/tomcat
> >> > ENV PATH $CATALINA_HOME/bin:$PATH
> >> > RUN mkdir -p "$CATALINA_HOME"
> >> > WORKDIR $CATALINA_HOME
> >> >
> >> > # Install packages
> >> > RUN apt update && apt install default-jdk -y && groupadd tomcat &&
> >> useradd
> >> > -s /bin/false -g tomcat -d $CATALINA_HOME tomcat
> >> > COPY apache-tomcat-8.5.50.tar.gz /tmp/
> >> >
> >> > RUN tar xzvf /tmp/apache-tomcat-8.5.50.tar.gz -C /opt/tomcat
> >> > --strip-components=1
> >> >
> >> > ADD app.war $CATALINA_HOME/webapps/
> >> > ADD orbeon.war $CATALINA_HOME/webapps/
> >> > ADD server.xml $CATALINA_HOME/conf/
> >> > ADD web.xml $CATALINA_HOME/conf/
> >> > ADD mariadb-java-client-2.4.1.jar $CATALINA_HOME/lib
> >> > ADD setenv.sh $CATALINA_HOME/bin/
> >> >
> >> > RUN chgrp -R tomcat $CATALINA_HOME && \
> >> > chown -R tomcat webapps/ work/ temp/ logs/ && \
> >> > chmod -R g+r conf && \
> >> > chmod g+x conf && \
> >> > chmod 750 $CATALINA_HOME/bin/setenv.sh && \
> >> > rm -f /tmp/apache-tomcat-8.5.50.tar.gz;
> >> >
> >> > EXPOSE 8443
> >> > CMD ["catalina.sh", "run"]
> >> >
> >> > I have tried also several other ways, by using directly other docker
> >> tomcat
> >> > images everytime resulting with some error.
> >> >
> >> > The error I am getting now is:
> >> >
> >> > 10:21:32.201 WARN  c.h.c.c.s.CubaXmlWebApplicationContext  - Exception
> >> > encountered during context initialization - cancelling refresh attempt:
> >> > org.springframework.beans.factory.BeanCreationException: Error creating
> >> > bean with name 'org.springframework.security.filterChains': Cannot
> >> resolve
> >> > reference to bean
> >> > 'org.springframework.security.web.DefaultSecurityFilterChain#0' while
> >> > setting bean property 'sourceList' with key [0]; nested exception is
> >> > org.springframework.beans.factory.BeanCreationException: Error creating
> >> > bean with name
> >> > 'org.springframework.security.web.DefaultSecurityFilterChain#0': Cannot
> >> > create inner bean '(inner bean)#27690bd5' of type
> >> >
> >> [org.springframework.security.web.authentication.www.BasicAuthenticationFilter]
> >> > while setting constructor argument with key [4]; nested exception is
> >> > org.springframework.beans.factory.BeanCreationException: Error creating
> >> > bean with name '(inner bean)#27690bd5': Cannot resolve reference to bean
> >> > 'clientAuthenticationEntryPoint' while setting constructor argument;
> >> nested
> >> > exception is org.springframework.beans.factory.BeanCreationException:
> >> Error
> >> > creating bean with name 'clientAuthenticationEntryPoint' defined in
> >> class
> >> > path resource [com/haulmont/addon/restapi/rest-dispatcher-spring.xml]:
> >> > Instantiation of bea

Re: [OT] Tomcat app within docker container

[Martynas Jusevičius]

Forget Kubernetes for now :)

My recipe is using a multi-stage build. Very crudely:

FROM maven as maven
# build your webapp into a .war
mvn clean install

FROM tomcat
COPY --from=maven /webapp/target/ROOT webapps/ROOT/

It copies the whole folder from the build directory rather than the .war file.
Here is an example:
https://github.com/AtomGraph/LinkedDataHub/blob/master/Dockerfile

It does not use tomcat image directly but rather an intermediary image
which adds config as ENV capabilities as well as LetsEncrypt
certificates:
https://hub.docker.com/r/atomgraph/letsencrypt-tomcat/

You might also want to take a look at the entrypoint script which is a
bit more involved:
https://github.com/AtomGraph/LinkedDataHub/blob/master/platform/entrypoint.sh

Look at the container as a large function. Minimize the number of
inputs to it - generate all the configs that can be generated and
execute the init actions within Dockerfile and/or entrypoint. Mount
the rest from host as volumes, under Tomcat's webapps/ROOT (assuming
you're Dockerizing one webapp).

Martynas
atomgraph.com

On Thu, Jan 9, 2020 at 8:32 PM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Pater,
>
> On 1/9/20 12:39 PM, logo wrote:
> >> Am 09.01.2020 um 17:51 schrieb Alex K :
> >>
> >> Hi all,
> >>
> >> I have two .war files that when deployed at a plain Debian 9 VM
> >> are working fine. I have prepared a docker file so as to deploy
> >> the same apps within a docker container and for some reason one
> >> of the apps is not loading due to some error.
> >>
> >> Dockerfile: FROM debian:latest
> >
> > Why not using any of the different flavored tomcat images?
> >
> > https://hub.docker.com/_/tomcat 
> >
> > You get a working jdk (oracle, adopt, openjdk) and don’t have to
> > build the system yourself. That may help to get the base running
> > and then copy your file to the correct spots.
>
> If you've got experience with Docker, I'd love for someone to put
> together a post/presenation/whatever which addresses this question:
>
> I've got an application that I deploy to Tomcat on a traditional
> server; How do I Dockerize that?
>
> Specifically, I'd like more than just "well, docker-compose with your
> WAR file and put it in the right place" because we all know that there
> are plenty of configuration files, etc. that don't work well with a
> WAR file, etc.
>
> So maybe this bleeds into "well, if you want to use Docker, maybe you
> want to consider Kubernetes for configuration" and then explain how
> you might move some of your server/application configuration into
> Kubernetes (or similar). I'd like to understand how to package-up
> things like this to be able to eventually use something like AWS's
> auto-scaling.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4Xf6sACgkQHPApP6U8
> pFgobg//Zf5fQ5RqqNDYRDk8KFuS7QWmsZWxUez/waeEbrLW0z/iBRYaIDf63dDs
> G6/XOPAKov5K4jWxLxTeUY/GUVklwdqy8mGnQJwEmBOlFrMqidfrYZEbx4b6Us1o
> /GiAch2QUFhflaZ7DzSjxLYosMdReiQRl4PXnLVxNUQ7jB7aRaYRMwXgjCJGc66b
> PXJSUamYhngIlV4ZYB23ACJsbUlaacsyiYdXOJNSuip/xb8atz547KuGT7shCT0P
> QqJMNDD91KHWBtgrldkO9pb6zYMpwCUxf5PE9jpgk6U6MDlXeXF+HGEnYY6PFxwV
> kJfsPt2JUIC8Coo7ydkboxUgSQ16xvV6/PvhAdUGiaadS+WF4ZullveqSyNVHBQw
> dQI563oQYZ1qfh8zcHeZdsb7TLIaVh9Vx2Vn/+XN1bA1tcvjJx+Pz0fEHjtTy8Q+
> JW2nLIV2ZdbpsdHi0FjdIWIXscg+EyVMUiPx+qmpVyFA3Al7GWLc1h7yQic+hsuT
> oscRQf2crbu2tpPBBRP5YodtcAtOOvxbbRsQnALxKuBhBDmFzdl4taPTXlko6Kqc
> b1C/onqwrDlVPKwySPWFU43rTCLImD0L7eGCDxIzDX5z/HbGahtvYxKXf/Jpg7Sl
> lZuGlyhIIgRoWZF3utUsI11YjRsmRFme0EtfpMdBz/Xb4v/9YeU=
> =PK8y
> -END PGP SIGNATURE-
>
> -
> 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: HTTP to HTTPS redirect not happening

[Martynas Jusevičius]

Richard,

I think the rule goes that you should avoid touching server.xml for
something that web.xml can do.

On Sun, Jul 21, 2019 at 4:40 AM Richard Huntrods  wrote:
>
> I apologise for top posting in advance, but just a quick update and
> quicker question...
>
> After Konstantin found my typo, I tried editing the global web.xml file
> (/conf/web.xml) . In my case, this is actually the file I want based on
> the behaviour described by Konstantin as this entire tomcat instance is
> for this one application and it's static web pages, so *everything*
> needs to have the redirect.
>
> After fixing the typo, I tried it again and it works perfectly.
>
> So now I have two ways to accomplish what I want:
> 1. Edit /conf/web.xml and add the lines.
>
> 2. Edit server.xml and add the RewriteValve line, then create
> rewrite.config in /conf/Catalina/localhost.
>
> So my question - which is considered "more elegant" or better, more
> appropriate appoach - the valve or the change to web.xml?
>
> I'm leaning towards the valve simply because I kind of like the whole
> concept of valves, but if editing web.xml is just as good... ?
>
> Thanks,
>
> -Richard
>
>
> On 7/20/2019 2:08 PM, Richard Huntrods wrote:
> > Sorry for top-posting. It's the default with my mail program
> > (thunderbird)...
> >
> > On 7/20/2019 11:27 AM, Konstantin Kolinko wrote:
> >> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods :
> >>> OK. That was really weird.
> >>>
> >>> As I said in my message, following the directions on the web did NOT
> >>> work. It didn't force redirection from http to https.
> >>>
> >>> What it DID end up doing was to kill the tomcat servlet application.
> >>> Before the change it was working fine, and after the change it would
> >>> only generate a 404 page.
> >>>
> >>> I reverted to the original /conf/web.xml, restarted tomcat and the
> >>> servlet application is back up and running perfectly.
> >>>
> >>> So this code in /conf/web.xml affected the servlet but not the ROOT
> >>> static web pages.
> >> 1. The web.xml file and its behavior are defined in the Servlet
> >> Specification.
> >>
> >> Some random instructions on the net have to be used carefully.
> >>
> >> 2. The web.xml file is the one in your web application
> >> (WEB-INF/web.xml).
> >>
> >> The /conf/web.xml file provides defaults for all web applications, and
> >> SHOULD not be edited. (The /conf/context.xml should not be exited as
> >> well. That is another frequent error.).
> >>
> >> Those defaults are merged with the web.xml file of your web
> >> application using merging rules defined in the Servlet Specification.
> >>
> >> There is an option, "logEffectiveWebXml" [1] that turns on logging of
> >> the merged web.xml file.
> > I still am having trouble understanding why the web application's
> > WEB-INF/web.xml would be the appropriate place to put the change when
> > I want to affect ROOT. I would have thought
> > webapps/ROOT/WEB-INF/web.xml would have been the correct one.
> >>
> >> 3. Beware of typos.
> >>
> >> The tag "" is misspelled.
> >
> > AARRR
> >
> > TYPOS
> >
> > And I checked that code several times before implementing it. Of
> > course it wouldn't work 'as designed'. Ouch.
> >
> > I can clearly see why 'fixing stuff' using that code would generate
> > the 404 errors I was seeing. That does prove I was editing the correct
> > web.xml files, at least. Since the typo was in the block that then
> > defined the url-pattern, messing that up would mess up everything.
> >
> > One person asked what the logs said. Nothing. Start up log was normal,
> > access log was normal.
> >
> >>
> >> There is an option, "xmlValidation" [1] that turns on automatic
> >> validation of web.xml against the XML schema specified in that file.
> >>
> >> (Personally, I usually run with
> >> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
> >> and that turns "xmlValidation" on as well).
> >>
> >> 4. Top-posting is bad.
> >
> > Again, sorry. In the end I solved it using a Rewritevalve instead of
> > web.xml, and I think that may be the more elegant solution. Certainly
> > it's cleaner - edit server.xml and add one file, rewrite.config. That
> > takes care of everywhere; both the static pages I started wanting to
> > fix, and also the servlet application which I discovered could be
> > forced to run http when I was testing. This fixes all.
> >
> > One last point. I started this particular application for a client
> > back in early 2001. At that time I was considered a maverick for
> > choosing open source (Tomcat, MySQL) over the then-ubiquitous
> > proprietary solutions "everyone" was using. I even got to speak at
> > Unix user groups at the time, and even spoke at a CIPS meeting in
> > August 2001 (Montreal, PQ, Canada) on the use of open source for
> > enterprise solutions.
> >
> > Mostly folks simply didn't want to believe it could be done.
> >
> > Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the
> > ubiquitous choices, with proprietary so

Re: OT: Tomcat on AWS for Dummies

[Martynas Jusevičius]

My advice when it comes to making your setup environment-agnostic:
Docker'ize it.

I haven't used Docker on AWS, but once you have an image running
locally you can be 98% sure it's gonna run on the server (e.g.
mounting files from host can cause some differences still, so best to
avoid that).

See if it makes sense: https://aws.amazon.com/docker/

On Fri, Jul 19, 2019 at 8:39 PM Jerry Malcolm  wrote:
>
> I have had a dedicated hosted environment with WAMP and Tomcat for over
> 15 years.  I'm very familiar with everything related to that
> environment... apache http, mysql, dns server, the file system, JAMES,
> and all of my management scripts that I've accumulated over the years.
> Everything is in the same box and basically on the same desktop.  But
> now I have a client that has needs that are best met in an AWS
> environment.  I understand just enough AWS to be dangerous, which is not
> much  I do know that it's a bunch of different modules, and I
> believe I lose the direct file system access.  I've watched an AWS intro
> video and a couple of youtube videos on setting up TC in AWS.  But they
> always starts with "now that you have your AWS environment set
> up".   I am looking for something that explains the big picture of
> migrating an existing WAMP+TC to AWS.  I am not so naive to think that
> there won't be significant rip-up to what I have now.  But I don't want
> to do unnecessary rip-up just because I don't understand where I'm
> heading.  Basically, I don't know enough to know what I don't know
> But I need to start planning ahead and learning soon if I'm going to
> have any disasters in my code where I might have played it too loose
> with accessing the file system directly in my dedicated environment.
>
> Has anyone been down this path before and could point me to some
> tutorials targeted to migrating WAMP+TC to AWS? Or possible hand-hold me
> just a little...? I'm a pretty quick learner.  I just don't know where
> to start.
>
> Thanks.
>
> Jerry
>
>
> -
> 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: Modify web.xml in production war file

[Martynas Jusevičius]

André,

installers are platform-specific, Docker images are not. You do the changes
within the image which is Linux-based, and then deploy the image on any
host platform that supports Docker. Moreover you’re able to deploy
different versions of Tomcat (or other image) on the same system.

Most images have an entrypoint, which is the shell script making changes to
server.xml in this case:
https://github.com/AtomGraph/letsencrypt-tomcat/blob/master/entrypoint.sh


On Wed, 17 Jul 2019 at 02.34, André Warnier (tomcat)  wrote:

> On 16.07.2019 19:54, Martynas Jusevičius wrote:
> > Grigor,
> >
> > I think this is a use case that Docker containers at least partially
> > address.
> >
> > I find deploying containers way easier to share/deploy and more
> > platform-independent than WAR files.
> >
> > I’ve created a Tomcat-based image that accepts ENV variables and modifies
> > server.xml using their values:
> > https://github.com/AtomGraph/letsencrypt-tomcat
> >
> > I think you should be able to do the same with web.xml.
>
> I have not seen your solution. But a question comes to mind : does this
> not just move the
> problem, from tomcat to the Docker container then ?
>
> Why not provide a (shell ? perl ?) installer/updater script, along with
> the application
> WAR, which modifies the application's web.xml (or the server's web.xml) in
> function of
> some site-specific parameter file, which is located somewhere outside the
> tomcat
> directories and remains there ?
>
>
>
> >
> > Martynas
> >
> > On Fri, 12 Jul 2019 at 21.44, Grigor Aleksanyan
> >  wrote:
> >
> >> Hi Everyone,
> >>
> >> We have been shipping web application with war packaging in our
> production
> >> builds which contains a web.xml with few security sections.
> >> This web.xml defines security constraints that are in most cases not
> what
> >> the final deployment uses. This means that to update the war we need to
> >> save new web.xml somewhere, copy the new war, run the server so that it
> >> extracts the war, then shut down the server and copy web.xml back. This
> is
> >> a headache for our cloud based web services upgrade as well as in all
> other
> >> deployment scenarios, including tests.
> >>
> >> To facilitate deployment we've added a new packaging of another war
> file,
> >> which is the same as our original war but its web.xml doesn't contain
> any
> >> security sections.
> >> With an empty web.xml (in terms of security), the security can be
> defined
> >> via server's conf/web.xml, where it belongs, since the security is in
> >> reality defined by the server rather than the war application.
> >> It would be great if we could just replace our default web.xml but if
> some
> >> user uses our default web.xml, they would become unsecured after an
> >> upgrade, so we opted for a separate war.
> >>
> >> Do you guys see any other way of achieving what we aim to achieve with
> the
> >> new war file with default web.xml (backwards compatibility is a
> constraint
> >> in our case)?
> >> Maybe there is a way of ignoring security sections in the war or we can
> >> make it configurable in the code based on some config/env variable?
> >>
> >> Please let me know if you have any considerations about this, any help
> >> would be appreciated.
> >>
> >> Thank you,
> >> -Grigor
> >>
> >> --
> >>
> >>
> >> *
> >> *
> >> *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY
> >> CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.
> IT
> >> IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED
> >> REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE
> >> INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY
> E-MAIL
> >> OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS
> MESSAGE
> >> FROM YOUR SYSTEM.
> >>
> >> E-SIGNATURE NOTICE: Unless specifically set forth
> >> herein, the transmission of this communication is not intended to be a
> >> legally binding electronic signature, and no offer, commitment or assent
> >> on
> >> behalf of OneMarketData, LLC is expressed or implied by the sending of
> >> this
> >> email, or any attachments hereto.
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Modify web.xml in production war file

[Martynas Jusevičius]

Grigor,

I think this is a use case that Docker containers at least partially
address.

I find deploying containers way easier to share/deploy and more
platform-independent than WAR files.

I’ve created a Tomcat-based image that accepts ENV variables and modifies
server.xml using their values:
https://github.com/AtomGraph/letsencrypt-tomcat

I think you should be able to do the same with web.xml.

Martynas

On Fri, 12 Jul 2019 at 21.44, Grigor Aleksanyan
 wrote:

> Hi Everyone,
>
> We have been shipping web application with war packaging in our production
> builds which contains a web.xml with few security sections.
> This web.xml defines security constraints that are in most cases not what
> the final deployment uses. This means that to update the war we need to
> save new web.xml somewhere, copy the new war, run the server so that it
> extracts the war, then shut down the server and copy web.xml back. This is
> a headache for our cloud based web services upgrade as well as in all other
> deployment scenarios, including tests.
>
> To facilitate deployment we've added a new packaging of another war file,
> which is the same as our original war but its web.xml doesn't contain any
> security sections.
> With an empty web.xml (in terms of security), the security can be defined
> via server's conf/web.xml, where it belongs, since the security is in
> reality defined by the server rather than the war application.
> It would be great if we could just replace our default web.xml but if some
> user uses our default web.xml, they would become unsecured after an
> upgrade, so we opted for a separate war.
>
> Do you guys see any other way of achieving what we aim to achieve with the
> new war file with default web.xml (backwards compatibility is a constraint
> in our case)?
> Maybe there is a way of ignoring security sections in the war or we can
> make it configurable in the code based on some config/env variable?
>
> Please let me know if you have any considerations about this, any help
> would be appreciated.
>
> Thank you,
> -Grigor
>
> --
>
>
> *
> *
> *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY
> CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.  IT
> IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED
> REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE
> INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY E-MAIL
> OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS MESSAGE
> FROM YOUR SYSTEM.
>
> E-SIGNATURE NOTICE: Unless specifically set forth
> herein, the transmission of this communication is not intended to be a
> legally binding electronic signature, and no offer, commitment or assent
> on
> behalf of OneMarketData, LLC is expressed or implied by the sending of
> this
> email, or any attachments hereto.
>
>

Re: TLS client cert clarification

[Martynas Jusevičius]

In my experience with 8.x -- on all requests.

On Fri, Jul 12, 2019 at 3:06 AM Wilmoth, Jon
 wrote:
>
> I was hoping to get some clarification on when to expect client x509 certs in 
> http requests where the Tomcat server (v9.x) has been configured to “want” or 
> “need” client auth.  
> https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
>  says:
>
> “If there is an SSL certificate associated with the request, it must be 
> exposed by the servlet container to the servlet programmer as an array of 
> objects of type java.security.cert.X509Certificate and accessible via a 
> ServletRequest attribute of javax.servlet.request.X509Certificate.”
>
> Is this only for the request that initiated the TLS handshake?  Or does this 
> mean it will be present on all requests (i.e. requests on a keep-alive 
> connection after the initial handshake) while the TLS connection is still 
> open?
>
> Thanks,
> Jon

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

Re: Redirecting to https URL when https port is accessed with http scheme

[Martynas Jusevičius]

Ettra,

see also this thread:
https://mail-archives.apache.org/mod_mbox/tomcat-users/201808.mbox/%3ccae35vmwcm9dkxmvabofgjb5d_oa07a6mrjxwcgknksbzgjh...@mail.gmail.com%3E

I did this with front nginx eventually.
On Sat, Oct 6, 2018 at 7:29 AM ettra lancelot  wrote:
>
> Thank you for the detailed answer, Chris.
>
> On Sat, Oct 6, 2018 at 2:41 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Etcy,
> >
> > On 10/5/18 14:57, ettra lancelot wrote:
> > > I would like to know whether it's possible to configure tomcat to
> > > automatically redirect to the https URL when https port is access
> > > using http scheme instead of https*.*
> >
> > There is no way to get Tomcat to do this for you right now.
> >
> > There is, however, the possibility of adding such a feature to Tomcat.
> >
> > If you make an HTTP request to Apache httpd on a TLS-enabled port,
> > you'll get a response that says "Looks like you made a mistake".
> >
> > In the past, that would have been a huge pain in the neck for Tomcat,
> > since the TLS handshake was handled *entirely* by the underlying
> > crypto system (e.g. JSSE or APR/OpenSSL). AIUI, that code has been
> > re-written and Tomcat is buffering everything internally and probing
> > the handshake, etc.
> >
> > It should therefore be possible to respond in the way you describe,
> > but I'm not sure how much appetite there is for issuing a redirect
> > rather than just an informational page such as the one httpd returns.
> >
> > Unfortunately, Bill is incorrect when he says that you can write a
> > Filter for this. No application code will ever see a connection over a
> > connection which failed a TLS handshake.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu304gACgkQHPApP6U8
> > pFgj9A//SR89S85mbNovDkiRLo/KzlAf64sNNd0RHSsrKkxnwnoGxMwFt2XVIJ5F
> > aNELyTf/mI0UPAyJw6D3W30pWVDtmqjyWe/Xc3YBKCTbDfruxUEGiW3rcSt1jVus
> > RmqirBN3baduSiVyF5CLktXr/82CfqQ0Z4XUtt6NK5Nh7Hz+l6Olt6D7VlP1fcpM
> > 29Q9vEuC5dkmdLoZYOuCleWtKeHOv96nk7pWvOq6P81VAk9SUcUEk9cbVhPosCYV
> > fdUf3ma8fwgJLLfz2LGZEf5Fdo4elRYTNI/OXTWQbJiuFg1umHURKjCoEhUXnzPf
> > FZY6mQr2OM3Yo/iLGBiVRAxrUAVEhXZjLEVE0DuPugDtb1JDX7bCZDKkz6HH+mXy
> > 8A8Ekm/A12I55StC2CMqLSzKErd1q06lT6Xt1y4z76IZe3O6LjGMFfIsTLRVI63w
> > QG1vF2pVDniXyGYozUwPuudJ7to/M9Z1Ls57RKXDXgw8QPxF7waM5vTQuiQDE/DP
> > ECJEnaVeGVtPeCekD8Me56ezAVDRFrDlQKcZD+8PguTGJGpIC7ubByCFgTp1PRZ0
> > GxNA732h7zwTO8hSYzDTbnswwK17MJjYAezjz6ulnw178hJYSd05WJtPA1I8E798
> > QmsCilXAdmp741/QjdE8cLkonmBZHrkE7tm09Jit34I9VlBg3as=
> > =wLba
> > -END PGP SIGNATURE-
> >
> > -
> > 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:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?

[Martynas Jusevičius]

I've solved this by removing the  completely and
doing a 301 redirect to https:// in nginx (which is in front of
Tomcat) instead:
https://nginx.org/en/docs/http/converting_rewrite_rules.html

Also added HTST header as suggested in this thread:
https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#HTTP_Header_Security_Filter

On Fri, Aug 17, 2018 at 8:24 PM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 8/17/18 11:49 AM, Mark Thomas wrote:
>> On 17/08/18 14:57, Christopher Schultz wrote:
>>> Mark,
>>>
>>> On 8/17/18 4:09 AM, Mark Thomas wrote:
>>>> On 16/08/18 13:40, Martynas Jusevičius wrote:
>>>>> Hi,
>>>>>
>>>>> my initial observations suggest, and SO post [1] seems to
>>>>> confirm, that when
>>>>>
>>>>> 
>>>>> CONFIDENTIAL
>>>>> 
>>>>>
>>>>> is specified on a security-constraint in web.xml, Tomcat does
>>>>> two things: 1. automatically redirects to HTTPS 2. appends
>>>>> Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00
>>>>> CET response headers
>>>>>
>>>>> Is that correct?
>>>
>>>> It is broader than that. Tomcat adds those headers to any
>>>> resource that is protected by any security constraint.
>>>
>>>>> I had added the CONFIDENTIAL because I want the redirect to
>>>>> HTTPS. What I don't want is Tomcat overriding my caching
>>>>> headers and effectively disabling browser caching.
>>>
>>>> Those headers shouldn't disable browser caching.
>>>
>>> Expires: 1970 certainly effectively disables browsed caching.
>>
>> My understanding was that the browser caches the resource but marks
>> it as stale which means it needs validation on the next request.
>
> That's essentially the same thing. The server can still return a 304
> response if the browser thinks it has an up-to-date copy, but it's
> still a round-trip to the server that might be avoided.
>
>>>> They will mean the client has to revalidate the request. How
>>>> relatively expensive that is will depend on the resources.
>>>
>>>>> Why in the world would those two things be conflated?
>>>
>>>> Security. Any resource protected by a security constraint
>>>> should not be stored in a shared cache else information
>>>> disclosure could occur.
>>>
>>> I'm curious, too: I can understand the "Cache-Control" header,
>>> but why the "Expires" one? What about some CSS file that can
>>> surely be cached by the browser?
>>
>> Looks like an HTTP/1.0 solution from a very short amount of
>> research. Revalidation for a static file shouldn't be too
>> expensive.
>>
>>> Is it possible for a servlet to override a single header -- say,
>>> the "Expires" header? It might be nice to have a facility to
>>> allow applications to override maybe just this one header (or,
>>> optionally, just one *other* header). I glossed-over the servlet
>>> spec and I don't see much in the way of proscriptions for
>>> precisely how to handle security-constraints e.g. when it comes
>>> to setting headers.
>>
>> It depends when the header is added. In this case the Authenticator
>> adds them before the filter chain is invoked so it should be
>> possible for an application to remove them.
>
> That's very good to know.
>
> There are very few headers that Tomcat automatically adds (at any
> stage). Could those be described somewhere including when/where they
> are added and whether they can be overridden?
>
> For example, I tried (and failed) to override the "Date" response
> header at some point while testing my "replay response" sample code.
> It might be nice to know that Tomcat adds (overwrites) that header
> fairly late in the process.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt3EskACgkQHPApP6U8
> pFg9TQ/9E2lLXq8ZjBBU1bMvd66jHJ4RgruQYG3sViaTA6xkk0zF1YWmAH0fquZV
> Xnid0102FteOZ7uqsMvzIRNywvnuL6S1nq9ItIvBMIQofZZnTnu275Xetq6smOHR
> j+o51S1sq5WwFP1ypijnYwT1KHmc1eQ9XwubsxmWgxVw33nJNhfsLr2BWMs9xWsT
> lG+iHA1ArIxRjx/oTtjuZAXgyH2PsB5T91huOmrzeR9uXbXfUGj+/qCoS33KcMyq
> +qQT/iDFH/z6i0g50a95fl6dLb3Tizmpwk7xikhd4eZ+D05qJEQAH0Vnyff8a/NA
> leHjeouGgo0ZaSBGWByYDZno1q34QkwOUfv6UGaHD0fw21yGsxWt1mfo6jedHNQ3
> ZhXbEQMhM8uYIHYuKAaMcXSEbOvMkd7SsoqZGRzK6t1HptgtGN6NyRQA9U6hLT8I
> 5eGad3Bdx2nbnR7KDqcizJZ/Ulx5Be6XIQE4pncf2OLgfB6H3EkJ8FUkeU74i6W5
> se0z9vECh7zBxEAaCm0u7bVH1NK5zZKcOgPxzFvtHrkj7bnpBXcN9Qm6G1OkEfjG
> d7rxnQtzG/d38YL0LQy3VsMp+q0Va9sRSztKpmmSU+se2904R/mj4ITz3M7e6VTE
> 1+LhS4WSf4yriC7qmShd5d/CzDW3Pvz0S0uyoV5MduQWtBbnDbQ=
> =8Svp
> -END PGP SIGNATURE-
>
> -
> 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

[tomcat:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?

[Martynas Jusevičius]

Hi,

my initial observations suggest, and SO post [1] seems to confirm, that when


CONFIDENTIAL


is specified on a security-constraint in web.xml, Tomcat does two things:
1. automatically redirects to HTTPS
2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970
01:00:00 CET response headers

Is that correct?

I had added the CONFIDENTIAL because I want the redirect to HTTPS.
What I don't want is Tomcat overriding my caching headers and
effectively disabling browser caching.

Why in the world would those two things be conflated? And how do I
disable this header override behavior?

Does disableProxyCaching attribute need to be set to false to in order
to do that? [2]

I'm running the tomcat:8.0-jre8 on Docker.

[1] 
https://stackoverflow.com/questions/21829553/tomcat-security-constraint-impact-cache
[2] 
https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes

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

Re: Using existing LetsEncrypt certs with tomcat

[Martynas Jusevičius]

Paul,

see if this Docker setup could help:
https://github.com/AtomGraph/letsencrypt-tomcat

I also have nginx config that works with it.


Martynas
atomgraph.com



On Sat, Jan 6, 2018 at 7:46 PM, Paul Beard  wrote:

>
>
> > On Jan 4, 2018, at 1:53 AM, Mark Thomas  wrote:
> >
> > This might help.
> >
> > https://www.youtube.com/watch?v=I6TbMqH9WFg  watch?v=I6TbMqH9WFg>
> It was, along with the script (after a little search and replace on / and
> \).
>
> I have just walked through this and worked alongside with the script. All
> seemed to go well, nice to see that experienced presenters fumble passwords
> and forget to clean out old files, but I’m not quite there. Learned a few
> things about setting defaults in openssl.cnf do I don’t have to retype and
> get it wrong from one step to the next (did I do uppercase or lowercase
> last time?).
>
> The log shows that tomcat is running, I see it listening on port 8443, but
> it times out. It’s literally 10 feet from me, one hop via my wireless
> router, so I’m pretty confident it’s not a network error.
>
> Is there a way to run tomcat with no encryption at all? The system it runs
> on sits on a table across the room and is behind a router on a private
> network. I may never need encryption if the application itself doesn’t
> work. So the fact that this is so fiddly to get working chafes a bit. The
> only reason I need tomcat is to run another application which has its own
> configuration/documentation/deployment issues and I can’t get to that til
> this works. If my nginx instance is encrypted, do I need tomcat to be as
> well? Can I forward requests to it that are already encrypted, all through
> nginx?
>
> What might be useful, as well, is a similar script, with or without video,
> that explicitly details using LetsEncrypt certs with tomcat. This makes
> tomcat more accessible and perhaps increases the use of reliable encryption
> for more sites and services.

Re: Am I reinventing the wheel to get letsencrypt certs for Tomcat

[Martynas Jusevičius]

I think Tomcat 9 suppors PEM files directly, but if you want to use PKCS12,
this might help:
https://github.com/AtomGraph/letsencrypt-tomcat/blob/master/entrypoint.sh#L33

On Fri, Oct 27, 2017 at 1:22 PM, Don Flinn  wrote:

> I am writing a Java program to get a certificate from letsencrypt put it in
> a keystore and ftp it to my Tomcat 9 or any version running on Amazon Web
> Services or any place you can fip to.  I intended to contribute it to
> Tomcat users.  It's about 80% done. I am able to get the letsencrypt
> certificate and do the ftping.   Recent mail indicates that this has
> already been done.  If so how can I get the existing code?  No sense
> duplicating existing work.
>
> Don
>

Re: Invalid characters in request header

[Martynas Jusevičius]

Well then you're out of luck. Everything is as expected though, at least on
your end -- client sends invalid request, gets error response. What else do
you need?

On Sat, Sep 9, 2017 at 12:13 PM, Yuval Schwartz 
wrote:

> Is that in my control? The url is not one that appears on my website, it's
> something that was manually written by some client.
>
> On Sat, Sep 9, 2017 at 1:12 PM, Martynas Jusevičius <
> marty...@atomgraph.com>
> wrote:
>
> > Tomcat is an HTTP sever, and if your client is sending invalid HTTP
> > requests, Tomcat is right to respond with 400. The solution is to fix the
> > client.
> >
> > On Sat, Sep 9, 2017 at 12:09 PM, Yuval Schwartz <
> yuval.schwa...@gmail.com>
> > wrote:
> >
> > > Hello Martynas, thanks.
> > >
> > > I'm not sure 404 is better than 400.
> > >
> > > Wouldn't it be preferable to validate the url before it has a chance to
> > > throw the exception?
> > > I guess my only reason for preferring this is because I don't want it
> > > crowding up my logs.
> > > I figure if I can filter it out beforehand then it's not really an
> > > exception? But I would be happy to hear thoughts on this as I'm still
> > > fairly new to programming. I'm not sure what is considered best
> practice
> > > here.
> > >
> > > Thanks.
> > >
> > > On Sat, Sep 9, 2017 at 12:24 PM, Martynas Jusevičius <
> > > marty...@atomgraph.com
> > > > wrote:
> > >
> > > > How is 404 beter than 400?
> > > >
> > > > On Sat, Sep 9, 2017 at 9:46 AM, Yuval Schwartz <
> > yuval.schwa...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Tomcat version:8.0.43
> > > > > jdk1.8.0_05
> > > > >
> > > > > Hello,
> > > > >
> > > > > I've asked a similar question in the past about illegal characters
> in
> > > the
> > > > > http request header (May 15, 2017).
> > > > >
> > > > > Certain users are able to send http requests to my server that
> > contain
> > > > the
> > > > > space character.
> > > > > This character is obviously not allowed. Tomcat recognizes it and
> > > throws
> > > > an
> > > > > IllegalArgumentException and a http response code 400 is returned
> to
> > > the
> > > > > client.
> > > > > From my logs:
> > > > >
> > > > >
> > > > >
> > > > > *Error parsing HTTP request header...*
> > > > > *java.lang.IllegalArgumentException: Invalid character found in
> the
> > > > > request
> > > > > target. The valid characters are defined in RFC 7230 and RFC 3986*
> > > > >
> > > > > Is there any way to validate the url before it reaches tomcat so
> > that I
> > > > can
> > > > > return a 404 if an invalid character is found in the url? I would
> > just
> > > > like
> > > > > to avoid exceptions being thrown where possible.
> > > > >
> > > > > Thank you.
> > > > >
> > > >
> > >
> >
>

Re: Invalid characters in request header

[Martynas Jusevičius]

Tomcat is an HTTP sever, and if your client is sending invalid HTTP
requests, Tomcat is right to respond with 400. The solution is to fix the
client.

On Sat, Sep 9, 2017 at 12:09 PM, Yuval Schwartz 
wrote:

> Hello Martynas, thanks.
>
> I'm not sure 404 is better than 400.
>
> Wouldn't it be preferable to validate the url before it has a chance to
> throw the exception?
> I guess my only reason for preferring this is because I don't want it
> crowding up my logs.
> I figure if I can filter it out beforehand then it's not really an
> exception? But I would be happy to hear thoughts on this as I'm still
> fairly new to programming. I'm not sure what is considered best practice
> here.
>
> Thanks.
>
> On Sat, Sep 9, 2017 at 12:24 PM, Martynas Jusevičius <
> marty...@atomgraph.com
> > wrote:
>
> > How is 404 beter than 400?
> >
> > On Sat, Sep 9, 2017 at 9:46 AM, Yuval Schwartz  >
> > wrote:
> >
> > > Tomcat version:8.0.43
> > > jdk1.8.0_05
> > >
> > > Hello,
> > >
> > > I've asked a similar question in the past about illegal characters in
> the
> > > http request header (May 15, 2017).
> > >
> > > Certain users are able to send http requests to my server that contain
> > the
> > > space character.
> > > This character is obviously not allowed. Tomcat recognizes it and
> throws
> > an
> > > IllegalArgumentException and a http response code 400 is returned to
> the
> > > client.
> > > From my logs:
> > >
> > >
> > >
> > > *Error parsing HTTP request header...*
> > > *java.lang.IllegalArgumentException: Invalid character found in the
> > > request
> > > target. The valid characters are defined in RFC 7230 and RFC 3986*
> > >
> > > Is there any way to validate the url before it reaches tomcat so that I
> > can
> > > return a 404 if an invalid character is found in the url? I would just
> > like
> > > to avoid exceptions being thrown where possible.
> > >
> > > Thank you.
> > >
> >
>

Re: Invalid characters in request header

[Martynas Jusevičius]

How is 404 beter than 400?

On Sat, Sep 9, 2017 at 9:46 AM, Yuval Schwartz 
wrote:

> Tomcat version:8.0.43
> jdk1.8.0_05
>
> Hello,
>
> I've asked a similar question in the past about illegal characters in the
> http request header (May 15, 2017).
>
> Certain users are able to send http requests to my server that contain the
> space character.
> This character is obviously not allowed. Tomcat recognizes it and throws an
> IllegalArgumentException and a http response code 400 is returned to the
> client.
> From my logs:
>
>
>
> *Error parsing HTTP request header...*
> *java.lang.IllegalArgumentException: Invalid character found in the
> request
> target. The valid characters are defined in RFC 7230 and RFC 3986*
>
> Is there any way to validate the url before it reaches tomcat so that I can
> return a 404 if an invalid character is found in the url? I would just like
> to avoid exceptions being thrown where possible.
>
> Thank you.
>

Re: letsencrypt integration?

[Martynas Jusevičius]

Hi,

we have made a Docker image that configures Tomcat with LE certs:
https://hub.docker.com/r/atomgraph/letsencrypt-tomcat/

It hasn't been tested in production though.

Martynas
atomgraph.com
On Thu, 24 Aug 2017 at 20.50, Chris Cheshire  wrote:

> Currently I am using httpd to handle SSL (because my certs are generated
> via LE) with all content being passed off to Tomcat 7 (investigating 8.5
> upgrade).
>
> I had a poke around on the archives and found mention of a talk on it in a
> conference in Miami.
>
>
> http://tomcat.10.x6.nabble.com/Dynamic-reloading-of-SSL-certificates-tt5059619.html#a5059673
>
> Did this happen? I looked in the Tomcat youtube channel and found a handful
> of videos from there, but nothing on LE. Is it something that is still in
> the "we'd like to find time to do it, but don't know who or when" phase, or
> something that is being worked on for Tomcat 9?
>

Re: [8.0.44] NPE when deploying to /manager/text/list with RemoteHostValve

[Martynas Jusevičius]

Hmm, strange. I tried "ping jenkins" from shell and it worked.
On Tue, 8 Aug 2017 at 04.19, Zemian Deng  wrote:

> Hi Martynas, you are getting NPE because "request.getRemoteHost()" is
> returning null value after you enableLookups! Maybe you have problem
> resolving hostname in your env? Try to disable the valve and test "<%=
> request.getRemoteHost() %>" in a simple jsp until you can get the right
> value before re-enable the valve again.
>
> --Zemian
>
> On Mon, Aug 7, 2017 at 11:46 AM, Martynas Jusevičius <
> marty...@atomgraph.com
> > wrote:
>
> > Hi,
> >
> > I'm deploying WAR from Jenkins Docker container to Tomcat Docker
> container.
> >
> > In server.xml I have enableLookups to enable DNS lookups
> >
> >  >connectionTimeout="2"
> >redirectPort="8443"
> >enableLookups="true"/>
> >
> > and in conf/Catalina/localhost/manager.xml I have
> >
> >  >  docBase="${catalina.home}/webapps/manager">
> >>  allow="jenkins" />
> > 
> >
> > There is also manager-script role and user in tomcat-users.xml but I
> won't
> > post it because authentication works.
> >
> > The issue is RemoteHostValve. If I comment the Valve out, deployment
> works.
> > If I enable it as shown here, in the localhost log I can see
> >
> > 07-Aug-2017 17:00:22.854 SEVERE [http-apr-8080-exec-1]
> > org.apache.catalina.core.StandardHostValve.invoke Exception Processing
> > /manager/text/list
> >  java.lang.NullPointerException
> > at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
> > at java.util.regex.Matcher.reset(Matcher.java:309)
> > at java.util.regex.Matcher.(Matcher.java:229)
> > at java.util.regex.Pattern.matcher(Pattern.java:1093)
> > at
> > org.apache.catalina.valves.RequestFilterValve.isAllowed(
> > RequestFilterValve.java:377)
> > at
> > org.apache.catalina.valves.RequestFilterValve.process(
> > RequestFilterValve.java:312)
> > at
> >
> org.apache.catalina.valves.RemoteHostValve.invoke(RemoteHostValve.java:84)
> > at
> > org.apache.catalina.core.StandardHostValve.invoke(
> > StandardHostValve.java:141)
> > at
> > org.apache.catalina.valves.ErrorReportValve.invoke(
> > ErrorReportValve.java:79)
> > at
> > org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> > AbstractAccessLogValve.java:620)
> > at
> > org.apache.catalina.core.StandardEngineValve.invoke(
> > StandardEngineValve.java:88)
> > at
> > org.apache.catalina.connector.CoyoteAdapter.service(
> > CoyoteAdapter.java:502)
> > at
> > org.apache.coyote.http11.AbstractHttp11Processor.process(
> > AbstractHttp11Processor.java:1132)
> > at
> > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
> > process(AbstractProtocol.java:684)
> > at
> > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.
> > run(AprEndpoint.java:2458)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> > TaskThread.java:61)
> > at java.lang.Thread.run(Thread.java:748)
> >
> >
> > Can anyone explain what the issue is and how to fix it?
> >
> > Thanks
> >
> > Martynas
> >
>

[8.0.44] NPE when deploying to /manager/text/list with RemoteHostValve

[Martynas Jusevičius]

Hi,

I'm deploying WAR from Jenkins Docker container to Tomcat Docker container.

In server.xml I have enableLookups to enable DNS lookups



and in conf/Catalina/localhost/manager.xml I have


  


There is also manager-script role and user in tomcat-users.xml but I won't
post it because authentication works.

The issue is RemoteHostValve. If I comment the Valve out, deployment works.
If I enable it as shown here, in the localhost log I can see

07-Aug-2017 17:00:22.854 SEVERE [http-apr-8080-exec-1]
org.apache.catalina.core.StandardHostValve.invoke Exception Processing
/manager/text/list
 java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
at java.util.regex.Matcher.reset(Matcher.java:309)
at java.util.regex.Matcher.(Matcher.java:229)
at java.util.regex.Pattern.matcher(Pattern.java:1093)
at
org.apache.catalina.valves.RequestFilterValve.isAllowed(RequestFilterValve.java:377)
at
org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:312)
at
org.apache.catalina.valves.RemoteHostValve.invoke(RemoteHostValve.java:84)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:502)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1132)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
at
org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2458)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)


Can anyone explain what the issue is and how to fix it?

Thanks

Martynas

Re: [8.5.16] SSLHostConfig certificateVerification="optionalNoCA" ignored?

[Martynas Jusevičius]

Actually I am using Tomcat on Docker:
https://hub.docker.com/_/tomcat/

I do not really know the answer to your question :/

On Sun, 30 Jul 2017 at 23.12, Mark Thomas  wrote:

> On 30/07/17 21:35, Martynas Jusevičius wrote:
> > Hey list,
> >
> > I need my webapp to accept all SSL client certificates and do its own
> > validation.
> >
> > I'm upgrading server.xml from the JSSE SSL Connector which used
> > clientAuth="want" and a custom trustManagerClassName in order to do that.
> >
> > The 8.5.16 docs indicate that this should be replaced with SSLHostConfig
> > certificateVerification="optionalNoCA". I have done, and also using
> OpenSSL
> > implementation now:
> >
> >  > protocol="org.apache.coyote.http11.Http11AprProtocol"
> >maxThreads="150" SSLEnabled="true" >
> >  className="org.apache.coyote.http2.Http2Protocol"
> > />
> > 
> >  certificateKeyFile="/usr/local/ssl/tomcat.key.pem"
> >  certificateFile="/usr/local/ssl/tomcat.cert.pem"
> >  type="RSA" />
> > 
> > 
> >
> > However, I'm getting an exception that shows my client certificate is
> > validated and rejected by Tomcat/OpenSSL:
> >
> > tomcat_1 | https-openssl-apr-8443-exec-3,
> handling
> > exception: javax.net.ssl.SSLHandshakeException:
> > sun.security.validator.ValidatorException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find
> > valid certification path to requested target
> > tomcat_1 | https-openssl-apr-8443-exec-3,
> > IOException in getSession():  javax.net.ssl.SSLHandshakeException:
> > sun.security.validator.ValidatorException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find
> > valid certification path to requested target
> > tomcat_1 | https-openssl-apr-8443-exec-3, called
> > close()
> > tomcat_1 | https-openssl-apr-8443-exec-3, called
> > closeInternal(true)
> >
> > Am I missing something? certificateVerification="optional" exhibits the
> > same behaviour.
>
> How is your tomcat-native binary built? If it has been built with OCSP
> support then neither of the optional verification options will work
> since OCSP validation will always fail.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

[8.5.16] SSLHostConfig certificateVerification="optionalNoCA" ignored?

[Martynas Jusevičius]

Hey list,

I need my webapp to accept all SSL client certificates and do its own
validation.

I'm upgrading server.xml from the JSSE SSL Connector which used
clientAuth="want" and a custom trustManagerClassName in order to do that.

The 8.5.16 docs indicate that this should be replaced with SSLHostConfig
certificateVerification="optionalNoCA". I have done, and also using OpenSSL
implementation now:








However, I'm getting an exception that shows my client certificate is
validated and rejected by Tomcat/OpenSSL:

tomcat_1 | https-openssl-apr-8443-exec-3, handling
exception: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
tomcat_1 | https-openssl-apr-8443-exec-3,
IOException in getSession():  javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
tomcat_1 | https-openssl-apr-8443-exec-3, called
close()
tomcat_1 | https-openssl-apr-8443-exec-3, called
closeInternal(true)

Am I missing something? certificateVerification="optional" exhibits the
same behaviour.

Thanks.

Martynas