You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2019/12/27 00:49:21 UTC
Let's Encrypt with Tomcat?
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> jamesl@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Alex O'Ree <al...@apache.org>.
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 <
jamesl@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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}&op=reload
SslHostConfig&ps=${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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by logo <lo...@kreuser.name>.
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 <
>>> jamesl@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%202018/Let's%20Enc
> rypt%20Apache%20Tomcat.pdf>
>>>
>>>
>>>
> 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):
>>
>> <Certificate
>> 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.
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}&op=reloadSslHostConfig&ps=${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
> bVljArD183gM46navyBk9xHxjaTHckGu5dramqyUYYvlG4HwGdvLk2CP780DT/Ik
> Ntacf1O3KIDUyDqKxZepSeqExWuBZc1hco08lsk+un1kF3uFIQlspCwz/8laErh5
> eQZs2Yf8GCksO0piXX1Ojo7nbG4vjuh+kwotkIcxUl2Ww/jnerE=
> =L67K
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
>> jamesl@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%202018/Let's%20Enc
rypt%20Apache%20Tomcat.pdf>
>>
>>
>>
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):
>
> <Certificate
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by logo <lo...@kreuser.name>.
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 <
> jamesl@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%202018/Let's%20Encrypt%20Apache%20Tomcat.pdf>
> 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):
<Certificate
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
> Did I? I don't recall recommending purchasing a certificate
Purchase a domain name not certificate.
On Mon, 6 Jan 2020, 16:45 Christopher Schultz, <ch...@christopherschultz.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Zahid,
>
> On 1/6/20 10:08, Zahid Rahman wrote:
> > 》> If, however, I do curl https://foo.bar.net from my Mac, I get a
> >> response, but if I do curl https://localhost, it doesn't get
> >> anywhere.
> >
> > This may be relevant. In the video mentioned earlier in the thread
> > the let's encrypt expert says let's encrypt doesn't work on
> > localhost but it only works on actual domain.
>
> Correct. You cannot obtain a certificate from Let's Encrypt for
> "localhost"; it's got to be something Let's Encrypt can resolve and
> contact from their infrastructure. For that reason, LE doesn't work
> very well for internal networks.
>
> > He goes on to say you should purchase one "it is not very expensive
> > ".
>
> Did I? I don't recall recommending purchasing a certificate during a
> presentation on zero-cost certificates.
>
> I'd never bother paying for a certificate for an internal network.
> Just self-sign and establish your own trust. The purpose of LE is for
> environments where you need *public* trust, not private trust. Private
> trust is easy to establish: you get to decide all by yourself! :)
>
> - -chris
>
> > On Mon, 6 Jan 2020, 14:57 Christopher Schultz,
> > <ch...@christopherschultz.net> wrote:
> >
> > James,
> >
> > On 1/3/20 13:47, James H. H. Lampert wrote:
> >>>> On 1/3/20 9:57 AM, Christopher Schultz wrote:
> >>>>> Is perhaps the AWS firewall (which is a Load Balancer,
> >>>>> right?) redirecting the port?
> >>>>>
> >>>>> Easy test (from the server):
> >>>>>
> >>>>> $ telnet localhost 443
> >>>>
> >>>> I hadn't thought of that. But alas, that instance doesn't
> >>>> have Telnet on it.
> >>>>
> >>>>> If it connects, you have something on the host making this
> >>>>> work. If it fails to connect, the 443 -> 8443 magic is
> >>>>> outside the host itself.
> >>>>
> >>>> If, however, I do curl https://foo.bar.net from my Mac, I get
> >>>> a response, but if I do curl https://localhost, it doesn't
> >>>> get anywhere.
> >
> > So your instance is indeed listening on 8443 and the host (at least
> > on the loopback interface) isn't doing any port 443
> > funny-business.
> >
> >>>>> Note that if you are using AWS load-balancer, AWS provides
> >>>>> free certificates that auto-renew; just configure them and
> >>>>> you are done forever.
> >>>>
> >>>>> Let me know about the Load-Balancer. That's probably the
> >>>>> piece of the puzzle you aren't looking at quite yet.
> >>>>
> >>>> No; we *have* load-balanced clusters, and they *are* (as of
> >>>> last month) on AWS's certificate system, so I know what that
> >>>> looks like. This is completely different; when I connect, I
> >>>> see the certificate that is currently active on the Tomcat
> >>>> server (and if I plug a different cert into Tomcat, I see the
> >>>> change from my browser).
> >
> > There are also load-balancers that just move bytes and don't
> > terminate TLS. It's also possible to have the same certificate
> > installed in multiple places. I think you are going to have to look
> > around your network a little more to figure out what's happening.
> >
> > Maybe simply try:
> >
> > $ host foo.bar.net
> >
> > And check the IP versus the IP of the Tomcat node?
> >
> > -chris
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TZB0ACgkQHPApP6U8
> pFib/A//TRP6v+GXvkDw7DXMcP3EzQSCEZ6yzdKoL4cblDLwW1Upe5TWVtEvHdiG
> IoqKesMwIUQQQDlv2Z3x6N5iCe9G5cTyFsz0JlSPZxGiHNGF1viwVrH/fGSsDLbp
> V2Q9HDdmp6zApl12+8HI1akCxHTPfySKg3j9NjEJlpbEA8w+Gzok+5UbjI3LzQgK
> c2iCN2Uj2mLoH135jMrdBbmYOb3rD0oEiiZY/fNch5C9bVGI5hiP7APTz8EEsjiq
> ei7eL4X0B/p+q6lgDSmvylD42TrTnpfESpiSitSZoFtM03alFdRm4OySzXuXK8za
> tYtAIha+VQs1i3y7LdRB6mIsl5xsU1NtrqGDl9lSg5ciFjuLpIQNRFDI3kqa8KwA
> FgiYOLsQZASK4bjoULQCAlcK55TBCALnbjL8PGu55YAPXO895hkeFtWokDciX+8B
> RRMqRyY2OWOoUNDZKan9icEk93vArKPU4JoVGJyvH0HCFTk+HL2B9F5s2PYvc3WO
> g+iVQdXBlDi4ngYsY0TXWC4GKBPgKVBuylJbAwbyBumpLYExIiYANn9ldtxtK9mr
> ukdlo5fvvlGclVgfL9CygsHiGgz6+aeo/n+3VkOSBsfxRHbYuw0JERicRnVImt2r
> O5ulCHoN4LwdRqhAc4BxzrnTsdrqKeyv2Qn3ANhJbpz7qNImI5o=
> =kBdi
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Zahid,
On 1/6/20 10:08, Zahid Rahman wrote:
> 》> If, however, I do curl https://foo.bar.net from my Mac, I get a
>> response, but if I do curl https://localhost, it doesn't get
>> anywhere.
>
> This may be relevant. In the video mentioned earlier in the thread
> the let's encrypt expert says let's encrypt doesn't work on
> localhost but it only works on actual domain.
Correct. You cannot obtain a certificate from Let's Encrypt for
"localhost"; it's got to be something Let's Encrypt can resolve and
contact from their infrastructure. For that reason, LE doesn't work
very well for internal networks.
> He goes on to say you should purchase one "it is not very expensive
> ".
Did I? I don't recall recommending purchasing a certificate during a
presentation on zero-cost certificates.
I'd never bother paying for a certificate for an internal network.
Just self-sign and establish your own trust. The purpose of LE is for
environments where you need *public* trust, not private trust. Private
trust is easy to establish: you get to decide all by yourself! :)
- -chris
> On Mon, 6 Jan 2020, 14:57 Christopher Schultz,
> <ch...@christopherschultz.net> wrote:
>
> James,
>
> On 1/3/20 13:47, James H. H. Lampert wrote:
>>>> On 1/3/20 9:57 AM, Christopher Schultz wrote:
>>>>> Is perhaps the AWS firewall (which is a Load Balancer,
>>>>> right?) redirecting the port?
>>>>>
>>>>> Easy test (from the server):
>>>>>
>>>>> $ telnet localhost 443
>>>>
>>>> I hadn't thought of that. But alas, that instance doesn't
>>>> have Telnet on it.
>>>>
>>>>> If it connects, you have something on the host making this
>>>>> work. If it fails to connect, the 443 -> 8443 magic is
>>>>> outside the host itself.
>>>>
>>>> If, however, I do curl https://foo.bar.net from my Mac, I get
>>>> a response, but if I do curl https://localhost, it doesn't
>>>> get anywhere.
>
> So your instance is indeed listening on 8443 and the host (at least
> on the loopback interface) isn't doing any port 443
> funny-business.
>
>>>>> Note that if you are using AWS load-balancer, AWS provides
>>>>> free certificates that auto-renew; just configure them and
>>>>> you are done forever.
>>>>
>>>>> Let me know about the Load-Balancer. That's probably the
>>>>> piece of the puzzle you aren't looking at quite yet.
>>>>
>>>> No; we *have* load-balanced clusters, and they *are* (as of
>>>> last month) on AWS's certificate system, so I know what that
>>>> looks like. This is completely different; when I connect, I
>>>> see the certificate that is currently active on the Tomcat
>>>> server (and if I plug a different cert into Tomcat, I see the
>>>> change from my browser).
>
> There are also load-balancers that just move bytes and don't
> terminate TLS. It's also possible to have the same certificate
> installed in multiple places. I think you are going to have to look
> around your network a little more to figure out what's happening.
>
> Maybe simply try:
>
> $ host foo.bar.net
>
> And check the IP versus the IP of the Tomcat node?
>
> -chris
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TZB0ACgkQHPApP6U8
pFib/A//TRP6v+GXvkDw7DXMcP3EzQSCEZ6yzdKoL4cblDLwW1Upe5TWVtEvHdiG
IoqKesMwIUQQQDlv2Z3x6N5iCe9G5cTyFsz0JlSPZxGiHNGF1viwVrH/fGSsDLbp
V2Q9HDdmp6zApl12+8HI1akCxHTPfySKg3j9NjEJlpbEA8w+Gzok+5UbjI3LzQgK
c2iCN2Uj2mLoH135jMrdBbmYOb3rD0oEiiZY/fNch5C9bVGI5hiP7APTz8EEsjiq
ei7eL4X0B/p+q6lgDSmvylD42TrTnpfESpiSitSZoFtM03alFdRm4OySzXuXK8za
tYtAIha+VQs1i3y7LdRB6mIsl5xsU1NtrqGDl9lSg5ciFjuLpIQNRFDI3kqa8KwA
FgiYOLsQZASK4bjoULQCAlcK55TBCALnbjL8PGu55YAPXO895hkeFtWokDciX+8B
RRMqRyY2OWOoUNDZKan9icEk93vArKPU4JoVGJyvH0HCFTk+HL2B9F5s2PYvc3WO
g+iVQdXBlDi4ngYsY0TXWC4GKBPgKVBuylJbAwbyBumpLYExIiYANn9ldtxtK9mr
ukdlo5fvvlGclVgfL9CygsHiGgz6+aeo/n+3VkOSBsfxRHbYuw0JERicRnVImt2r
O5ulCHoN4LwdRqhAc4BxzrnTsdrqKeyv2Qn3ANhJbpz7qNImI5o=
=kBdi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
》> If, however, I do curl https://foo.bar.net from my Mac, I get a
> response, but if I do curl https://localhost, it doesn't get
> anywhere.
This may be relevant. In the video mentioned earlier in the thread the
let's encrypt expert says let's encrypt doesn't work on localhost but
it only works on actual domain. He goes on to say you should purchase one
"it is not very expensive ".
On Mon, 6 Jan 2020, 14:57 Christopher Schultz, <ch...@christopherschultz.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> James,
>
> On 1/3/20 13:47, James H. H. Lampert wrote:
> > On 1/3/20 9:57 AM, Christopher Schultz wrote:
> >> Is perhaps the AWS firewall (which is a Load Balancer, right?)
> >> redirecting the port?
> >>
> >> Easy test (from the server):
> >>
> >> $ telnet localhost 443
> >
> > I hadn't thought of that. But alas, that instance doesn't have
> > Telnet on it.
> >
> >> If it connects, you have something on the host making this work.
> >> If it fails to connect, the 443 -> 8443 magic is outside the host
> >> itself.
> >
> > If, however, I do curl https://foo.bar.net from my Mac, I get a
> > response, but if I do curl https://localhost, it doesn't get
> > anywhere.
>
> So your instance is indeed listening on 8443 and the host (at least on
> the loopback interface) isn't doing any port 443 funny-business.
>
> >> Note that if you are using AWS load-balancer, AWS provides free
> >> certificates that auto-renew; just configure them and you are
> >> done forever.
> >
> >> Let me know about the Load-Balancer. That's probably the piece of
> >> the puzzle you aren't looking at quite yet.
> >
> > No; we *have* load-balanced clusters, and they *are* (as of last
> > month) on AWS's certificate system, so I know what that looks like.
> > This is completely different; when I connect, I see the certificate
> > that is currently active on the Tomcat server (and if I plug a
> > different cert into Tomcat, I see the change from my browser).
>
> There are also load-balancers that just move bytes and don't terminate
> TLS. It's also possible to have the same certificate installed in
> multiple places. I think you are going to have to look around your
> network a little more to figure out what's happening.
>
> Maybe simply try:
>
> $ host foo.bar.net
>
> And check the IP versus the IP of the Tomcat node?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TSsMACgkQHPApP6U8
> pFgvHw//fBItKsqFiCNeA5lLwo6hi6tZaZY6BxC24SQfMPFe4TaQKkvl/ziGdvpc
> E7afIiahzkksZ5Afeq08xx5yE16XVWNDfXy005x5TjosK9tq+msYQU0RUXiHolPo
> iTNMfVAi7vHx4OYciJzDzV34vb8pF4Xl4AlMj/ESh38BUPsZWQtcpzmMi9Nf9+/q
> grQonVVKHBIydBSbygpiHBGcPesJX0kRUtpArVIWJZdw+V+lKApeo32Xw1Y+Dm0q
> 1knwGFzHYGdxROCCpez8dq83ABI5l4tmVMPYpTZsTxBrebZxXxy2GUfrRHTH8UaC
> E1ew1jHhYwyPWIUQjEAWynKqVZ8OFcBlRN3DwFvNCGMyd5c9vyE50qfRwzYqeQMk
> tEnNafRgWGdsiw0El79m6Xl3LVOd9psSYTgvobqICPk27YhPbpk7izR5td2stvxu
> wnmfgxBJd9lL/ckwkvQfKgsdQSnCx8ULJgNUWyCv/gKrhBuBK1gkRrHj3MbJM5Cf
> A7fquztvXVZdTnAuEBLvAhKdmIYX6k7W/TnX1kvJcBQ0AN1WhcbmnxQhcww2bn5s
> LB2VA91XKg8BaNItodEx03EsUEpbjIvxmnBoCbTgYxcVaKs76qxzP9DENZmGNV/b
> JTSEo7xAyGnRQ42l4pm1Lxj/8kAZLrZ5VfNK2DBmmDTeZ8eCUAI=
> =372g
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/6/20 11:29 AM, Christopher Schultz wrote:
> I think Route 53 always uses a load-balancer, doesn't it?
No. A load balancer implies the existence of a cluster, and this is a
single instance, with a fixed IP address, and that is the address in the
A record under Route 53.
And if a load balancer were involved, then something would show up under
load balancing: either a load balancer specific to this instance, or
something tying this instance to a load balancer on one of our two clusters.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/7/20 4:54 PM, Christopher Schultz wrote:
> I have further confused you, because TCP packets+connections also have
> state, and I misspoke.
Think nothing of it: at my age, I'm easily confused.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/7/20 7:22 PM, James H. H. Lampert wrote:
> On 1/7/20 4:17 PM, Christopher Schultz wrote:
>> iptables doesn't work on pipes, it works on packets. So you have
>> to redirect both incoming AND outgoing packets. That's why you
>> have the "output redirect" as well as the (more obvious) "input
>> redirect".
>
> Well, that just leaves me more puzzled than ever: why would our
> webapp (and Manager, for that matter) "work just fine" even though
> there's no sign of an output redirect in the iptables-save output
> (which I posted in its entirety)?
I have further confused you, because TCP packets+connections also have
state, and I misspoke. For UDP, you'd need the output redirect. The
TCP stack knows where the packets from a particular connection came
from, so responses along the same connection will go back the way they
came (this is NAT).
I'm not sure under what circumstances you need an OUTPUT redirect. I
seem to remember in my testing that I did indeed require the OUTPUT
redirect for things to work properly, but I may be making that up. The
slides mention that you "may need" those, and so I went ahead and put
the commands into the slides to show how to do it, if necessary.
Actually, it's not INPUT and OUTPUT, it's PREROUTING and POSTROUTING.
But those are basically the same concept for NAT as INPUT/OUTPUT are
for the "filter" tables.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VKC8ACgkQHPApP6U8
pFjqSRAAtKLif+WBswtmW8jOswhHn2SNRX2jUPm/RYOf7YqEFMYgeunA6GqewcT0
E2AVcBangWNGLuMWaaDhmFb5S4KcgW2c5HlbafBVtdggESkfjzozJnBw+sg6ShbZ
SxRQ4Lty/WwczAwduHkOaG7pFIeQlTKLSA1wL5zCJ02hQllYa1CYGIxMRAbwqu/m
1oC0jgiJs1zGXQN7XlgZdTD6uyHuUEhSLzh0it8+QtWEoLtki+LcvRy+Bmv+nEtw
ssqHpCX+TD4PnhcLpgFqWzy3DrUJYPUdV6dExnBujrFe2tzBAYtZfDy+Gshb6efo
LtGdLwaHgd6BLA71wEUEGMr85o9Opeuu1l3niENP/WaOuELidre3+umAVWr5Ypdq
zSGhO6clt6V9JCpXqM1EWh18hjDomKLb6Q1V9hpeTbBodmr8yFGo6D9pv9lddRyD
ArXxmqvL3aUSWXb80zrsUuPYXTO+SIbIXJRSJGPVRWM7eCrO8o1VpeTcD1bsXnPz
3l32YDEd6hbWjwLMWKzWu4oIuoZlHiCgsx4Tm2T0KtdBRn2/kStTLIoXOF5s129Y
ewZ0ygViiPqnTL1QD1jwnKG7EuAplx9ppKXCRM1MSbbB/+VSjdwDFvQCAnVykLhg
IB0AniJsaYP6BnPIGHcihPU3mj7Qp9uGcm/3QeAIwX0ULf1iEKs=
=tP73
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/7/20 4:17 PM, Christopher Schultz wrote:
> iptables doesn't work on pipes, it works on packets. So you have to
> redirect both incoming AND outgoing packets. That's why you have the
> "output redirect" as well as the (more obvious) "input redirect".
Well, that just leaves me more puzzled than ever: why would our webapp
(and Manager, for that matter) "work just fine" even though there's no
sign of an output redirect in the iptables-save output (which I posted
in its entirety)?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/7/20 12:28 PM, James H. H. Lampert wrote:
> On 1/7/20 7:32 AM, Christopher Schultz wrote:
>> Hah, sorry about that. Nobody thought of specifying that only
>> root can view the iptables stuff. :)
>
> Not your fault, nor that of anybody else here; I blame the author
> of iptables and iptables-save: it should either (a) allow *anybody*
> to *see* the information, or (b) *tell* the user that he/she is
> not authorized to see it.
>
> While I occasionally use "quiet failure" myself, when writing code
> to protect database fields from unauthorized modification, I
> generally do so only when it actually makes sense, and the user can
> actually *see* that his or her attempt to change the value(s) was
> quietly ignored.
>
> ***
>
> But I'm still puzzled about the "output redirect" specified in the
> presentation, but absent from this installation (and yet it still
> works just fine).
iptables doesn't work on pipes, it works on packets. So you have to
redirect both incoming AND outgoing packets. That's why you have the
"output redirect" as well as the (more obvious) "input redirect".
> Does the "proxyPort" clause on the connector have something to do
> with it "working just fine" without the "output redirect"?
The proxyPort is just a configuration option which overrides the port
that will be used when Tomcat is building URLs that point back to
itself (e.g. Location: for redirects). If Tomcat is listening on port
8443, then, obviously, port 8443 should be used. But if there is a
reverse-proxy in the way (or some other hand-wavy magic like
iptables), then you want to use the port that the CLIENT needs to use
to get back to you, regardless of the actual port being bound to by
Tomcat.
It's just like setting the virtual host hostname: you can't just
take-over "microsoft.com" by setting your <VirtualHost>'s hostname to
"microsoft.com". But if you don't do that, your users might be sent to
"node-1-6-2-4-6-32-34.binhost.net" which isn't quite what you want.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VH60ACgkQHPApP6U8
pFiW/g//VnCbgnHs/fbsxKANfdIwNGSZP37SEkfLMOzQxBK9eC6nb6LQeWHw5FQd
8yVFVP1LnbvM0ey+UDhWME7Chbm9iyLfpMO09BqAuzcJWopODk9JYQOn0YFJsiVh
kcKeoUGLV1nw4I3qPdh0fjVRV6GDwSpt9XXZvwOZdIbqBUrS+rGuobBDJU5SaA8y
SSVzTYKqoHryJAt7yNiPkulrqpS7rgmiLbm/RvDfF5VFnaYMfh3/Mz7kmBhcvDDC
lkG2+Zs29g/mQ3YyCoKCKLfs0m7bS3WHlxv9qwsZkJzx0Rql2LJ1PSgPnO9vh4VH
LecAk9/6rQGySVuDY4f8r265Gm/jDAn5z+WWT8mv6FsbZZckYbm4f+8DYhxzWjh0
jYJNJf0dOorjjUY7hIQKw9k+QQgBKdufKtfHpDK5u1MIYsC8pdrzyjN9LFl566ad
ESEtlXjnFCzCr9wobi7YJAJLXc9rFsd/IoN988Oui69RIroqZWL6Jjxetj4fDr+8
RiJiTiSl8yWXZuSpkHrQuIrD4eLSpdoOWkrNJOOzDExuJbTpPpFABjapqSrWDEV/
BP0+xAKzeH4RMHLyUciVzw4czRe8DB/0mOBIxSv5z2LXKlef07McFzg8ACOsMCS2
oCG7vXqh7iZbNdB+AKhFs0+TIxJNcBe8bT75t0LF7xgcD0nyXf4=
=67mG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/7/20 7:32 AM, Christopher Schultz wrote:
> Hah, sorry about that. Nobody thought of specifying that only root can
> view the iptables stuff. :)
Not your fault, nor that of anybody else here; I blame the author of
iptables and iptables-save: it should either (a) allow *anybody* to
*see* the information, or (b) *tell* the user that he/she is not
authorized to see it.
While I occasionally use "quiet failure" myself, when writing code to
protect database fields from unauthorized modification, I generally do
so only when it actually makes sense, and the user can actually *see*
that his or her attempt to change the value(s) was quietly ignored.
***
But I'm still puzzled about the "output redirect" specified in the
presentation, but absent from this installation (and yet it still works
just fine). Does the "proxyPort" clause on the connector have something
to do with it "working just fine" without the "output redirect"?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/6/20 4:28 PM, James H. H. Lampert wrote:
> I think I found something, with the help of "MLu" on ServerFault:
>
> He advised me to try "iptables -L" and "iptables-save" again, only
> this time "sudo" them.
Hah, sorry about that. Nobody thought of specifying that only root can
view the iptables stuff. :)
> When I did "iptables -L" under root privileges, I still only got
> column headings, but when I did "iptables-save" under root
> privileges, I hit what appears to be paydirt:
>> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020
>> *filter :INPUT ACCEPT [5018099:5766179544] :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [4555500:2863742410] COMMIT
This means "no filtering". You have a firewall, so that's fine.
>> # Completed on Mon Jan 6 21:17:22 2020 # Generated by
>> iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 *nat
>> :PREROUTING ACCEPT [41828:2351495] :INPUT ACCEPT [76356:4167904]
>> :OUTPUT ACCEPT [254990:18418937] :POSTROUTING ACCEPT
>> [254990:18418937] -A PREROUTING -p tcp -m tcp --dport 443 -j
>> REDIRECT --to-ports 8443 COMMIT
This means that the NAT table is being used to forward port 443 ->
8443 just like we were all assuming, but hadn't yet proven.
>> # Completed on Mon Jan 6 21:17:22 2020
>
> Other than the one obvious line near the bottom,
>> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports
>> 8443
> I'm not entirely sure what all of this means, nor do I remember
> what I did to set it up.
This definitely means that clients can connect to host:443 and will
actually communicate with host:8443. Mystery solved!
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4UpIQACgkQHPApP6U8
pFgHWg/9GkBh1aVeCqqUmKd4l8BcBTrYGCEdVf5FxirWHwWTbmqAY5NYwDPqNOEU
OzOrdbFr6O4tbrcrQGg78pD/ZqhyuwyTKN+NY41/IOFBegbB7ziHyGMNWt81mWbW
n9yYQblEHDkwrdLxu1p6l9DFLsNkWmZxbIE+Ktp8Dyvocv0rfeEh6Ht2jQGOyWKm
m4xhgIc9i9ewGglpRoOwJmfSYuHLs8ijw8CA7owfMz+A3brS4RzreNzLW1nxU7m0
1neLHu2e8AFHw0CPb8NAMt4kC1Rf67wyLbxE2umOPIK16V6yIY96fWmkFNqIlHCl
tiY2oncn6A9jG4r86W2i1MHMEust8a2d/F/bvL5Yjiw26TMr+T5rL/EFU6debTfW
jkFSCS2gFaUM/bBb78d6vQfmpHTj17lP87YK4YJtjQT5/SAXnnty8g7PtOO+jp+W
6gaHYKp1TSYPareexO9NcNd4QM6aWMjMqNgNqiPnggZ6We1Xc+eK7U7kmMpp3hee
7Jggk4oM7G7d8ld1KNW5lRvEGc15E39ZEstFP0UJ78qbHv0ROlh4xoD0lhkW00YB
fC4P4RQE4nwCbDRC7hd2vNPPrSKu6IKo/rwTcGl7yPpi0oX1eTg0AYkaxd2MOTX8
o7NemE0CY01Y65Fev7Yir/WRBxuC1wfuJb1U91t8WblAejQV5bU=
=z5M1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
I think I found something, with the help of "MLu" on ServerFault:
He advised me to try "iptables -L" and "iptables-save" again, only this
time "sudo" them.
When I did "iptables -L" under root privileges, I still only got column
headings, but when I did "iptables-save" under root privileges, I hit
what appears to be paydirt:
> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020
> *filter
> :INPUT ACCEPT [5018099:5766179544]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [4555500:2863742410]
> COMMIT
> # Completed on Mon Jan 6 21:17:22 2020
> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020
> *nat
> :PREROUTING ACCEPT [41828:2351495]
> :INPUT ACCEPT [76356:4167904]
> :OUTPUT ACCEPT [254990:18418937]
> :POSTROUTING ACCEPT [254990:18418937]
> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
> COMMIT
> # Completed on Mon Jan 6 21:17:22 2020
Other than the one obvious line near the bottom,
> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
I'm not entirely sure what all of this means, nor do I remember what I
did to set it up.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with
Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/6/20 9:10 PM, James H. H. Lampert wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly
> brace, and an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent,
> and the -k!)
>
>> curl -k
>> "https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3A
type%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=relo
adSslHostConfigs"
>>
>
>>
> I get curl: (3) [globbing] unmatched brace in column xx
>
> If I change the curly brace to "%7B," I get:
>
>> curl -k
>> "https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%
3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=re
loadSslHostConfigs"
>>
>
>>
> I get curl: (3) Port number ended with 'n'
>
> And if I put the user-ID and password in with a -u clause on curl,
> rather than in the URL itself, I get "Unauthorized."
>
> What is wrong here? Are there characters it simply can't tolerate
> in passwords, even if URL-escaped?
>
> Or do I need to give the manager user an additional role?
> Currently, I have: <user username="foo" password="b?a{r"
> roles="manager-gui"/>
You need another role. The role necessary for jmxproxy is "manager-jmx".
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4Up+EACgkQHPApP6U8
pFjy0xAAmwbNbBSnW5mydxPPSD5OXyJW13wmLtZy2BoMyV5E6HR9wu/u79i27VbI
qfNoIMk3K1wAKNTzuBOtM+cUgXaiFBZeehXuN9lF2AvqiOnp948n3JXrY2JvAovk
Adr3tsx+21nZgNVaVTsEezdKcad+odCRVWER52eVKdnz8In3oh4bWXOEcHQ6T22o
/o+JvQY0kjrRFGMWGHGUu7EvtzM+zawf3RDMuRD2xdhMv3MWhH5o5nrt4DalglUU
qhvZQ5RfVcjMNC43clCjdRhoz7hhCAkf6GTCkqQmVGW0KYP4x8yGxM2NFV0ft8Vc
/DJiy3h3rX6j4lE1c7XXDksUqfPx70h8RJ1ApzcYumXrGxHDUsvYzkuzsGQCBMSF
5qo1lRCgK+qaITNuc9nZIhKdtai3iojjCUr0VNN9+3wI61rNBlncPyIRrNJR2pS7
m6IeML1cKxE7c4sWr7Th4egM+NOX65E4oyv1X6vqpWZYL5TrB2Eys+zcPdG981KI
OF06FybbBW4XDpyv9ECTE9gmtqiw0LYLTz8bg9ytRqOfCgSCmUxVzIc9CTk0glgZ
3AJA8QElFlibnORB7rD1nagDBO4VYmcSXnttHrXf47jjtchWEF+cI24IUUZnbWKb
+yVgFfBJS4mqIIe7IvxYjL2I2bMTx+FWGf7erAm+/WYbMt8DAEE=
=bHGS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
https://stackoverflow.com/questions/17560858/command-prompt-having-trouble-escaping-quotes-and-braces
You can use curl -g to turn off globbing:
On Tue, 7 Jan 2020, 02:11 James H. H. Lampert, <ja...@touchtonecorp.com>
wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly brace,
> and an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent, and
> the -k!)
>
> > curl -k "https://foo:b?a{r@localhost
> :8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
>
> I get curl: (3) [globbing] unmatched brace in column xx
>
> If I change the curly brace to "%7B," I get:
>
> > curl -k "https://foo:b?a%7Br@localhost
> :8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
>
> I get curl: (3) Port number ended with 'n'
>
> And if I put the user-ID and password in with a -u clause on curl,
> rather than in the URL itself, I get "Unauthorized."
>
> What is wrong here? Are there characters it simply can't tolerate in
> passwords, even if URL-escaped?
>
> Or do I need to give the manager user an additional role? Currently, I
> have:
> <user username="foo" password="b?a{r" roles="manager-gui"/>
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with
Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
Dear Mr. Schultz, et al.:
The manager password on this Tomcat server has an embedded curly brace,
and an embedded question mark.
If I do this (the names have been changed to protect the innocent, and
the -k!)
> curl -k "https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
I get curl: (3) [globbing] unmatched brace in column xx
If I change the curly brace to "%7B," I get:
> curl -k "https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
I get curl: (3) Port number ended with 'n'
And if I put the user-ID and password in with a -u clause on curl,
rather than in the URL itself, I get "Unauthorized."
What is wrong here? Are there characters it simply can't tolerate in
passwords, even if URL-escaped?
Or do I need to give the manager user an additional role? Currently, I have:
<user username="foo" password="b?a{r" roles="manager-gui"/>
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/6/20 13:05, James H. H. Lampert wrote:
>> $ host foo.bar.net
>>
>> And check the IP versus the IP of the Tomcat node?
>
> Doing a "host" on the domain gives me the same IP address where
> the instance itself lives, which is also the address given in Route
> 53.
I think Route 53 always uses a load-balancer, doesn't it?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TiowACgkQHPApP6U8
pFgiGw//bFJf2zl+A2FEDHl/vnFycLaW0VqzAkFtoG5Rwbzhim6788qTruJmzcR1
Bs/zmOVTJeoj7B8KQhmpO3+T6QLn+lrQ/Ik+AqBSZRAfTFcHEgeGQWrD8MuPadqI
vzu7VdDKI5QwPVzPoJPzf6UKb2cQgOrn7PP08wpvcm97UCKATXyYS6T2KsGqpo6x
nXL9BKcGcCYTDlkSK2V8f0wNLpocTVPnshm33eZz/EK6CLPbcj0A7lHBg7JscQlR
Ax7prdjhD80nY+4wK9rs9nZL5JTttrKzS+CXhECJPncGE8lswTWuIvmSFqdowZfw
biv6KJkiZlAdPzZthRWymt46njJzHumG7CY5WANU/Y3QezSCNmcXjG8VY8W3gWjS
sMM3+tPOcnRIHX5cJGswo+0QImhQCdxmZVKBt2imaXhvLUAyzDMi6NT3RyHWQxT2
kwmqJpmPurL3UAWeZslICAqjFPql6ADeLIoXgRdIxvYD0FAKBemz220FNaG8/Dil
hkitBAZf0dkdPfIYM3xLS5J2XoWxIcni3BZKXCeYYCC4sHth3SbT596N4KXeJamm
NUxQh5baPydZ38CmOtcnYiy2r4j/jz20B2VaPtp67jHtBtelmFx+yaVZvNHwxZ7V
tUJLvzwbcwGNMq+T2uxXM+NvDx65ruQHENtvp1lZepT2m/yCjdM=
=pf56
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
> $ host foo.bar.net
>
> And check the IP versus the IP of the Tomcat node?
Doing a "host" on the domain gives me the same IP address where the
instance itself lives, which is also the address given in Route 53.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/3/20 13:47, James H. H. Lampert wrote:
> On 1/3/20 9:57 AM, Christopher Schultz wrote:
>> Is perhaps the AWS firewall (which is a Load Balancer, right?)
>> redirecting the port?
>>
>> Easy test (from the server):
>>
>> $ telnet localhost 443
>
> I hadn't thought of that. But alas, that instance doesn't have
> Telnet on it.
>
>> If it connects, you have something on the host making this work.
>> If it fails to connect, the 443 -> 8443 magic is outside the host
>> itself.
>
> If, however, I do curl https://foo.bar.net from my Mac, I get a
> response, but if I do curl https://localhost, it doesn't get
> anywhere.
So your instance is indeed listening on 8443 and the host (at least on
the loopback interface) isn't doing any port 443 funny-business.
>> Note that if you are using AWS load-balancer, AWS provides free
>> certificates that auto-renew; just configure them and you are
>> done forever.
>
>> Let me know about the Load-Balancer. That's probably the piece of
>> the puzzle you aren't looking at quite yet.
>
> No; we *have* load-balanced clusters, and they *are* (as of last
> month) on AWS's certificate system, so I know what that looks like.
> This is completely different; when I connect, I see the certificate
> that is currently active on the Tomcat server (and if I plug a
> different cert into Tomcat, I see the change from my browser).
There are also load-balancers that just move bytes and don't terminate
TLS. It's also possible to have the same certificate installed in
multiple places. I think you are going to have to look around your
network a little more to figure out what's happening.
Maybe simply try:
$ host foo.bar.net
And check the IP versus the IP of the Tomcat node?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TSsMACgkQHPApP6U8
pFgvHw//fBItKsqFiCNeA5lLwo6hi6tZaZY6BxC24SQfMPFe4TaQKkvl/ziGdvpc
E7afIiahzkksZ5Afeq08xx5yE16XVWNDfXy005x5TjosK9tq+msYQU0RUXiHolPo
iTNMfVAi7vHx4OYciJzDzV34vb8pF4Xl4AlMj/ESh38BUPsZWQtcpzmMi9Nf9+/q
grQonVVKHBIydBSbygpiHBGcPesJX0kRUtpArVIWJZdw+V+lKApeo32Xw1Y+Dm0q
1knwGFzHYGdxROCCpez8dq83ABI5l4tmVMPYpTZsTxBrebZxXxy2GUfrRHTH8UaC
E1ew1jHhYwyPWIUQjEAWynKqVZ8OFcBlRN3DwFvNCGMyd5c9vyE50qfRwzYqeQMk
tEnNafRgWGdsiw0El79m6Xl3LVOd9psSYTgvobqICPk27YhPbpk7izR5td2stvxu
wnmfgxBJd9lL/ckwkvQfKgsdQSnCx8ULJgNUWyCv/gKrhBuBK1gkRrHj3MbJM5Cf
A7fquztvXVZdTnAuEBLvAhKdmIYX6k7W/TnX1kvJcBQ0AN1WhcbmnxQhcww2bn5s
LB2VA91XKg8BaNItodEx03EsUEpbjIvxmnBoCbTgYxcVaKs76qxzP9DENZmGNV/b
JTSEo7xAyGnRQ42l4pm1Lxj/8kAZLrZ5VfNK2DBmmDTeZ8eCUAI=
=372g
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/3/20 9:57 AM, Christopher Schultz wrote:
> Is perhaps the AWS firewall (which is a Load Balancer, right?)
> redirecting the port?
>
> Easy test (from the server):
>
> $ telnet localhost 443
I hadn't thought of that. But alas, that instance doesn't have Telnet on it.
> If it connects, you have something on the host making this work. If it
> fails to connect, the 443 -> 8443 magic is outside the host itself.
If, however, I do curl https://foo.bar.net from my Mac, I get a
response, but if I do curl https://localhost, it doesn't get anywhere.
> Note that if you are using AWS load-balancer, AWS provides free
> certificates that auto-renew; just configure them and you are done
> forever.
> Let me know about the Load-Balancer. That's probably the piece of the
> puzzle you aren't looking at quite yet.
No; we *have* load-balanced clusters, and they *are* (as of last month)
on AWS's certificate system, so I know what that looks like. This is
completely different; when I connect, I see the certificate that is
currently active on the Tomcat server (and if I plug a different cert
into Tomcat, I see the change from my browser).
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/2/20 19:45, James H. H. Lampert wrote:
>>>>> 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?
>
> On 12/30/19 1:41 PM, Peter Kreuser wrote:
>> Correct!
>
> Great. Then if I can figure out how to get this thing
>
> I'm studying the server under discussion, and I can't figure out
> what I did, some six months ago, to make Tomcat look like 443 to
> the outside world.
>
> Here is what I do know: * It's an AWS EC2 instance.
>
> * There is no load balancer involved.
>
> * The only active connector in server.xml has it listening on 8443,
> with a proxyPort clause specifying 443.
>
> * If I do a netstat, I find that something is indeed listening on
> 8443, but nothing is listening on 443.
>
> * If I look at the AWS console, if there is something translating
> 443 to 8443, I can't find it.
>
> * If I do an "iptables -L," I get only column headings.
>
> * There are evidently two copies of Apache httpd on the box, one
> of which evidently came with the OS, and the other of which
> evidently came with the Bitnami SVN/Trac stack. Only the latter
> copy is active. It is listening on ports 81 (unsecured, but blocked
> by the firewall) and 8000 (secured).
>
> * If I open port 81 up to my own IP (in the AWS firewall), I can
> reach the same SVN/Trac landing page on unsecured port 81 that I
> can on secured port 8000.
Is perhaps the AWS firewall (which is a Load Balancer, right?)
redirecting the port?
Easy test (from the server):
$ telnet localhost 443
If it connects, you have something on the host making this work. If it
fails to connect, the 443 -> 8443 magic is outside the host itself.
Note that if you are using AWS load-balancer, AWS provides free
certificates that auto-renew; just configure them and you are done
forever.
Also, AWS will happily connect to an EC2 server with a self-signed
certificate, so there is no need to use Let's Encrypt for your
host-specific certificates. Just generate a long-lived self-signed
certificate and you are done for a while. You are still welcome to
rotate your certs as often as you'd like. The only reason to use Let's
Encrypt is if you want OTHER clients to trust your own certificate.
> * Tomcat is running completely independently of the active httpd:
> if I shut down the active httpd, Tomcat still responds.
>
> * I was able to find the apache VirtualHost configurations (in a
> file called bitnami.conf, naturally), and by replacing the one for
> port 81 with (and once again, domain names have been changed to
> protect the innocent):
>> <VirtualHost _default_:81> ServerName foo.bar.net Redirect
>> permanent / https://foo.bar.net:8000/ </VirtualHost>
> the unsecured Port 81 now redirects to 80. Conversely, if I leave
> out the :8000 it redirects to the Tomcat server.
>
> * Like a complete and utter idiot, I left no notes whatsoever about
> how I set this thing up in the first place. Probably because I
> didn't fully understand what I'd done, or how.
>
> * Just as it was when I *was* setting this thing up in the first
> place, httpd configuration files (that can be all over the place)
> make me long for the simplicity of Tomcat configuration files.
>
> I *think* I can *probably* get Apache (and a cron job running
> certbot) on Let's Encrypt, and Tomcat using its certs (and a cron
> job reloading them), without understanding what I'd done to get
> Tomcat showing up on 443 to the outside world, but it would be nice
> if I *did* understand what I'd done.
Let me know about the Load-Balancer. That's probably the piece of the
puzzle you aren't looking at quite yet.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4PgIEACgkQHPApP6U8
pFgvtg/8DPjUrMAsW6oreNhOK1Aj4GmKgZHUJZsW/RBkgg5CTvwiFnVAxfAF3SP6
0Lill24qp9ZGvoq3FQC9sKu68N7nQCfSbNn6D54by7YscAtAL42puUxOPXOTDlLl
sG0fHbZA6YAYuoVprpT5LuVODwSu13v9rOtCKJWZROWymKTuUf3C8oZgo2aYc/PS
FScWwcGbtPgkgO7tuOY9QsmuJMqOj73Z1lq86voU9cW0PCH8cik/Wp2iS+30XbRH
c+J+Yirie7WrDa7wVRBPm76sDGSmmyRy+DeR9dwuzFiixQOdsuP/Lsgp/2y+rc+M
VbBCiPWy/pS+kcJWP7R3JtfujgZzyyqkuTL/AlTnhW2OykNSoCzHHUgnTYcDdHps
udxUih+o5fikT5kJvxglvTECaY9QbizXN84Uy6S5rGCB2LMZtlDShTnF0cx+v2y1
zagbC1/5TDedGTCISqpCRu+RliuyvmPvUs8NoxgtIEvg5cqVOoVdaL9tLHZ+UxVC
0wLoboMdneyn0yEF5fe4ySefW7Do8pAyBNRJLpYg0wuQC3Q6j5Kv4CUAUOazrEyK
/AlxrhM3Zg82EecbjgfzNbq87vSQnQvosALCVvqcylC1TtWUaE1WWPhy+0hxo8y+
PVuw4KSg2BZnn2kCMlBLVNWOREDl8tTdZDfX7ASf8xaCdZx8LiE=
=ITNd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
>>>> 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?
On 12/30/19 1:41 PM, Peter Kreuser wrote:
> Correct!
Great. Then if I can figure out how to get this thing
I'm studying the server under discussion, and I can't figure out what I
did, some six months ago, to make Tomcat look like 443 to the outside world.
Here is what I do know:
* It's an AWS EC2 instance.
* There is no load balancer involved.
* The only active connector in server.xml has it listening on 8443, with
a proxyPort clause specifying 443.
* If I do a netstat, I find that something is indeed listening on 8443,
but nothing is listening on 443.
* If I look at the AWS console, if there is something translating 443 to
8443, I can't find it.
* If I do an "iptables -L," I get only column headings.
* There are evidently two copies of Apache httpd on the box, one of
which evidently came with the OS, and the other of which evidently came
with the Bitnami SVN/Trac stack. Only the latter copy is active. It is
listening on ports 81 (unsecured, but blocked by the firewall) and 8000
(secured).
* If I open port 81 up to my own IP (in the AWS firewall), I can reach
the same SVN/Trac landing page on unsecured port 81 that I can on
secured port 8000.
* Tomcat is running completely independently of the active httpd: if I
shut down the active httpd, Tomcat still responds.
* I was able to find the apache VirtualHost configurations (in a file
called bitnami.conf, naturally), and by replacing the one for port 81
with (and once again, domain names have been changed to protect the
innocent):
> <VirtualHost _default_:81>
> ServerName foo.bar.net
> Redirect permanent / https://foo.bar.net:8000/
> </VirtualHost>
the unsecured Port 81 now redirects to 80. Conversely, if I leave out
the :8000 it redirects to the Tomcat server.
* Like a complete and utter idiot, I left no notes whatsoever about how
I set this thing up in the first place. Probably because I didn't fully
understand what I'd done, or how.
* Just as it was when I *was* setting this thing up in the first place,
httpd configuration files (that can be all over the place) make me long
for the simplicity of Tomcat configuration files.
I *think* I can *probably* get Apache (and a cron job running certbot)
on Let's Encrypt, and Tomcat using its certs (and a cron job reloading
them), without understanding what I'd done to get Tomcat showing up on
443 to the outside world, but it would be nice if I *did* understand
what I'd done.
--
James H. H. Lampert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/9/20 1:24 AM, Mark Thomas wrote:
> The moderators are aware of the situation. The subscriber in question
> was blocked from making further posts an hour or so ago.
I'm glad to see that I'm not the only one who looked at those posts, and
found them less-than-helpful (I think every link he posted was one using
a JKS, and we already know they work fine), and in some cases downright
nonsensical. Although making him only the third or fourth user to be
kicked out, in the history of the List, seems a bit drastic, unless he
has a history of similar actions.
At any rate, in answer to Peter's question about my private key, the
file looks like:
> -----BEGIN RSA PRIVATE KEY-----
[REDACTED]
> -----END RSA PRIVATE KEY-----
and looking at it with KeyStore Explorer tells me it's an RSA private
key, 2048 bits, format PKCS#8.
As to the cert and chain files, the .cer file looks like:
> -----BEGIN CERTIFICATE-----
[REDACTED]
> -----END CERTIFICATE-----
and looking at it with KSE shows that it contains our certificate,
and the .ca.crt file looks like:
> -----BEGIN CERTIFICATE-----
[REDACTED]
> -----END CERTIFICATE-----
> -----BEGIN CERTIFICATE-----
[REDACTED]
> -----END CERTIFICATE-----
> -----BEGIN CERTIFICATE-----
[REDACTED]
> -----END CERTIFICATE-----
and looking at it with KSE shows that it contains "AddTrust External CA
Root," "COMODO RSA Certification Authority," and "COMODO RSA
Organization Validation Secure Server CA."
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Using the certificate files instead of a Java Keystore file,
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Everyone,
On 1/9/20 4:24 AM, Mark Thomas wrote:
> On 09/01/2020 08:27, calder wrote:
>> Moderators ?????
>
> The moderators can be contacted via users-owner@tomcat.apache.org
>
> The moderators are aware of the situation. The subscriber in
> question was blocked from making further posts an hour or so ago.
>
> Blocking a user is not a decision the moderators take lightly.
> Excluding obvious spambots, I can only think of 2 instances in the
> last 20 years before this one (it might be 3 - my memory is a
> little hazy going back that far) where a user has been blocked from
> this list. The moderators try to point out inappropriate behaviour
> and provide an opportunity for posters to change their behaviour
> before a ban is applied.
>
> The moderators appreciate that behaviour like this can be
> frustrating. We aim to deal with it as quickly as we can whilst at
> the same time trying to allow for the fact that everyone can have a
> bad day sometimes.
I would encourage the lifting of this block. We have had posters in
the past who have posted many confusing messages and frankly, it's
fairly easy to sift-out the cruft.
While some novice readers may be confused by such posts, it's up to
the rest of us to provide better and more helpful responses.
I'd prefer not to ban people unless they are being overtly abusive.
Annoying is not being abusive. Picking fights with one or two
community members is not being abusive. (Yet)
I replied to this thread instead of starting a new one because I
didn't want to start a whole new thread debating this topic. I
apologize if this reply ends up hijacking the original thread (a
second time). If you feel like this is a larger discussion to be had
on the list, please start a new thread.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4XcHcACgkQHPApP6U8
pFipQRAApFI15mbpZYeKDw++FJr5z8QzE5MAn/zKeckWA+tgOuc5hIN0lJk3lfFF
IsyOYqlrrBfrPQQd9GEaDTrxHc8vCEVPEEQWgnm+04LwiPR6Udu/ADncjaMdVw9U
j2KO5/wRoGAPl/6VfSEyxvIhW8+MZ88cM69AYIp91CCjHJBXZd59+ADXRjHcOHNo
a3otBmZ5wJnjC3tg3LwUwS2u2+jimWEqN06Dp96oXy7xmzW8+nmKY1v24J0WjW/Z
C7c2C1H/kGmi2lnolyqeYxzQmul2y9n9VkF2Uh2cmXFlWF3y99V7R3U7CXJM0FC2
seV0N9kVmbWgphYnG0Ihj6IfjbsANHjRfc+tEMT9KqIgKxR5QJPgdjNIUNN8To8u
WoJnt30q8xgbPPkvdeYaLQlQU9JwWuU5Llz7I72rraig4ZLoaJitm+oBW2vtVs3I
E9+vDQEEc3IDeU7odfNwO/18bQgz+bDf9Z3DD99XRvPKteutOMiFtiEpANpmDDZu
P7ozxoSaCe2a6pITMRl75ioXVsDTS+3fBg0682ItJl0J+MjO6Ul97f8cV9sry7Jf
iq2ucsiMT+CdSz8Xx9uKndOXyam7gbZVYvhUdtYIWUTQcF0isu9U3HJ0ipYhbhWn
9KgEq9XzHcMhTzaiEDFYaoyvUooEt/dNKmm0UF8aE+rMtuuFxCk=
=39IH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by Mark Thomas <ma...@apache.org>.
On 09/01/2020 08:27, calder wrote:
> Moderators ?????
The moderators can be contacted via users-owner@tomcat.apache.org
The moderators are aware of the situation. The subscriber in question
was blocked from making further posts an hour or so ago.
Blocking a user is not a decision the moderators take lightly. Excluding
obvious spambots, I can only think of 2 instances in the last 20 years
before this one (it might be 3 - my memory is a little hazy going back
that far) where a user has been blocked from this list. The moderators
try to point out inappropriate behaviour and provide an opportunity for
posters to change their behaviour before a ban is applied.
The moderators appreciate that behaviour like this can be frustrating.
We aim to deal with it as quickly as we can whilst at the same time
trying to allow for the fact that everyone can have a bad day sometimes.
Mark
wearing his list moderator hat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by calder <ca...@gmail.com>.
Moderators ?????
On Wed, Jan 8, 2020, 20:44 Zahid Rahman <za...@gmail.com> wrote:
>
> https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
>
> I went to college and studied IT before finding a job. My teacher explained
> to me that you should always look at the first error and ignore the rest.
>
Then your "teacher" has NO IDEA what they are talking about, as related
to log interpretation ... and now, YOU foster the same INVALID information.
When one reads a log file, if there are any "Caused by" statements, locate
the last "Caused by" in the stack trace, and that is the area of root cause.
One can see there are "Caused by's" in the stack trace, so "looking at the
first error" does NOT apply in this case.
James, do not take Zahid's information as accurate - his knowledge is
lacking.
First error.
> 08-Jan-2020 23:14:09.026 SEVERE [main]
> org.apache.catalina.core.StandardService.initInternal
> Failed to initialize connector [Connector[HTTP/1.1-8443]]
>
>
> Once that has been addressed then either the remaining will disappear or
> address the second error which will then be the first error.
>
>
> On Wed, 8 Jan 2020, 23:59 James H. H. Lampert, <ja...@touchtonecorp.com>
> wrote:
>
> > I wrote:
> > > 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?
> >
> > On 12/30/19 1:41 PM, Peter Kreuser wrote:
> > > Correct!
> >
> > I tried an experiment this afternoon:
> >
> > I made a copy of the existing server.xml file, and I changed the active
> > connector from this (keystore file and alias redacted for privacy,
> > ciphers and compressibleMimeTypes clauses redacted because they're quite
> > long, and not relevant here):
> > > <Connector port="8443" proxyPort="443"
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > compression="on" compressionMinSize="2048"
> > noCompressionUserAgents="gozilla, traviata"
> > > compressableMimeType="[REDACTED]"
> > > maxThreads="1000" socket.appReadBufSize="1024"
> > socket.appWriteBufSize="1024" bufferSize="1024"
> > > SSLEnabled="true" scheme="https" secure="true"
> > > keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
> > > clientAuth="false" sslProtocol="TLS" />
> >
> > to this:
> > > <Connector port="8443" proxyPort="443"
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > compression="on" compressionMinSize="2048"
> > noCompressionUserAgents="gozilla, traviata"
> > > compressableMimeType="[REDACTED]"
> > > maxThreads="1000" socket.appReadBufSize="1024"
> > socket.appWriteBufSize="1024" bufferSize="1024"
> > > SSLEnabled="true" scheme="https" secure="true">
> > > <SSLHostConfig ciphers="[REDACTED]"
> > > certificateVerification="none" sslProtocol="TLS">
> > > <Certificate certificateFile="[REDACTED].cer"
> > certificateKeyFile="[REDACTED].key"
> > > certificateChainFile="[REDACTED].ca.crt" />
> > > </SSLHostConfig>
> > > </Connector>
> >
> > and restarted Tomcat, and it failed to open the port, producing this in
> > catalina.out:
> > > 08-Jan-2020 23:14:09.026 SEVERE [main]
> > org.apache.catalina.core.StandardService.initInternal Failed to
> initialize
> > connector [Connector[HTTP/1.1-8443]]
> > > org.apache.catalina.LifecycleException: Failed to initialize component
> > [Connector[HTTP/1.1-8443]]
> > > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> > > at
> >
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> > > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > > at
> >
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> > > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> > > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > at java.lang.reflect.Method.invoke(Method.java:498)
> > > at
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
> > > at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> > > Caused by: org.apache.catalina.LifecycleException: Protocol handler
> > initialization failed
> > > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
> > > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > > ... 12 more
> > > Caused by: java.lang.IllegalArgumentException: Cannot store
> > non-PrivateKeys
> > > at org.apache.tomcat.util.net
> > .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> > > at org.apache.tomcat.util.net
> > .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> > > at org.apache.tomcat.util.net
> > .NioEndpoint.bind(NioEndpoint.java:244)
> > > at org.apache.tomcat.util.net
> > .AbstractEndpoint.init(AbstractEndpoint.java:1105)
> > > at org.apache.tomcat.util.net
> > .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
> > > at
> > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> > > at
> >
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> > > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> > > ... 13 more
> > > Caused by: java.security.KeyStoreException: Cannot store
> non-PrivateKeys
> > > at
> >
> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
> > > at
> >
> sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
> > > at
> >
> sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
> > > at
> >
> sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
> > > at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
> > > at org.apache.tomcat.util.net
> > .SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
> > > at org.apache.tomcat.util.net
> > .SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
> > > at org.apache.tomcat.util.net
> > .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
> > > ... 20 more
> >
> > Can anybody explain what I did wrong? These are fully-qualified paths to
> > the certificate, chain, and key files. [REDACTED].ca.crt contains a
> > certificate chain; [REDACTED].cer contains a certificate, and
> > [REDACTED].key contains a private key, and they all work in Apache
> > httpd, on the same box.
> >
> > --
> > JHHL
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
http://tomcat.10.x6.nabble.com/Can-t-Get-SSL-to-Work-in-8-5-td5071245.html
On Thu, 9 Jan 2020, 03:01 Zahid Rahman, <za...@gmail.com> wrote:
>
> https://confluence.atlassian.com/confkb/ssl-connector-fails-to-initialize-during-tomcat-startup-646251490.html
>
> On Thu, 9 Jan 2020, 02:44 Zahid Rahman, <za...@gmail.com> wrote:
>
>>
>> https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
>>
>> I went to college and studied IT before finding a job. My teacher
>> explained to me that you should always look at the first error and ignore
>> the rest.
>>
>>
>> First error.
>> 08-Jan-2020 23:14:09.026 SEVERE [main] org.apache.catalina.core.StandardService.initInternal
>> Failed to initialize connector [Connector[HTTP/1.1-8443]]
>>
>>
>> Once that has been addressed then either the remaining will disappear
>> or address the second error which will then be the first error.
>>
>>
>>
>>
>>
>>
>> On Wed, 8 Jan 2020, 23:59 James H. H. Lampert, <ja...@touchtonecorp.com>
>> wrote:
>>
>>> I wrote:
>>> > 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?
>>>
>>> On 12/30/19 1:41 PM, Peter Kreuser wrote:
>>> > Correct!
>>>
>>> I tried an experiment this afternoon:
>>>
>>> I made a copy of the existing server.xml file, and I changed the active
>>> connector from this (keystore file and alias redacted for privacy,
>>> ciphers and compressibleMimeTypes clauses redacted because they're quite
>>> long, and not relevant here):
>>> > <Connector port="8443" proxyPort="443"
>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> > compression="on" compressionMinSize="2048"
>>> noCompressionUserAgents="gozilla, traviata"
>>> > compressableMimeType="[REDACTED]"
>>> > maxThreads="1000" socket.appReadBufSize="1024"
>>> socket.appWriteBufSize="1024" bufferSize="1024"
>>> > SSLEnabled="true" scheme="https" secure="true"
>>> > keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
>>> > clientAuth="false" sslProtocol="TLS" />
>>>
>>> to this:
>>> > <Connector port="8443" proxyPort="443"
>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> > compression="on" compressionMinSize="2048"
>>> noCompressionUserAgents="gozilla, traviata"
>>> > compressableMimeType="[REDACTED]"
>>> > maxThreads="1000" socket.appReadBufSize="1024"
>>> socket.appWriteBufSize="1024" bufferSize="1024"
>>> > SSLEnabled="true" scheme="https" secure="true">
>>> > <SSLHostConfig ciphers="[REDACTED]"
>>> > certificateVerification="none" sslProtocol="TLS">
>>> > <Certificate certificateFile="[REDACTED].cer"
>>> certificateKeyFile="[REDACTED].key"
>>> > certificateChainFile="[REDACTED].ca.crt" />
>>> > </SSLHostConfig>
>>> > </Connector>
>>>
>>> and restarted Tomcat, and it failed to open the port, producing this in
>>> catalina.out:
>>> > 08-Jan-2020 23:14:09.026 SEVERE [main]
>>> org.apache.catalina.core.StandardService.initInternal Failed to initialize
>>> connector [Connector[HTTP/1.1-8443]]
>>> > org.apache.catalina.LifecycleException: Failed to initialize
>>> component [Connector[HTTP/1.1-8443]]
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>>> > at
>>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>> > at
>>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
>>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
>>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> > at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> > at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> > at java.lang.reflect.Method.invoke(Method.java:498)
>>> > at
>>> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
>>> > at
>>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
>>> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
>>> initialization failed
>>> > at
>>> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>> > ... 12 more
>>> > Caused by: java.lang.IllegalArgumentException: Cannot store
>>> non-PrivateKeys
>>> > at org.apache.tomcat.util.net
>>> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
>>> > at org.apache.tomcat.util.net
>>> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
>>> > at org.apache.tomcat.util.net
>>> .NioEndpoint.bind(NioEndpoint.java:244)
>>> > at org.apache.tomcat.util.net
>>> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
>>> > at org.apache.tomcat.util.net
>>> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
>>> > at
>>> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
>>> > at
>>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
>>> > at
>>> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
>>> > ... 13 more
>>> > Caused by: java.security.KeyStoreException: Cannot store
>>> non-PrivateKeys
>>> > at
>>> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
>>> > at
>>> sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
>>> > at
>>> sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
>>> > at
>>> sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
>>> > at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
>>> > at org.apache.tomcat.util.net
>>> .SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
>>> > at org.apache.tomcat.util.net
>>> .SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
>>> > at org.apache.tomcat.util.net
>>> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
>>> > ... 20 more
>>>
>>> Can anybody explain what I did wrong? These are fully-qualified paths to
>>> the certificate, chain, and key files. [REDACTED].ca.crt contains a
>>> certificate chain; [REDACTED].cer contains a certificate, and
>>> [REDACTED].key contains a private key, and they all work in Apache
>>> httpd, on the same box.
>>>
>>> --
>>> JHHL
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
https://confluence.atlassian.com/confkb/ssl-connector-fails-to-initialize-during-tomcat-startup-646251490.html
On Thu, 9 Jan 2020, 02:44 Zahid Rahman, <za...@gmail.com> wrote:
>
> https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
>
> I went to college and studied IT before finding a job. My teacher
> explained to me that you should always look at the first error and ignore
> the rest.
>
>
> First error.
> 08-Jan-2020 23:14:09.026 SEVERE [main] org.apache.catalina.core.StandardService.initInternal
> Failed to initialize connector [Connector[HTTP/1.1-8443]]
>
>
> Once that has been addressed then either the remaining will disappear or
> address the second error which will then be the first error.
>
>
>
>
>
>
> On Wed, 8 Jan 2020, 23:59 James H. H. Lampert, <ja...@touchtonecorp.com>
> wrote:
>
>> I wrote:
>> > 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?
>>
>> On 12/30/19 1:41 PM, Peter Kreuser wrote:
>> > Correct!
>>
>> I tried an experiment this afternoon:
>>
>> I made a copy of the existing server.xml file, and I changed the active
>> connector from this (keystore file and alias redacted for privacy,
>> ciphers and compressibleMimeTypes clauses redacted because they're quite
>> long, and not relevant here):
>> > <Connector port="8443" proxyPort="443"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> > compression="on" compressionMinSize="2048"
>> noCompressionUserAgents="gozilla, traviata"
>> > compressableMimeType="[REDACTED]"
>> > maxThreads="1000" socket.appReadBufSize="1024"
>> socket.appWriteBufSize="1024" bufferSize="1024"
>> > SSLEnabled="true" scheme="https" secure="true"
>> > keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
>> > clientAuth="false" sslProtocol="TLS" />
>>
>> to this:
>> > <Connector port="8443" proxyPort="443"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> > compression="on" compressionMinSize="2048"
>> noCompressionUserAgents="gozilla, traviata"
>> > compressableMimeType="[REDACTED]"
>> > maxThreads="1000" socket.appReadBufSize="1024"
>> socket.appWriteBufSize="1024" bufferSize="1024"
>> > SSLEnabled="true" scheme="https" secure="true">
>> > <SSLHostConfig ciphers="[REDACTED]"
>> > certificateVerification="none" sslProtocol="TLS">
>> > <Certificate certificateFile="[REDACTED].cer"
>> certificateKeyFile="[REDACTED].key"
>> > certificateChainFile="[REDACTED].ca.crt" />
>> > </SSLHostConfig>
>> > </Connector>
>>
>> and restarted Tomcat, and it failed to open the port, producing this in
>> catalina.out:
>> > 08-Jan-2020 23:14:09.026 SEVERE [main]
>> org.apache.catalina.core.StandardService.initInternal Failed to initialize
>> connector [Connector[HTTP/1.1-8443]]
>> > org.apache.catalina.LifecycleException: Failed to initialize component
>> [Connector[HTTP/1.1-8443]]
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>> > at
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> > at
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> > at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.lang.reflect.Method.invoke(Method.java:498)
>> > at
>> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
>> > at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
>> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
>> initialization failed
>> > at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> > ... 12 more
>> > Caused by: java.lang.IllegalArgumentException: Cannot store
>> non-PrivateKeys
>> > at org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
>> > at org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
>> > at org.apache.tomcat.util.net
>> .NioEndpoint.bind(NioEndpoint.java:244)
>> > at org.apache.tomcat.util.net
>> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
>> > at org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
>> > at
>> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
>> > at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
>> > at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
>> > ... 13 more
>> > Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
>> > at
>> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
>> > at
>> sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
>> > at
>> sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
>> > at
>> sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
>> > at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
>> > at org.apache.tomcat.util.net
>> .SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
>> > at org.apache.tomcat.util.net
>> .SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
>> > at org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
>> > ... 20 more
>>
>> Can anybody explain what I did wrong? These are fully-qualified paths to
>> the certificate, chain, and key files. [REDACTED].ca.crt contains a
>> certificate chain; [REDACTED].cer contains a certificate, and
>> [REDACTED].key contains a private key, and they all work in Apache
>> httpd, on the same box.
>>
>> --
>> JHHL
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
I went to college and studied IT before finding a job. My teacher explained
to me that you should always look at the first error and ignore the rest.
First error.
08-Jan-2020 23:14:09.026 SEVERE [main]
org.apache.catalina.core.StandardService.initInternal
Failed to initialize connector [Connector[HTTP/1.1-8443]]
Once that has been addressed then either the remaining will disappear or
address the second error which will then be the first error.
On Wed, 8 Jan 2020, 23:59 James H. H. Lampert, <ja...@touchtonecorp.com>
wrote:
> I wrote:
> > 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?
>
> On 12/30/19 1:41 PM, Peter Kreuser wrote:
> > Correct!
>
> I tried an experiment this afternoon:
>
> I made a copy of the existing server.xml file, and I changed the active
> connector from this (keystore file and alias redacted for privacy,
> ciphers and compressibleMimeTypes clauses redacted because they're quite
> long, and not relevant here):
> > <Connector port="8443" proxyPort="443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> > compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> > compressableMimeType="[REDACTED]"
> > maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> > SSLEnabled="true" scheme="https" secure="true"
> > keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
> > clientAuth="false" sslProtocol="TLS" />
>
> to this:
> > <Connector port="8443" proxyPort="443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> > compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> > compressableMimeType="[REDACTED]"
> > maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> > SSLEnabled="true" scheme="https" secure="true">
> > <SSLHostConfig ciphers="[REDACTED]"
> > certificateVerification="none" sslProtocol="TLS">
> > <Certificate certificateFile="[REDACTED].cer"
> certificateKeyFile="[REDACTED].key"
> > certificateChainFile="[REDACTED].ca.crt" />
> > </SSLHostConfig>
> > </Connector>
>
> and restarted Tomcat, and it failed to open the port, producing this in
> catalina.out:
> > 08-Jan-2020 23:14:09.026 SEVERE [main]
> org.apache.catalina.core.StandardService.initInternal Failed to initialize
> connector [Connector[HTTP/1.1-8443]]
> > org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> > at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > ... 12 more
> > Caused by: java.lang.IllegalArgumentException: Cannot store
> non-PrivateKeys
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> > at org.apache.tomcat.util.net
> .NioEndpoint.bind(NioEndpoint.java:244)
> > at org.apache.tomcat.util.net
> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
> > at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> > at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> > ... 13 more
> > Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
> > at
> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
> > at
> sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
> > at
> sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
> > at
> sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
> > at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
> > at org.apache.tomcat.util.net
> .SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
> > at org.apache.tomcat.util.net
> .SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
> > ... 20 more
>
> Can anybody explain what I did wrong? These are fully-qualified paths to
> the certificate, chain, and key files. [REDACTED].ca.crt contains a
> certificate chain; [REDACTED].cer contains a certificate, and
> [REDACTED].key contains a private key, and they all work in Apache
> httpd, on the same box.
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by logo <lo...@kreuser.name>.
James,
Am 2020-01-09 00:58, schrieb James H. H. Lampert:
> I wrote:
>> 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?
>
> On 12/30/19 1:41 PM, Peter Kreuser wrote:
>> Correct!
>
> I tried an experiment this afternoon:
>
> I made a copy of the existing server.xml file, and I changed the active
> connector from this (keystore file and alias redacted for privacy,
> ciphers and compressibleMimeTypes clauses redacted because they're
> quite long, and not relevant here):
>> <Connector port="8443" proxyPort="443"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> compression="on" compressionMinSize="2048"
>> noCompressionUserAgents="gozilla, traviata"
>> compressableMimeType="[REDACTED]"
>> maxThreads="1000" socket.appReadBufSize="1024"
>> socket.appWriteBufSize="1024" bufferSize="1024"
>> SSLEnabled="true" scheme="https" secure="true"
>> keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
>> clientAuth="false" sslProtocol="TLS" />
>
> to this:
>> <Connector port="8443" proxyPort="443"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> compression="on" compressionMinSize="2048"
>> noCompressionUserAgents="gozilla, traviata"
>> compressableMimeType="[REDACTED]"
>> maxThreads="1000" socket.appReadBufSize="1024"
>> socket.appWriteBufSize="1024" bufferSize="1024"
>> SSLEnabled="true" scheme="https" secure="true">
>> <SSLHostConfig ciphers="[REDACTED]"
>> certificateVerification="none" sslProtocol="TLS">
>> <Certificate certificateFile="[REDACTED].cer"
>> certificateKeyFile="[REDACTED].key"
>> certificateChainFile="[REDACTED].ca.crt" />
>> </SSLHostConfig>
>> </Connector>
>
> and restarted Tomcat, and it failed to open the port, producing this
> in catalina.out:
>> 08-Jan-2020 23:14:09.026 SEVERE [main]
>> org.apache.catalina.core.StandardService.initInternal Failed to
>> initialize connector [Connector[HTTP/1.1-8443]]
>> org.apache.catalina.LifecycleException: Failed to initialize
>> component [Connector[HTTP/1.1-8443]]
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>> at
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at
>> org.apache.catalina.startup.Catalina.load(Catalina.java:639)
>> at
>> org.apache.catalina.startup.Catalina.load(Catalina.java:662)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at
>> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
>> at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
>> Caused by: org.apache.catalina.LifecycleException: Protocol handler
>> initialization failed
>> at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> ... 12 more
>> Caused by: java.lang.IllegalArgumentException: Cannot store
>> non-PrivateKeys
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
>> at
>> org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
>> at
>> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1105)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
>> at
>> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
>> at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
>> ... 13 more
>> Caused by: java.security.KeyStoreException: Cannot store
>> non-PrivateKeys
>> at
>> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
>> at
>> sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
>> at
>> sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
>> at
>> sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
>> at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
>> at
>> org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
>> at
>> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
>> ... 20 more
>
I recently came across a similar problem (at least the same error
message), where the key was in an unsupported format (first line of the
file: "BEGIN EC PRIVATE KEY"; Mark is working on a solution for this).
What type of private key are you using? all files PEM encoded?
Besides this your config seems to be OK.
Maybe you want to add
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
to the connector - just to be sure of the implementation.
Peter
> Can anybody explain what I did wrong? These are fully-qualified paths
> to the certificate, chain, and key files. [REDACTED].ca.crt contains a
> certificate chain; [REDACTED].cer contains a certificate, and
> [REDACTED].key contains a private key, and they all work in Apache
> httpd, on the same box.
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
The second technique is to use the *.nix command.
The result is as below
diff a.out b.out I draw your attention to third line in FILE b.out
5,7c5,7
< SSLEnabled="true" scheme="https" secure="true"
< keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
< clientAuth="false" sslProtocol="TLS" />
---
> SSLEnabled="true" scheme="https" secure="true">
> <SSLHostConfig ciphers="[REDACTED]"
> certificateVerification="none" sslProtocol="TLS">
*cat a.out*
<Connector port="8443" proxyPort="443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
compression="on" compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="[REDACTED]"
maxThreads="1000" socket.appReadBufSize="1024"
socket.appWriteBufSize="1024" bufferSize="1024"
SSLEnabled="true" scheme="https" secure="true"
keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
clientAuth="false" sslProtocol="TLS" />
*cat b.out*
<Connector port="8443" proxyPort="443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
compression="on" compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="[REDACTED]"
maxThreads="1000" socket.appReadBufSize="1024"
socket.appWriteBufSize="1024" bufferSize="1024"
SSLEnabled="true" scheme="https" secure="true">
<SSLHostConfig ciphers="[REDACTED]"
certificateVerification="none" sslProtocol="TLS">
www.backbutton.co.uk
♡۶¯\_(ツ)_/¯ ♡۶
Marriage of loose and tight coupling
-> healthy applications
♡۶
java -cp classpath class-path
On Wed, 8 Jan 2020 at 23:59, James H. H. Lampert <ja...@touchtonecorp.com>
wrote:
> I wrote:
> > 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?
>
> On 12/30/19 1:41 PM, Peter Kreuser wrote:
> > Correct!
>
> I tried an experiment this afternoon:
>
> I made a copy of the existing server.xml file, and I changed the active
> connector from this (keystore file and alias redacted for privacy,
> ciphers and compressibleMimeTypes clauses redacted because they're quite
> long, and not relevant here):
> > <Connector port="8443" proxyPort="443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> > compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> > compressableMimeType="[REDACTED]"
> > maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> > SSLEnabled="true" scheme="https" secure="true"
> > keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
> > clientAuth="false" sslProtocol="TLS" />
>
> to this:
> > <Connector port="8443" proxyPort="443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> > compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> > compressableMimeType="[REDACTED]"
> > maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> > SSLEnabled="true" scheme="https" secure="true">
> > <SSLHostConfig ciphers="[REDACTED]"
> > certificateVerification="none" sslProtocol="TLS">
> > <Certificate certificateFile="[REDACTED].cer"
> certificateKeyFile="[REDACTED].key"
> > certificateChainFile="[REDACTED].ca.crt" />
> > </SSLHostConfig>
> > </Connector>
>
> and restarted Tomcat, and it failed to open the port, producing this in
> catalina.out:
> > 08-Jan-2020 23:14:09.026 SEVERE [main]
> org.apache.catalina.core.StandardService.initInternal Failed to initialize
> connector [Connector[HTTP/1.1-8443]]
> > org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> > at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > ... 12 more
> > Caused by: java.lang.IllegalArgumentException: Cannot store
> non-PrivateKeys
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> > at org.apache.tomcat.util.net
> .NioEndpoint.bind(NioEndpoint.java:244)
> > at org.apache.tomcat.util.net
> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
> > at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> > at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> > ... 13 more
> > Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
> > at
> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
> > at
> sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
> > at
> sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
> > at
> sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
> > at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
> > at org.apache.tomcat.util.net
> .SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
> > at org.apache.tomcat.util.net
> .SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
> > ... 20 more
>
> Can anybody explain what I did wrong? These are fully-qualified paths to
> the certificate, chain, and key files. [REDACTED].ca.crt contains a
> certificate chain; [REDACTED].cer contains a certificate, and
> [REDACTED].key contains a private key, and they all work in Apache
> httpd, on the same box.
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Using the certificate files instead of a Java Keystore file, Re:
Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
I wrote:
> 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?
On 12/30/19 1:41 PM, Peter Kreuser wrote:
> Correct!
I tried an experiment this afternoon:
I made a copy of the existing server.xml file, and I changed the active
connector from this (keystore file and alias redacted for privacy,
ciphers and compressibleMimeTypes clauses redacted because they're quite
long, and not relevant here):
> <Connector port="8443" proxyPort="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
> compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata"
> compressableMimeType="[REDACTED]"
> maxThreads="1000" socket.appReadBufSize="1024" socket.appWriteBufSize="1024" bufferSize="1024"
> SSLEnabled="true" scheme="https" secure="true"
> keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
> clientAuth="false" sslProtocol="TLS" />
to this:
> <Connector port="8443" proxyPort="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
> compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata"
> compressableMimeType="[REDACTED]"
> maxThreads="1000" socket.appReadBufSize="1024" socket.appWriteBufSize="1024" bufferSize="1024"
> SSLEnabled="true" scheme="https" secure="true">
> <SSLHostConfig ciphers="[REDACTED]"
> certificateVerification="none" sslProtocol="TLS">
> <Certificate certificateFile="[REDACTED].cer" certificateKeyFile="[REDACTED].key"
> certificateChainFile="[REDACTED].ca.crt" />
> </SSLHostConfig>
> </Connector>
and restarted Tomcat, and it failed to open the port, producing this in
catalina.out:
> 08-Jan-2020 23:14:09.026 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-8443]]
> org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-8443]]
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> at org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> Caused by: org.apache.catalina.LifecycleException: Protocol handler initialization failed
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException: Cannot store non-PrivateKeys
> at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
> at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1105)
> at org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> ... 13 more
> Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
> at sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
> at sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
> at sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
> at sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
> at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
> at org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
> at org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
> at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
> ... 20 more
Can anybody explain what I did wrong? These are fully-qualified paths to
the certificate, chain, and key files. [REDACTED].ca.crt contains a
certificate chain; [REDACTED].cer contains a certificate, and
[REDACTED].key contains a private key, and they all work in Apache
httpd, on the same box.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Peter Kreuser <lo...@kreuser.name>.
James,
> Am 28.12.2019 um 00:33 schrieb James H. H. Lampert <ja...@touchtonecorp.com>:
>
>
<snip>
>>>
>>> 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?
Correct!
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 12/27/19 17:07, James H. H. Lampert 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:
>
> <Connector port="8443" proxyPort="443"
> 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).
This means that you are listening on port 443, but when Tomcat builds
URLs for redirection, etc. the port 443 will be used (and, actually,
as likely secure="true", then the port will be omitted because the
default port for https is 443 of course).
There is no proxying going on in Tomcat; this configuration is named
for the use-case: you must have a reverse-proxy somewhere which is
terminating TLS (and likely re-establishing a separate secure link
with Tomcat, since sslProtocol="TLS" in your config). It's probably a
load-balancer which is essentially synonymous with a reverse-proxy in
this context. It's possible to have one without the other, but they
are often performing both functions.
netstat on *NIX should give you the IP(s) of the clients, so you can
probably pretty easily see the IP address of the reverse proxy.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4KSWsACgkQHPApP6U8
pFhgpA/+PVIwacQPcjbaHMPwEz+JfVMzZubjzQDxM6u0gSRTpH3z8PRHPvm/DPZN
FJhNHEZhpbdXVA5ypsg5LIHShqIOh716Rp/mIObIWn2Z+NK2x5uLytBhIOt6w1fZ
Qsqy4f+jFUesRp3Y5/wWu6plIvB5y3c+RzGVt7Q4fX5XKTMKuP5DueHC57qaY6LL
V28qwyRQCBPMJV89pb3rKICzQEf8uSCVFjV/xKU7/0IamHKh3MfVXrUikFJB8/ex
CiHLsmc2FGSxERHvHOPxnKaGA/EFa3Lu3p0VrdSbczsmtS/cCmlrBUz0pmcqQLQ/
wm0OOfQ2aTvU42E0E3bgc014dOsrC2zugrjGNrZTQqyCXbBN065iZoi9RT3Hl8vN
lAfS83rF0E4eTNlB2E3qRZTFVGPSaNS5MPnl4RXC8F9c2/vukIY0Xb9DWi4Hf6f+
8tSZHer24uD8nR928p78mbiqoI1NMZaM9CwIN0XhJzjb2XzhZF9pgfmjAvbdV8vo
AtWauUHw1BictxXdVtmZ2xY3dYsK0RDPqX/K9u053rPOfweYTCCVn5lcRUzhITmr
sf8pP/8vRiXQAIyH0JjvCXJIUIIJGo7xofJQcs2RPA8qt+aukQC3OpB7UdpKOHv0
P/7zx+mWDyCH5A9fIfT16H6kgRfxoyUi19X6pFMPuzXNpiZP2zU=
=9vaq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Andrew,
On 12/27/19 17:23, Andrew Stanton wrote:
> 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.
There isn't any such thing as a secure network. IMHO, all network
connections should be encrypted. TLS just isn't that tricky and,
honestly, the more you do it the better you'll get at doing it.
- -chris
> On Fri, Dec 27, 2019 at 2:08 PM James H. H. Lampert <
> jamesl@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:
>>
>> <Connector port="8443" proxyPort="443"
>> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4KSaUACgkQHPApP6U8
pFjZew/9FWTFhMx3Zx8aVdxgxMJytTDdiffxCrpv2vqUpbIS3qlxjJl8B6D8DEYW
uie+KUyFrHu/DQrRYIRK+VUYUj8RJalDRAtPAkWryD4tq6Qneqfph7TGRlpJtbAI
efPg3HFMDczTqeOPf93gzvx3NjSGlql+f6iCtNB8ttIlnFaS2DLWWIsYvU7Skryy
k8UMycWFIh0zIex6tpwYLmTs6OsueJqMqFkuKxIRSyGiRRvsDVU1Qs8/SbKoTdA8
c30roHB0Z5jwWkfb2jDbRPYKOzTnrnCFUF7INO94/px96vrtnfNwB8aWkcM903WP
KSvU4WRb9S8dDMXRXcVYIl4LvyKwMwEAlhSuNRCAXcGKsCKwoVufy63ND1v0cQKa
Tc+Va5oxDBvFGVN0zWyyGi/hVlDp2ezRhdczDM/IlpKvo5v23W5sw1m0jccHCKmb
IS3o9s+hhqrdzIoEVqViSK3QntEeCCm7dksjCD4JRyCtUDY7b+Qqi9cbQxg6C/PK
V93BhswbLUzgfHkLvFhdDAoMJtv4rXf6woPlGV53zEwJW6YRYQu0xbBLRl1RdFYG
KSalgVc6YWBfsPy7ulYdhsL66AEyGGOLjNNIrPvb+/Pkoh3eiQZj4HQb+MHxkJn2
dL9cpUQsl2clultPWj4U9c5bCGAZzWTG+Z1ZLEB2aKkGJBC4lg8=
=4wzn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Andrew Stanton <an...@gmail.com>.
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 <
jamesl@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:
>
> <Connector port="8443" proxyPort="443"
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Andrew G. Stanton
CEO/Founder/Principal Engineer, Stanton Web Applications, Inc.
Founder, GetMorty.io and UniversalWallet.io
email: andrewgstanton@gmail.com
also: andy@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?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
>> 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:
<Connector port="8443" proxyPort="443"
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Igal Sapir <ig...@lucee.org>.
James,
On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jamesl@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%202018/Let's%20Encrypt%20Apache%20Tomcat.pdf>
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
>
> James H. H. Lampert
> Touchtone Corporation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Let's Encrypt with Tomcat?
Posted by Andrew Stanton <an...@gmail.com>.
You could use their public certificate with their lb and redirect 443 to
port 80 in the lb I was using jboss server running on port 80 in the ec2
instances that were running behind the lb. when I did that all requests
hitting the lb were secured. Jboss is another container like tomcat.
Hope that helps
On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jamesl@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> --
Andrew G. Stanton
CEO/Founder/Principal Engineer, Stanton Web Applications, Inc.
Founder, GetMorty.io and UniversalWallet.io
email: andrewgstanton@gmail.com
also: andy@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.