Re: http://localhost:8080/manager/

[Zahid Rahman]

I got slightly confused with the error message "command" because where I
come from we use different terminology.

Element
Description
http://localhost:8080  The
web server to process the request
/manager/text
The name and location of server resource
?
  separates the location from the data
key=value
Field Name and associated values
&
  separates key value pairs
+
  replaces the space character.Note that all  other  special characters
are hex-encoded.





On Mon, 23 Dec 2019 at 15:51, Zahid Rahman  wrote:

> In that case there is more bad news for the person(s) who development the
> "command line" method  of deployment, when there are two other competing
> methods as GUIs. Especially the GUI you are presented with when you open
> the build.properties file in Eclipse.
>
>
>
> On Mon, 23 Dec 2019, 14:52 Christopher Schultz, <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Zahid,
>>
>> On 12/21/19 15:22, Zahid Rahman wrote:
>> > Yes thank you. I was just about to send message to with draw my
>> > message as I found the answer as I read on.
>> > http://tomcat.apache.org/tomcat-8.5-doc/manager-howto.html It seems
>> > I was a but *impatient* :)
>>
>> You're in luck: "impatience" is one of the three great virtues of
>> programmers!
>>
>> http://threevirtues.com/
>>
>> - -chris
>>
>> > On Sat, 21 Dec 2019, 19:46 Mark Thomas,  wrote:
>> >
>> >> On 21/12/2019 19:27, Zahid Rahman wrote:
>> >>> I am on
>> >>> http://tomcat.apache.org/tomcat-8.5-doc/manager-howto.html
>> >>> Tomcat Web Application Manager This same page is  produced by
>> >>> http://localhost:8080/manager/html
>> >>> http://localhost:8080/manager/ but
>> >>> http://localhost:8080/manager/text produces
>> >>>
>> >>> FAIL - Unknown command [/text]
>> >>>
>> >>> I thought that was a valid  url, it is in my ant
>> >>> configuration,
>> >> build.xml.
>> >>> > >>> value="http://localhost:8080/manager/text
>> >> "/>
>> >>
>> >> That URL doesn't contain a command. Hence the error message.
>> >>
>> >> See
>> >>
>> >> http://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html#Supported_
>> Manager_Commands
>> >>
>> >>
>> >>
>> Mark
>> >>
>> >> -
>> >>
>> >>
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> >> For additional commands, e-mail: users-h...@tomcat.apache.org
>> >>
>> >>
>> >
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4A1KoACgkQHPApP6U8
>> pFg4/Q/9H3U4Y2f7S03eAvfWnBwPBSbs8iVpKPsxDeVpRcdGnJeNuLS4rJzjuihP
>> L8D5m1R3Mz60LyoiC9FNKTIgKRLsQVki2UQAPDazNWf9AZ6g7lai6Sq7VnG4mCtX
>> sDbNf4UUewoqCGfIfb7vUHslKPJy6rjA0pmCcIoSyuZr4qQqne4ApXKZsO0HkRsC
>> H3pUt2atZKQhM6xbTbg1k0ZHKcEU32GfzUf+jP19kIZ0WN24ht+drQF/a1isukHY
>> VoIe0CynaqoE3bu8hhxNcESJKRseaUg4XmKQ/sdW3MzMNV6dqj+dN/a7pgflSesz
>> F8WHCMYVymWT82wVykJYP5dAWi0CWLz7YjDoZQohjN+FRjZWCs0B/+483u2Tzds4
>> 5/Ny6R8+ARquJcdicFHQj7GvSpOYtsxEEQL+tcnAmorhqR5/kpZX5mNoZ7xXS5pd
>> 1NP4b0AAvXHegWhC3QCzzHBNqArSLExkOLgNnTGnV383uIlmVbsQbs+6ZRj4/pG4
>> ZlQL/X3j9TKJPZkxRb1ogGfu3bv5o1GteTHZqwWa5cxJeTObNHUKVbpsEWQvKW+r
>> JCEyKbJo8vkfcjc9KjoyIyx9ZyA132DCLO/xMCe04ngpRa162WStHcbX9gN1eQkf
>> kwkwn07uT+XDqLwWWEnqC/DPNQ8Hp9I/EdZaYkbZPtBL+zsAqq8=
>> =DYFR
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

-- 
www.backbutton.co.uk

Re: Let's Encrypt with Tomcat?

[James H. H. Lampert]

Something else I noticed, just now:
If I do an "ss -tulwn" on the EC2 instance under discussion, it only 
lists 8443, not 443. And yet if I look at the AWS management console, 
the security group I set up allows 443, but not 8443, and I don't see 
anything external to the box that would be doing the port remapping.


Of course, if (as per my previous post) I can (1) get Tomcat sharing the 
same actual certificate and private key files as HTTPD, and (2) get 
HTTPD to open up on 80, then *how* 8443 gets remapped to 443 becomes moot.


--
JHHL

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

Re: Let's Encrypt with Tomcat?

[James H. H. Lampert]

As it happens, one way or another (and I'm not entirely sure
*which* way; I'd have to look at my notes), we *do* have Tomcat
listening directly on 443 (but not 80; nothing there is currently
listening on 80) on that particular EC2 instance (and I'm pretty
sure we have HTTPD running on a *different* port, for the SVN and
Trac sharing the box).


Hmm. It seems I was mistaken about two things: (1) that the Tomcat 
server under discussion is listening *directly* on 443, and (2) that I 
could find my notes on how I set the box up.


What I can find is the server.xml file, and the active connector 
definition. The thing that catches my eye is

port="8443" proxyPort="443"

I hope that indicates how it is I'm getting this to look like port 443 
to the outside world, because I honestly can't remember what I did (even 
though it looks like it's only been six months since I did it).


I now know one thing that I apparently did *not* do: I did *not* have 
HTTPD handle the public-facing TLS for Tomcat, because when I swapped in 
a self-signed keystore on Tomcat, and used the new "Re-read TLS 
configuration files" button in Manager, the self-signed cert is what was 
visible to browsers.


Trac and SVN do indeed appear to be set up through HTTPD. And the Tomcat 
and Apache files appear to share a common keypair and certificate, and 
I'm pretty sure I remember *starting with* a Java Keystore (since it's 
very familiar territory for me, and since I have KeyStore Explorer on my 
Mac), and exporting files from it, i.e., (the names have been changed to 
protect the innocent), I started with "/etc/tomcat8/foo.bar.net.ks," and 
derived "/etc/pki/tls/certs/foo.bar.net.cer," 
"/etc/pki/tls/certs/foo.bar.net.ca.crt," and 
"/etc/pki/tls/private/foo.bar.net.key" from it.


Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt" and 
".key" files directly, instead of the Java Keystore file? If so, then 
that could potentially simplify things: if I have HTTPD listen on 80, 
and Tomcat sharing the same actual certificate and private key *files* 
that HTTPD uses, then the only other thing I have to automate would be a 
cron job to either restart Tomcat, or just do a programmatic "re-read 
TLS configuration," whenever the regular Let's Encrypt job for HTTPD 
completes.


Does any of this make any sense at all, or am I sucking antimatter?

--
James H. H. Lampert

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

Re: Let's Encrypt with Tomcat?

[Andrew Stanton]

Hi All,

If possible, I think it's better to let 443 (https) requests hitting an
instance be redirected to 80 so you don't have to configure an SSL locally
in the instance itself.  It's very cumbersome to do it that way.

You can also use a single instance behind an AWS LB if you only have one
instance to use.

Just my two cents worth

- Andy s.


On Fri, Dec 27, 2019 at 2:08 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:

> >> As it happens, one way or another (and I'm not entirely sure
> >> *which* way; I'd have to look at my notes), we *do* have Tomcat
> >> listening directly on 443 (but not 80; nothing there is currently
> >> listening on 80) on that particular EC2 instance (and I'm pretty
> >> sure we have HTTPD running on a *different* port, for the SVN and
> >> Trac sharing the box).
>
> Hmm. It seems I was mistaken about two things: (1) that the Tomcat
> server under discussion is listening *directly* on 443, and (2) that I
> could find my notes on how I set the box up.
>
> What I can find is the server.xml file, and the active connector
> definition:
>
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>. . .
> clientAuth="false" sslProtocol="TLS" />
>
> The thing that catches my eye is
> port="8443" proxyPort="443"
>
> I hope that indicates how it is I'm getting this to look like port 443
> to the outside world, because I honestly can't remember what I did (even
> though it looks like it's only been six months since I did it).
>
> --
> James H. H. Lampert
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Andrew G. Stanton

CEO/Founder/Principal Engineer, Stanton Web Applications, Inc.
Founder, GetMorty.io and UniversalWallet.io


email: andrewgstan...@gmail.com
also: a...@stantonweb.com

web: www.stantonweb.com
*mobile: 415-793-4072*
tel/fax: 415-738-8501
linkedin: https://www.linkedin.com/in/andrew-g-stanton/
twitter: https://twitter.com/andrewgstanton

This message and any attachments are solely for the individual(s) named
above and others who have been specifically authorized to receive such and
may contain information which is confidential, privileged or exempt from
disclosure under applicable law. If you are not the intended recipient, any
disclosure, copying, use or distribution of the information included in
this message and any attachments is strictly prohibited. If you have
received this communication in error, please notify us by reply e-mail and
immediately and permanently delete this message and any attachments.  Thank
you.

Re: Let's Encrypt with Tomcat?

[James H. H. Lampert]

As it happens, one way or another (and I'm not entirely sure
*which* way; I'd have to look at my notes), we *do* have Tomcat
listening directly on 443 (but not 80; nothing there is currently
listening on 80) on that particular EC2 instance (and I'm pretty
sure we have HTTPD running on a *different* port, for the SVN and
Trac sharing the box).


Hmm. It seems I was mistaken about two things: (1) that the Tomcat 
server under discussion is listening *directly* on 443, and (2) that I 
could find my notes on how I set the box up.


What I can find is the server.xml file, and the active connector definition:

protocol="org.apache.coyote.http11.Http11NioProtocol"

  . . .
   clientAuth="false" sslProtocol="TLS" />

The thing that catches my eye is
port="8443" proxyPort="443"

I hope that indicates how it is I'm getting this to look like port 443 
to the outside world, because I honestly can't remember what I did (even 
though it looks like it's only been six months since I did it).


--
James H. H. Lampert

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

Re: Let's Encrypt with Tomcat?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 12/27/19 14:22, James H. H. Lampert wrote:
> On 12/26/19 8:31 PM, Igal Sapir wrote:
>> You should check out Chris' presentations on the topic.  He
>> outlines a very efficient process.  There is probably more
>> materials out there, but a quick search brings up the video [1]
>> and slides [2] from his presentation at ApacheCon earlier this
>> year, as well as his shell script for automating the process.
> 
> Excellent video.

I'm glad you think so. Before the recording begins, there are ~10
minutes worth of shenanigans where 4 Tomcat PMC members try to figure
out how to get the projector working. And no, Rémy, it wasn't because
I was using a Mac :)

> As it happens, one way or another (and I'm not entirely sure
> *which* way; I'd have to look at my notes), we *do* have Tomcat 
> listening directly on 443 (but not 80; nothing there is currently 
> listening on 80) on that particular EC2 instance (and I'm pretty
> sure we have HTTPD running on a *different* port, for the SVN and
> Trac sharing the box).

ACME almost requires port 80 to be opened. There are other opens, but
the simplest is to open port 80[1].

> At this point, I think I'm going to have to go through the video
> at least once more, just to come up with intelligent questions to
> ask, other than "What is JMX?" (I've already got the Wikipedia
> article up, but it seems to be more about the internal nuts and
> bolts of it than about how to use it.). When the subject first
> comes up in the presentation, I saw some sort of JMX GUI in use,
> that was evidently something the attendees were already familiar
> with, but I'm completely in the dark.

Honestly, you don't even have to understand JMX itself (spoiler alert:
it's a protocol which lets you manage stuff, like SNMP does. It's
Java-specific, requires RMI and an odd configuration. I wouldn't
recommend using it directly unless you want to use a GUI client like
VisualVM or one of the Java IDEs that has one bundles into it.

I always recommend using the JMXProxyServlet which is a part of the
manager webapp. It gives you access to all the MXBean stuff that you
can get via the full JMX protocol without having to have complicated
(JMX) configuration, additional ports opened on your firewall, or a
GUI available at all. (I tend to work on headless Linux-based servers,
so a GUI isn't convenient at all. Likewise, running a GUI to ping an
MXBean in a crontab isn't something you want to do.)

If you have a Tomcat running on your localhost desktop, this will be
easy to explore: just fire-up VisualVM (which you may have to
download[1] and install) or jvisualvm (if you have a JDK) and attach
to the JVM running Tomcat. Under the "MBeans" tab, there is a tree of
... stuff. Poke-around in there and have a look at the things under
"Catalina". Many of them are read-only, but some of them have writable
values and also "operations" that you can invoke to cause something to
happen on the server.

At $work, we have an MBean for reloading system announcements from our
database. We can push an announcement into a table in our database and
every 5 minutes our application servers refresh their list of
announcements from the db. This allows us to have mostly-current
information available to the application server without having to hit
the db for every single user hitting a certain set of pages. That
MBean just has a "reload" operation which takes no arguments and
returns nothing. When it runs, it refreshes the announcements from the
database.

Tomcat has something similar for the TLS configuration. If you reload
that, it will re-load the keystores, truststores, certificates, etc.
that were in the original configuration.

- -chris

[1] https://jmorahan.net/article/lets-encrypt-without-port-80
[2] https://visualvm.github.io/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GeEMACgkQHPApP6U8
pFjLghAAq0R7SxJbkmQTOd4/M/fbdkEk5ybjarXGFG4/+PeSzavdIShbI2QEx7VD
1ymtN9IHCRCA786llno0+YJqzRMkW5XTQ89+ggH5/gGshTvtYmeaIBhCjxyqeBiQ
bOO1va5bWDXFCdDsDRJFHyZ42tT52G27F0CZZgzaXlrxu0peWm2oZFGtcim1hxFY
bh6MIq13pPIBWZTNk4DRLBn/rTnop/yHTU+RC916ZVnvycMrhgEl6BOWiB1Tbm1o
jtCABd8xkz9o+Ozzm0NfEKYBbZFozLA4WL+hOObzdPaKcixLtAdsU2ZBMCjM9bmS
mthISotVTCI6ypNSCjISAg3aA+1rfSUh1Si40moAK+H939Adwt4mM+J4L54xXZxh
qvy4YgwHUScycYMAvCJA+j/PONldsDJJ0QMiDO1Ihb4PnZKhaXcI+6tmb1fjwvL/
ifunV6InrLrHVKLcpvhdA3QKw2+TlsmZXdoGJUiaDn/UjAwvGkw9GhxLd0UVE/B3
Tdv19dkxQnJjaef+SE1Zci2CSgVV4VlvKUcJ9HlyJvi0IIvWIR9nRzagDjUEiosA
c9WsQVyfdu5+unkjyQXmY/NZNt1um0XfF5qBLqucfdS2ccsUPyE5EbHwso83yaCn
iftxyTNhiTj6GwR5kpKyb0lbXPDchEJzPoQ9F6Er12HB5Inmf9w=
=v9pw
-END PGP SIGNATURE-

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

Re: Let's Encrypt with Tomcat?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 12/27/19 11:27, logo wrote:
> Am 2019-12-27 16:40, schrieb Christopher Schultz: That's the plan.
> In Las Vegas, Christopher Tubbs did say to me "aw, I was really
> hoping for you to tell us that you just set letsEncrypt="true" in
> your configuration and you are done". So there is definitely more
> that can be done, here.
> 
> The plan was to try to get someone to integrate my script (or 
> equivalent) into certbot or other ACME clients. Maybe what we
> really need is a command that can be run that "gracefully" restarts
> the server -- like httpd already does. There is no reason to
> actually restart the server -- just reinitialize the TLS engine for
> the connector. So maybe what we need is a script that basically
> just hits the jmxproxy to reinit the connector and tell certbot to
> use that when it's done with the ACME stuff.
> 
>> oh I get the idea! a hook-script, right?

Yeah, I guess. certbot basically runs "apachectl graceful" when you
are using the "apache" plug-in. If we had a "tomcat" plug-in, maybe
that could run "tomcatctl graceful" and that just pings the manager
application. Unfortunately, it needs a bunch of configuration like the
hostname and port number to use, username/password, which connector to
bounce, etc.

>> Like the 2nd part of your script. well specifically it could
>> reload only the SSLHostConfig affected by this new cert curl 
>> "https:/$JMXUSER:$JMXPASSWORD@localhost:${SERVICE_PORT}/manager/jmxpr
oxy?invoke=Catalina:type=ProtocolHandler,port={CONNECTOR_PORT}=reload
SslHostConfig=${HOSTNAME}"

Right,
>> 
but the idea is that certbot has "plug-ins" and we'd need to
supply a "tomcat" plug-in that did things like this. I'm not sure
where the best place to keep configuration would be. Someone who
understands certbot (or autobot, etc.) would be a better resource than m
e.

>> Or did you think about a bin/version.sh type script? That would
>> get a +1 from me.

What do you mean?

>> What I don't like is, that one needs to add credentials in 
>> tomcat-users.xml and expose the manager-interface.
You can use other authentication mechanisms... it's just that usually
nobody bothers since it's easy to configure tomcat-users.xml. Exposing
the manager interface is a bit of pain, but it can be scripted. Our
deployments install a proper tomcat-users.xml file and enable the
manager, locked-down to localhost connections.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GZh8ACgkQHPApP6U8
pFjw8hAAqpsfbF/25K9A8l6ZFLoLrO+9C7z+86i1KLI/91VMylTxe/9Im8+Id/jG
4AOXOov5m8SvzBQIDnjnSbUrVAvZ9J36pzlH4FoAxDQoZY3DWmyGPPa7S56OKG0g
Ha3rS5QziBjV9XbSuCL+6hbt4VBLVY0aRT9dvkDahiN42j2cczc2AOi1GxSf1WbY
iIYO8c1yfJvF/4wo7lBE6WpLRJb3RVI9psRuDm/yaMGY/nBzzNbYvhgB+pM/m0dw
Ls+w2HC6X8dq+0jV33FH1MdEY6yroH2gapclLcaeJ1yB2uke2cvGo0/vi3MdzOYK
CndNSfQrXTeyawWcgj4DjQZy9koBeXfdDXC18cFOKLvceMmV6UG8jwSBSVDjhYml
Ut9W7+GPYn8fBej9I/PaLRB3VAS47pRjY6MjA+AEMZxdowyOiNpc6E5snP4N+J9u
s3wTL9gfPGIOrrIilSPD9eIIHGExZ5na3FxuVV1grGSOMAq8EoJRn9iCBjyrYwuF
JsKXtvG2e91r/pvSL/zTDufoZysVvf4aUrgnxA9kY8lp+3O6+3U/5FTLWWtc7Fcj
ljjb87yda57Zvb/KU95GBakDt8+3fbMMyhHeUAANWrSMPIN5astpacBdDRD5F1KH
HNW5QTmxG56D0yaM3/pKPpoFBMqojtCen6MO8ZVkSN9Qv4H3NKo=
=SHiE
-END PGP SIGNATURE-

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

Re: Let's Encrypt with Tomcat?

[James H. H. Lampert]

On 12/26/19 8:31 PM, Igal Sapir wrote:

You should check out Chris' presentations on the topic.  He outlines a very
efficient process.  There is probably more materials out there, but a quick
search brings up the video [1] and slides [2] from his presentation at
ApacheCon earlier this year, as well as his shell script for automating the
process.


Excellent video. As it happens, one way or another (and I'm not entirely 
sure *which* way; I'd have to look at my notes), we *do* have Tomcat 
listening directly on 443 (but not 80; nothing there is currently 
listening on 80) on that particular EC2 instance (and I'm pretty sure we 
have HTTPD running on a *different* port, for the SVN and Trac sharing 
the box).


At this point, I think I'm going to have to go through the video at 
least once more, just to come up with intelligent questions to ask, 
other than "What is JMX?" (I've already got the Wikipedia article up, 
but it seems to be more about the internal nuts and bolts of it than 
about how to use it.). When the subject first comes up in the 
presentation, I saw some sort of JMX GUI in use, that was evidently 
something the attendees were already familiar with, but I'm completely 
in the dark.


--
JHHL

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

Re: ECDSA Private Keys

[logo]

Chris

Am 2019-12-27 16:33, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 12/26/19 18:55, logo wrote:

Hi Mark,


I hope it's okay if I reply. :)


:-)





I just recently tested Step CA (smallstep.com) as an internal CA
that provides an internal ACME service.

After I deployed the created cert to my Tomcat (8.5.50 with
adoptopenjdk 11) I noticed that while the openssl connector
immediately started, the JSSE connector with the same cert would
fail with a "java.security.KeyStoreException: Cannot store
non-PrivateKeys“ I use the openssl XML certificate config also for
JSSE.

It took me quite a while to figure this one out - as the message
usually indicates a public key as cert. I noticed that Step Ca is
creating ECDSA certs by default. The Openssl Connector delivers the
new ECDSA cert just fine.

While Java (afaik) seems to be able to handle ECDSA, tomcat will
fall through a case statement in
org.apache.tomcat.util.net.jsse.PEMFile

When loading the PEM file parts it will skip all cases in

for (Part part : parts) { switch (part.type) { case "PRIVATE KEY":
privateKey = part.toPrivateKey(null, keyAlgorithm, Format.PKCS8);
break; case "ENCRYPTED PRIVATE KEY": privateKey =
part.toPrivateKey(password, keyAlgorithm, Format.PKCS8); break;
case "RSA PRIVATE KEY": privateKey = part.toPrivateKey(null,
keyAlgorithm, Format.PKCS1); break; case "CERTIFICATE": case "X509
CERTIFICATE": certificates.add(part.toCertificate()); break; } }

as an EC certificate will start with EC PRIVATE KEY.

Is this something that is expected? ECDSA unsupported? Or just an
incomplete implementation, edge case or a bug?


EC should work. What does your  configuration look like?



   
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"

   maxThreads="150"
   SSLEnabled="true" >
className="org.apache.coyote.http2.Http2Protocol" />






really basic.
First I had a type attribute "RSA" but even ommitting this didn't change 
it.


Once Tomcat hits the PEMFile-Class the parts read from the 
ECDSA-PEM-file are not transferred to a private key so the class member 
"privateKey" is null. None of the cases above match "EC PRIVATE KEY".


Peter


- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJDIACgkQHPApP6U8
pFi1HBAAxzrE1P4o2nj9/6/nr9sVEiPOusw30P2YnaJGvvkv2jvHoj1TITGVlaTg
Y/Oy4GPA7NEn0ofRPFwaphL0+kETxZyHSBotxtlsOZsg2aLj2tLKCmwCZe2UfPcA
nRmVtn+TgPOHOb3x+sSKhOzv73SjbnqVVRQLCa/4t/D/S8nfR6Lc9yqPibLI4y/+
+gqnKhs7TW5f74ZAMjLlWKrEwbsr1KRcCW7G4vA6859fxDtPSckPR5MoHBe3H/pK
2D26EoNb5jZ5McxgM9xmGe74lYXp3XVOQLEOZnBNAjGd6VWs4oyHFbc3/800vD6E
gyQLgFonupS0XE3gj0cy3HVWggSQhd9AlQXwyBNQg8UWA4tQNhRiPTvgX5gAYWnf
AHBKPb5LpDm8cEkCM63Ow92ce4a6JHFBxEs2TX2h14iHGCk1ARERiM2tgltugxub
vmkJLGkDGd6EM2B62Wv8dnA6/1qtebgrW6IcZrESEKaP3T5qYivs5uUq4sYLXMho
G8v24Om8tRDOCoE1gl+UIWRsoMZQttOJSYwbBriOWa7OJ3PSq3nzE22zSgqhqHOh
QwPBXMSYQNz6aMXKxCwwS5GjdrRQqIQINi8YbRf4Wjre4zZNIzPJ4FgDtROQYl85
32Gsa4pcwyEtM2a+8iH98dXhpP5ST1CxCiGXhlzEFmXbFgSadKg=
=aSBb
-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: Let's Encrypt with Tomcat?

[logo]

Chris,

Am 2019-12-27 16:40, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 12/27/19 07:24, logo wrote:

Hi James,

Am 2019-12-27 05:31, schrieb Igal Sapir:

James,

On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:


We have a Tomcat (8.5.40) server running on an Amazon EC2
instance, currently using a Java Keystore for the SSL support.

We would like to be able to use Let's Encrypt, but I've learned
that Let's Encrypt and Tomcat don't get along all that well
together. The best I've found so far are article at:

<
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-

3db8a469e3d2








and this thread in the Let's Encrypt community forum:

<
https://community.letsencrypt.org/t/how-can-i-automate-renewals-with

- -tomcat/81423








Does anybody here have any experience with situations like
this? Does anybody here have any suggestions? Or, as another
alternative, does anybody here know of some Amazon AWS product
that could front-end a single-box, non-load-balanced Tomcat
server, and use Amazon's free "Public Certificates"? (I've
already posted that last to the relevant Amazon forum.)



You should check out Chris' presentations on the topic.  He
outlines a very efficient process.  There is probably more
materials out there, but a quick search brings up the video [1]
and slides [2] from his presentation at ApacheCon earlier this
year, as well as his shell script for automating the process.

Igal

[1] https://www.youtube.com/watch?v=BWUjvmJgSeE [2]






https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt
%20Apache%20Tomcat.pdf


[3]
https://people.apache.org/~schultz/ApacheCon%20NA%202019/lets-encrypt

- -renew.sh









+1


Currently the script is broken


Really?


, as there is a bug in the JMX implementation of Tomcat 8.5 that
is fixed from 8.5.51.


Can you explain? I'll fix the script if there is something missing. I
*do* have to make the conversion from PEM -> PKCS12 optional.
keystores just suck.



well not really the script. I should say explicitly it will not work on 
8.5 as JMX reloadSSLConfigs is broken. See: 
https://markmail.org/thread/renoatnedduquebm

Mark already fixed it for 8.5.51.


Once that is released it is really easy to automate the letsencrypt
acme process with [3].

Tomcat 8.5 brings a new way to configure certificates [4]. You can
use pem encoded certs even in the JSSE implementation. So you can
just save/copy the certs from LE to your certificate directory (in
my case ${catalina.base}/conf/ssl):



After certbot has finished, reload the SSL config for the updated
Host through the jmxproxy and you are done.


That's the plan. In Las Vegas, Christopher Tubbs did say to me "aw, I
was really hoping for you to tell us that you just set
letsEncrypt="true" in your configuration and you are done". So there
is definitely more that can be done, here.

The plan was to try to get someone to integrate my script (or
equivalent) into certbot or other ACME clients. Maybe what we really
need is a command that can be run that "gracefully" restarts the
server -- like httpd already does. There is no reason to actually
restart the server -- just reinitialize the TLS engine for the
connector. So maybe what we need is a script that basically just hits
the jmxproxy to reinit the connector and tell certbot to use that when
it's done with the ACME stuff.


oh I get the idea! a hook-script, right?

Like the 2nd part of your script. well specifically it could reload only 
the SSLHostConfig affected by this new cert
curl 
"https:/$JMXUSER:$JMXPASSWORD@localhost:${SERVICE_PORT}/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port={CONNECTOR_PORT}=reloadSslHostConfig=${HOSTNAME}"


Or did you think about a bin/version.sh type script? That would get a +1 
from me. What I don't like is, that one needs to add credentials in 
tomcat-users.xml and expose the manager-interface.




I don't think it's necessary to build ACME into Tomcat itself when
tools like certbot already exist for that purpose, and admins will be
more familiar with those than some server-specific configuration.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJeMACgkQHPApP6U8
pFj6gA/+NS5ZO6IJZ8W8/XT7usLq8wG+B0VuRFGzPhERam0XqBFEe59AvW+LXpIa
ChUy/eZYkrtGmRX7ZhSr/njD3mEhp+3R2XVgM91kPg4WWIkpAeLixuJOaoqn5QZU
jDr9sWpe190i2RI/OKlki/ADJ6oEemJsF3HElW4YcSYtWnqgmjAzncCJDJd3xvrq
bCskiXd4ru7Afg0T0hv/B8B62W5DgtuvB0GqmTsQBElZ9cTpGMJFJFH3WUfVBwZV
jpE/X/jmArYnU/lJIf22of8+zZgCYxEDGmiNGhZxPMh+A8lkn71fyfXJ3ZojijIm
p29KSSWJX0GPcJpIq7xxs4tmvmehIErjxPyacTcGwEhhY0TCKA7aGnh8yrVrFJcs
Tvz/2CmPvDva37/d32Knv9mv+Niw2ia8TGD6SFmaxmlNLxWR9nB9i+VobYdeQeCL
xOvksLYZluhLcvTpKgxutv+S7utt+i5QuuvjphWxzT5ro0x6ZBMuPGBdhFHzo4M2

Re: HSTS not apply to some request URI path on tomcat 8.5.9 Centos 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pattavee,

On 12/26/19 05:22, Pattavee Sanchol wrote:
> Dear support team
> 
> I config tomcat server to enabled HSTS some request URI path not 
> response with Secure heading
> 
> The configuration illustrated below
> 
> 
> 
> httpHeaderSecurity
> 
> 
> org.apache.catalina.filters.HttpHeaderSecurityFilter
>
>  true
> 
> 
> 
> hstsEnabled
> 
> true
> 
> 
> 
> 
> 
> hstsIncludeSubDomains
> 
> true
> 
> 
> 
> 
> 
> hstsMaxAgeSeconds
> 
> 31536000
> 
> 
> 
> 
> 
> antiClickJackingEnabled
> 
> true
> 
> 
> 
> 
> 
> antiClickJackingOption
> 
> SAMEORIGIN
> 
> 
> 
> 
> 
> 
> 
> 
> httpHeaderSecurity
> 
> /*
> 
> REQUEST
> 
> 
> 
> 
> I some request URI such as http://192.168.1.1/%20 is not response
> with security hedering
> 
> 
> this is working
> 
> 
> image.png this not working image.png Please suggest me to solve
> this problem.

You configured this filter in your web application, right? I'm
guessing this is not the root application, but instead something like
/myapp ?

If that's the case, then requesting http://192.168.1.1/%20 will map to
the ROOT web application which doesn't have HSTS configured.

You will need to add this  to the ROOT web application, which
is usually found in CATALINA_BASE/webapps/ROOT. You may have
specifically configured it to be somewhere else, though.

Our applications at $work are also deployed as /myapp but our build
process always generates a "dummy" ROOT application that handles
things like 404 responses to things that don't start with /myapp.
Consider doing the same with your build: build your myapp.war (or
whatever) and then also build a ROOT.war (or similar) which contains
the minimal configuration you need to accomplish your goals, such as
the HSTS response headers, and maybe a catch-all error handler that
redirects people to /myapp or something similar.

As for HSTS being served from Tomcat... you might consider doing that
at the reverse-proxy level. My experience has been that having a
single Tomcat isn't enough for a production-quality deployment for
both fail-over and maintenance purposes. It's always a good idea to
have a load-balancer even if you don't have so much load that a single
server can handle it.

If you have a lb/reverse-proxy, then HSTS is best handled there
because it's usually easier to apply it to the whole site.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJ38ACgkQHPApP6U8
pFjZHg//TBEc6qs0vxQJMiscnxt0a+Fhwf0QPQcwTyO7WqnvmQk+pHhUEBbsyjPb
+Bj6fV4Qx9fX2HGBvrMKO6bGBXEGsjowUJr72OrQXjx1xsgfEIlzF8aSEG+DQWtF
XaswAcMA0LTncAYxZHM7rXItwLjH9JzD1Tc6wAkBZifPXuxw8iTUssBvGfT5WrcY
BSI2oOQ4uW7q1HYA81pm/jJMi0kbk6MhQk3ENagB24/BCDCXr/bEBOKGdVLGvFKH
c8etGdg2T7MJuEs232ug9tnu5balMzpDSoeqnrhnX84hnpHfZ87IDXVnvagkv3MB
fkL0+VwQhP1mHF9d/EMMO5OZHLoalTrcDOXJs6sHldlywkS0pqhb8ucV0vxKISmD
ox1TT3RqzFM200+ssc7o0dt7xWaX4HfQ8+/kpdLhjpq9+BNJhZ/hrxH13hlGQDNF
INLZyHuJvahQiS4i/7qKlIrra2CDHfFpfPYGJkpWDgCWvrpTItpKUr5aH9x5CX/L
zlmeIsYqD/Z4cl7N8H1Cf7Pmw6t24ihtozveyxJMm5Kix2VCo3akkEVdfNxRnUCI
2MDzKPqE1j7myWUXiSM4gK83z4RdUzXPagBlLrqhJH6LFrHfAdgOdnIQoKTzo7SE
GQbifq2pq5T6M5TWwlOl/ZtkL/UzYWmsGf2e/lEgoJjvw66wFVo=
=Uk5h
-END PGP SIGNATURE-

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

Re: Let's Encrypt with Tomcat?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alex,

On 12/27/19 10:07, Alex O'Ree wrote:
> i use letsencrypt with tomcat. i adopted a cronjob/bash script that
> auto renews the cert before expiration, it then stops tomcat,
> refreshes the jks files, then restarts tomcat. yeah it's down time,
> but it is minimal and it works

You can do better, depending upon your version of Tomcat.

https://tomcat.apache.org/presentations.html#latest-lets-encrypt

- -chris

> On Thu, Dec 26, 2019 at 7:49 PM James H. H. Lampert < 
> jam...@touchtonecorp.com> wrote:
> 
>> We have a Tomcat (8.5.40) server running on an Amazon EC2
>> instance, currently using a Java Keystore for the SSL support.
>> 
>> We would like to be able to use Let's Encrypt, but I've learned
>> that Let's Encrypt and Tomcat don't get along all that well
>> together. The best I've found so far are article at:
>> 
>> < 
>> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3
db8a469e3d2
>>>
>>
>>
>> 
and this thread in the Let's Encrypt community forum:
>> 
>> 
>> < 
>> https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-
tomcat/81423
>>>
>>
>>
>> 
Does anybody here have any experience with situations like this? Does
>> anybody here have any suggestions? Or, as another alternative,
>> does anybody here know of some Amazon AWS product that could
>> front-end a single-box, non-load-balanced Tomcat server, and use
>> Amazon's free "Public Certificates"? (I've already posted that
>> last to the relevant Amazon forum.)
>> 
>> James H. H. Lampert Touchtone Corporation
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJisACgkQHPApP6U8
pFhZdg//RU4E6kqOFnfbUtU0K7qqle2wTZ4E4RJ6dykWiXM9rtP3MiSGf/UgYMiA
aK/0m/s00pmv06T9tCwGVbQetf2xXbwYsI47Dv4mood70PnWTnpGv5CKpt2tuGP0
mQSAnRpPIogHdViSmnwcpBAk5DN2HlHbF+nXvVg1tAlubKQFD2p5uD7ycebjYzmq
K2HTda71pUDh6pZ5ZNhUOu+NMbMWhOZeEAJzCM1lC2BM4M+J3BLGEvhaFiZOLmb0
QwqcilBktqL0XJhcHSbMQyJWlLoHPQz/XpPLdCn7MeHgmi9ejOT0bBZNkn6D7pmt
u0P87hrT7ixgnI5Te52JkdzKIPV+ohBfDIUTQfx1uKoPbP5u7BPpA2zuxgxGrQVJ
A2/kitNmYYklf9dF8OyzlVfNTWj+nonEC87UMPmYyJn2voe8TyDwPGBRyiE4Kpqx
zMPfAR7on2deaC8ifqXbWlfmINjxMt3Yinj/I2awebbhU+smkPUix3qgB5+ukj+W
t7V/uGHSs5FZA2R75TujazLbnBNxfDEXhSnggvn5eWCYUF4YKSqhimjY8OX9zM7U
h1cJ0gipVgVlElI62tfL8HhyJVHml/8zqBv3+g90gWazOWMe21KNyC2U/98BVih+
j3UwrcXE486p/HUmeTY9O2nEbLk0FUxuoRGv9xZOXwk58Js2yJs=
=hogF
-END PGP SIGNATURE-

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

Re: Let's Encrypt with Tomcat?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 12/27/19 07:24, logo wrote:
> Hi James,
> 
> Am 2019-12-27 05:31, schrieb Igal Sapir:
>> James,
>> 
>> On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert < 
>> jam...@touchtonecorp.com> wrote:
>> 
>>> We have a Tomcat (8.5.40) server running on an Amazon EC2
>>> instance, currently using a Java Keystore for the SSL support.
>>> 
>>> We would like to be able to use Let's Encrypt, but I've learned
>>> that Let's Encrypt and Tomcat don't get along all that well
>>> together. The best I've found so far are article at:
>>> 
>>> < 
>>> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-
3db8a469e3d2
>>>
>>>
>>> 
> 
>>> 
>>> and this thread in the Let's Encrypt community forum:
>>> 
>>> < 
>>> https://community.letsencrypt.org/t/how-can-i-automate-renewals-with
- -tomcat/81423
>>>
>>>
>>> 
> 
>>> 
>>> Does anybody here have any experience with situations like
>>> this? Does anybody here have any suggestions? Or, as another
>>> alternative, does anybody here know of some Amazon AWS product
>>> that could front-end a single-box, non-load-balanced Tomcat
>>> server, and use Amazon's free "Public Certificates"? (I've
>>> already posted that last to the relevant Amazon forum.)
>>> 
>> 
>> You should check out Chris' presentations on the topic.  He
>> outlines a very efficient process.  There is probably more
>> materials out there, but a quick search brings up the video [1]
>> and slides [2] from his presentation at ApacheCon earlier this
>> year, as well as his shell script for automating the process.
>> 
>> Igal
>> 
>> [1] https://www.youtube.com/watch?v=BWUjvmJgSeE [2] 
>> 
>>
>>
>> 
https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt
%20Apache%20Tomcat.pdf
>> 
>> [3] 
>> https://people.apache.org/~schultz/ApacheCon%20NA%202019/lets-encrypt
- -renew.sh
>>
>>
>>
>
>> 
+1
> 
> Currently the script is broken

Really?

> , as there is a bug in the JMX implementation of Tomcat 8.5 that
> is fixed from 8.5.51.

Can you explain? I'll fix the script if there is something missing. I
*do* have to make the conversion from PEM -> PKCS12 optional.
keystores just suck.

> Once that is released it is really easy to automate the letsencrypt
> acme process with [3].
> 
> Tomcat 8.5 brings a new way to configure certificates [4]. You can
> use pem encoded certs even in the JSSE implementation. So you can
> just save/copy the certs from LE to your certificate directory (in
> my case ${catalina.base}/conf/ssl):
> 
>  certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem" 
> certificateFile="${catalina.base}/conf/ssl/cert.pem"
> 
> certificateChainFile="${catalina.base}/conf/ssl/chain.pem" 
> type="RSA" />
> 
> After certbot has finished, reload the SSL config for the updated
> Host through the jmxproxy and you are done.

That's the plan. In Las Vegas, Christopher Tubbs did say to me "aw, I
was really hoping for you to tell us that you just set
letsEncrypt="true" in your configuration and you are done". So there
is definitely more that can be done, here.

The plan was to try to get someone to integrate my script (or
equivalent) into certbot or other ACME clients. Maybe what we really
need is a command that can be run that "gracefully" restarts the
server -- like httpd already does. There is no reason to actually
restart the server -- just reinitialize the TLS engine for the
connector. So maybe what we need is a script that basically just hits
the jmxproxy to reinit the connector and tell certbot to use that when
it's done with the ACME stuff.

I don't think it's necessary to build ACME into Tomcat itself when
tools like certbot already exist for that purpose, and admins will be
more familiar with those than some server-specific configuration.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJeMACgkQHPApP6U8
pFj6gA/+NS5ZO6IJZ8W8/XT7usLq8wG+B0VuRFGzPhERam0XqBFEe59AvW+LXpIa
ChUy/eZYkrtGmRX7ZhSr/njD3mEhp+3R2XVgM91kPg4WWIkpAeLixuJOaoqn5QZU
jDr9sWpe190i2RI/OKlki/ADJ6oEemJsF3HElW4YcSYtWnqgmjAzncCJDJd3xvrq
bCskiXd4ru7Afg0T0hv/B8B62W5DgtuvB0GqmTsQBElZ9cTpGMJFJFH3WUfVBwZV
jpE/X/jmArYnU/lJIf22of8+zZgCYxEDGmiNGhZxPMh+A8lkn71fyfXJ3ZojijIm
p29KSSWJX0GPcJpIq7xxs4tmvmehIErjxPyacTcGwEhhY0TCKA7aGnh8yrVrFJcs
Tvz/2CmPvDva37/d32Knv9mv+Niw2ia8TGD6SFmaxmlNLxWR9nB9i+VobYdeQeCL
xOvksLYZluhLcvTpKgxutv+S7utt+i5QuuvjphWxzT5ro0x6ZBMuPGBdhFHzo4M2
bVljArD183gM46navyBk9xHxjaTHckGu5dramqyUYYvlG4HwGdvLk2CP780DT/Ik
Ntacf1O3KIDUyDqKxZepSeqExWuBZc1hco08lsk+un1kF3uFIQlspCwz/8laErh5
eQZs2Yf8GCksO0piXX1Ojo7nbG4vjuh+kwotkIcxUl2Ww/jnerE=
=L67K
-END PGP SIGNATURE-

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

Re: ECDSA Private Keys

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 12/26/19 18:55, logo wrote:
> Hi Mark,

I hope it's okay if I reply. :)

> I just recently tested Step CA (smallstep.com) as an internal CA
> that provides an internal ACME service.
> 
> After I deployed the created cert to my Tomcat (8.5.50 with
> adoptopenjdk 11) I noticed that while the openssl connector
> immediately started, the JSSE connector with the same cert would
> fail with a "java.security.KeyStoreException: Cannot store
> non-PrivateKeys“ I use the openssl XML certificate config also for
> JSSE.
> 
> It took me quite a while to figure this one out - as the message
> usually indicates a public key as cert. I noticed that Step Ca is
> creating ECDSA certs by default. The Openssl Connector delivers the
> new ECDSA cert just fine.
> 
> While Java (afaik) seems to be able to handle ECDSA, tomcat will
> fall through a case statement in
> org.apache.tomcat.util.net.jsse.PEMFile
> 
> When loading the PEM file parts it will skip all cases in
> 
> for (Part part : parts) { switch (part.type) { case "PRIVATE KEY": 
> privateKey = part.toPrivateKey(null, keyAlgorithm, Format.PKCS8); 
> break; case "ENCRYPTED PRIVATE KEY": privateKey =
> part.toPrivateKey(password, keyAlgorithm, Format.PKCS8); break; 
> case "RSA PRIVATE KEY": privateKey = part.toPrivateKey(null,
> keyAlgorithm, Format.PKCS1); break; case "CERTIFICATE": case "X509
> CERTIFICATE": certificates.add(part.toCertificate()); break; } }
> 
> as an EC certificate will start with EC PRIVATE KEY.
> 
> Is this something that is expected? ECDSA unsupported? Or just an
> incomplete implementation, edge case or a bug?

EC should work. What does your  configuration look like?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJDIACgkQHPApP6U8
pFi1HBAAxzrE1P4o2nj9/6/nr9sVEiPOusw30P2YnaJGvvkv2jvHoj1TITGVlaTg
Y/Oy4GPA7NEn0ofRPFwaphL0+kETxZyHSBotxtlsOZsg2aLj2tLKCmwCZe2UfPcA
nRmVtn+TgPOHOb3x+sSKhOzv73SjbnqVVRQLCa/4t/D/S8nfR6Lc9yqPibLI4y/+
+gqnKhs7TW5f74ZAMjLlWKrEwbsr1KRcCW7G4vA6859fxDtPSckPR5MoHBe3H/pK
2D26EoNb5jZ5McxgM9xmGe74lYXp3XVOQLEOZnBNAjGd6VWs4oyHFbc3/800vD6E
gyQLgFonupS0XE3gj0cy3HVWggSQhd9AlQXwyBNQg8UWA4tQNhRiPTvgX5gAYWnf
AHBKPb5LpDm8cEkCM63Ow92ce4a6JHFBxEs2TX2h14iHGCk1ARERiM2tgltugxub
vmkJLGkDGd6EM2B62Wv8dnA6/1qtebgrW6IcZrESEKaP3T5qYivs5uUq4sYLXMho
G8v24Om8tRDOCoE1gl+UIWRsoMZQttOJSYwbBriOWa7OJ3PSq3nzE22zSgqhqHOh
QwPBXMSYQNz6aMXKxCwwS5GjdrRQqIQINi8YbRf4Wjre4zZNIzPJ4FgDtROQYl85
32Gsa4pcwyEtM2a+8iH98dXhpP5ST1CxCiGXhlzEFmXbFgSadKg=
=aSBb
-END PGP SIGNATURE-

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

Re: [OT] Re: How to set apache load balancer for send request to 6 tomcat server

[Zahid Rahman]

Good,  please expand

On Fri, 27 Dec 2019, 15:27 Christopher Schultz, <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Zahid,
>
> On 12/23/19 15:19, Zahid Rahman wrote:
> > If your backend tomcat servers are running on different physical
> > machines therefore with different ip addresses then there is
> > nothing wrong with each backend  tomcat server listening on same
> > port (80) of each machine. Further to mod_jk worker properties file
> > redirection.
> >
> > It is pointless in having multiple tomcat instances running on same
> > machine , because the kernel will slice and share resources as per
> > priority level setting of OS.
>
> I disagree. There are use-cases for running multiple Tomcat instances
> on the same machine.
>
> > If you don't have heavy user activity expectations   then this
> > excercise is pointless.
>
> ?
>
> - -chris
>
> > On Mon, 23 Dec 2019, 17:45 Giancarlo Celli,
> >  wrote:
> >
> >> Hi, I need to configure a load balancer with apache connector on
> >> a jelastic server that redirects requests to 6 server workers
> >> with tomcat 7 installed. Atteched you can find extract from
> >> httpd.conf and workers.properties. I need to send single request
> >> to tomcat server individually, so I set sticky_session to 0.
> >> Could you tell me if parameters are configured correctly? Is the
> >> collector able to handle all requests? Could you give me some
> >> further advice?
> >>
> >> Each tomcat server is configured with the following parameters:
> >>
> >>  >> connectionTimeout="2" redirectPort="8443" />
> >>
> >> The balancer has the following configuration: Server version:
> >> Apache/2.4.39 (codeit) Server built:   Apr  3 2019 18:54:14
> >> Architecture:   64-bit Server MPM: event threaded: yes
> >> (fixed thread count) forked: yes (variable process count)
> >>
> >>
> >> Thanks. Best regards.
> >>
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GIuwACgkQHPApP6U8
> pFgmQA//aMZLwDbtop83M7HTtM2P8vXzO7Z1cbvu5NA8yvt4IjMBA9WyrJ+XYhDn
> pRHJP2S0LTLmWrZ3n8o2QpdUGkMwWwpnhuHsr1zqzwhIxWtB1tmBoIgkueM92Yk1
> wXOHuy+PRlXGTRkujprb6bwUH2OxGp3Z6w3X1kqdvgJtZ6ZydBFD+eDv0epOSPay
> z3gvFraikSSY6IAf2y3gI/FTMT8kjUmo+M9TnnZ2Lbjmaxg/abmRa1rypcaMLXPf
> DjlQ0SAJtu2lS4wtQphY1beAsP2l/EXlMPaWIy2HbbaTBmZNtevM21OyxsWAdXQH
> SNmPDIC0AycTJfpeeB3tUbAtPVBKUkoOoaMLEkuAp1JdqnrW1KGH71cAvDkdJIBK
> 7b8mXTE07/mVpak4XhIqfdEkTLI+QWpYDIds6xWPYFokNtfevD6ZIBjbtNyqFcgE
> CEFHOkiM9JtzEOLJu24bS6MAbeYx4TnkvcZZF3hd79/Cxbusw2rlTZEvvKSSDXUn
> tWi4/xeTq1o8slmWf+A241qrr4SyHdOR8XVMUT4RvXSCcmBdkh0UDsxaMXLyx/AK
> yg7BxhU8d2OTmOfsFzRMCYZOpw+P+a5zE+3lNkeTbLuIamn9igKm/E7msd/enK4Z
> yHWd7tof+JXHGyhtYsBlr8tM8cm9pS2R02kLHAr34s7t0TjL9D4=
> =qkR+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: How to set apache load balancer for send request to 6 tomcat server

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Giancarlo,

On 12/23/19 12:45, Giancarlo Celli wrote:
> Hi, I need to configure a load balancer with apache connector on a
> jelastic server that redirects requests to 6 server workers with
> tomcat 7 installed. Atteched you can find extract from httpd.conf
> and workers.properties. I need to send single request to tomcat
> server individually, so I set sticky_session to 0.

So you want your clients to switch servers even when they don't have to?

> Could you tell me if parameters are configured correctly? Is the
> collector able to handle all requests? Could you give me some
> further advice?
> 
> Each tomcat server is configured with the following parameters:
> 
>  connectionTimeout="2" redirectPort="8443" />
> 
> The balancer has the following configuration: Server version:
> Apache/2.4.39 (codeit) Server built:   Apr  3 2019 18:54:14 
> Architecture:   64-bit Server MPM: event threaded: yes
> (fixed thread count) forked: yes (variable process count)

Your attachments were stripped. Can you please post an example worker
and your JkMounts from httpd.conf? We don't need the whole httpd.conf.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GI1cACgkQHPApP6U8
pFjHPhAAyDpqNcDm5AIe+QcsF/dB0rEfWSrfXY3DFZUjvJVTLfeqhUxS+gKNbHBf
iXhbxnXiFVMkHqgWxcMlrsQMGK5wWL00HCOrlijGbJYa52QCn2aLFJ6buf5kU+Cy
SAXOIBbpz4x12QEU6x2LJGAEXa8fMx96xyTXl0SAiWQqQ/EtVw/0y+b5h97Zpej5
kxR04IyOMDfqyEMVeKUVQNr46yZmscHE3r9Bo49mVqmLjD8a/tzHZybTuFVeW6xj
lILNuPwBL+cMz5ImqfW3qQUKyKLC6Bo9gdeamIXYg4z/66XwFmBUTP/mcTf0Up67
rbaJWgg8Si2exZhRJeB5z51hZiEXGWldkBljvwUjevZcjo9dEqvFCY7KtxdkuA/b
ZWAyxaTJkRvzusJrRItdV6m66q5aLUKehPTeIe5zm0V10Ttfc6qOpncfULQh0d1N
Ic719F1UKYOecqZXVqJJ+mDHhdMsulvWlV18if29riQe2mu+VUGlkjFYuxgm7TCp
zKGzdDAI3v/9b5lLtKYqCDaIFjH0MnBjGo+x9gTvpvQRIrdC4OGPTiw8W3Urveln
ZycUWihsb26vqaog7jJn6SLMJ/N8nVyw64Uc/slN3tCAIwHvzpu6dTVBEoXI6Jsx
29Nqyx6B1tSXrSYXDN0PO7PmpBffS7LDEd1luYXqAtcUilgsb4Q=
=KK92
-END PGP SIGNATURE-

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

[OT] Re: How to set apache load balancer for send request to 6 tomcat server

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Zahid,

On 12/23/19 15:19, Zahid Rahman wrote:
> If your backend tomcat servers are running on different physical
> machines therefore with different ip addresses then there is
> nothing wrong with each backend  tomcat server listening on same
> port (80) of each machine. Further to mod_jk worker properties file
> redirection.
> 
> It is pointless in having multiple tomcat instances running on same
> machine , because the kernel will slice and share resources as per
> priority level setting of OS.

I disagree. There are use-cases for running multiple Tomcat instances
on the same machine.

> If you don't have heavy user activity expectations   then this
> excercise is pointless.

?

- -chris

> On Mon, 23 Dec 2019, 17:45 Giancarlo Celli,
>  wrote:
> 
>> Hi, I need to configure a load balancer with apache connector on
>> a jelastic server that redirects requests to 6 server workers
>> with tomcat 7 installed. Atteched you can find extract from
>> httpd.conf and workers.properties. I need to send single request
>> to tomcat server individually, so I set sticky_session to 0. 
>> Could you tell me if parameters are configured correctly? Is the
>> collector able to handle all requests? Could you give me some
>> further advice?
>> 
>> Each tomcat server is configured with the following parameters:
>> 
>> > connectionTimeout="2" redirectPort="8443" />
>> 
>> The balancer has the following configuration: Server version:
>> Apache/2.4.39 (codeit) Server built:   Apr  3 2019 18:54:14 
>> Architecture:   64-bit Server MPM: event threaded: yes
>> (fixed thread count) forked: yes (variable process count)
>> 
>> 
>> Thanks. Best regards.
>> 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GIuwACgkQHPApP6U8
pFgmQA//aMZLwDbtop83M7HTtM2P8vXzO7Z1cbvu5NA8yvt4IjMBA9WyrJ+XYhDn
pRHJP2S0LTLmWrZ3n8o2QpdUGkMwWwpnhuHsr1zqzwhIxWtB1tmBoIgkueM92Yk1
wXOHuy+PRlXGTRkujprb6bwUH2OxGp3Z6w3X1kqdvgJtZ6ZydBFD+eDv0epOSPay
z3gvFraikSSY6IAf2y3gI/FTMT8kjUmo+M9TnnZ2Lbjmaxg/abmRa1rypcaMLXPf
DjlQ0SAJtu2lS4wtQphY1beAsP2l/EXlMPaWIy2HbbaTBmZNtevM21OyxsWAdXQH
SNmPDIC0AycTJfpeeB3tUbAtPVBKUkoOoaMLEkuAp1JdqnrW1KGH71cAvDkdJIBK
7b8mXTE07/mVpak4XhIqfdEkTLI+QWpYDIds6xWPYFokNtfevD6ZIBjbtNyqFcgE
CEFHOkiM9JtzEOLJu24bS6MAbeYx4TnkvcZZF3hd79/Cxbusw2rlTZEvvKSSDXUn
tWi4/xeTq1o8slmWf+A241qrr4SyHdOR8XVMUT4RvXSCcmBdkh0UDsxaMXLyx/AK
yg7BxhU8d2OTmOfsFzRMCYZOpw+P+a5zE+3lNkeTbLuIamn9igKm/E7msd/enK4Z
yHWd7tof+JXHGyhtYsBlr8tM8cm9pS2R02kLHAr34s7t0TjL9D4=
=qkR+
-END PGP SIGNATURE-

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

Re: Let's Encrypt with Tomcat?

[Alex O'Ree]

i use letsencrypt with tomcat. i adopted a cronjob/bash script that auto
renews the cert before expiration, it then stops tomcat, refreshes the jks
files, then restarts tomcat. yeah it's down time, but it is minimal and it
works

On Thu, Dec 26, 2019 at 7:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:

> We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
> currently using a Java Keystore for the SSL support.
>
> We would like to be able to use Let's Encrypt, but I've learned that
> Let's Encrypt and Tomcat don't get along all that well together. The
> best I've found so far are article at:
>
> <
> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
> >
>
> and this thread in the Let's Encrypt community forum:
>
>
> <
> https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423
> >
>
> Does anybody here have any experience with situations like this? Does
> anybody here have any suggestions? Or, as another alternative, does
> anybody here know of some Amazon AWS product that could front-end a
> single-box, non-load-balanced Tomcat server, and use Amazon's free
> "Public Certificates"? (I've already posted that last to the relevant
> Amazon forum.)
>
> James H. H. Lampert
> Touchtone Corporation
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Let's Encrypt with Tomcat?

[logo]

Hi James,

Am 2019-12-27 05:31, schrieb Igal Sapir:

James,

On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:


We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
currently using a Java Keystore for the SSL support.

We would like to be able to use Let's Encrypt, but I've learned that
Let's Encrypt and Tomcat don't get along all that well together. The
best I've found so far are article at:

<
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
>

and this thread in the Let's Encrypt community forum:

<
https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423
>

Does anybody here have any experience with situations like this? Does
anybody here have any suggestions? Or, as another alternative, does
anybody here know of some Amazon AWS product that could front-end a
single-box, non-load-balanced Tomcat server, and use Amazon's free
"Public Certificates"? (I've already posted that last to the relevant
Amazon forum.)



You should check out Chris' presentations on the topic.  He outlines a 
very
efficient process.  There is probably more materials out there, but a 
quick

search brings up the video [1] and slides [2] from his presentation at
ApacheCon earlier this year, as well as his shell script for automating 
the

process.

Igal

[1] https://www.youtube.com/watch?v=BWUjvmJgSeE
[2]

https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt%20Apache%20Tomcat.pdf
[3]
https://people.apache.org/~schultz/ApacheCon%20NA%202019/lets-encrypt-renew.sh



+1

Currently the script is broken, as there is a bug in the JMX 
implementation of Tomcat 8.5 that is fixed from 8.5.51.


Once that is released it is really easy to automate the letsencrypt acme 
process with [3].


Tomcat 8.5 brings a new way to configure certificates [4]. You can use 
pem encoded certs even in the JSSE implementation.
So you can just save/copy the certs from LE to your certificate 
directory (in my case ${catalina.base}/conf/ssl):


  certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"

   certificateFile="${catalina.base}/conf/ssl/cert.pem"
   
certificateChainFile="${catalina.base}/conf/ssl/chain.pem"

   type="RSA" />

After certbot has finished, reload the SSL config for the updated Host 
through the jmxproxy and you are done.


Hope that helps.

Peter

[4] 
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig








James H. H. Lampert
Touchtone Corporation

-
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