Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
James, On 11/5/20 12:07, James H. H. Lampert wrote: I'm intrigued by Mr. Schultz's suggestion of Maybe you just want RedirectPermanent instead of Rewrite(Cond|Rule)? Would that make a difference? Or is it just a matter of altering the RewriteCond clause to specifically ignore anything that looks like a Let's Encrypt challenge? Or is there something I can put on the default landing page for the subdomain, rather than in the VirtualHost, to cause the redirection? I'm just thinking that Redirect[*] is a simpler configuration than Rewrite(Cond|Rule). As I recall (unless there's a way to force-expire the cached challenge result on a certbot call), I have to wait until December to run another test. You can delete all your stuff, but LE will get upset if you make requests too frequently. There is a way to ask LE to let you "test" stuff and they will lower the frequency limits. I have forgotten how to do that, but it might be a good idea to look into it since you really are testing things at this point. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't qutite understand, Re: Let's Encrypt with Tomcat behind httpd
Dr it really does not work On Thu, Nov 5, 2020, 12:07 PM James H. H. Lampert wrote: > On 8/24/20 9:57 AM, Christopher Schultz wrote: > > > So your RewriteCond[ition] is expected to always be true? Okay. Maybe > > remove it, then? BTW I think your rewrite will strip query strings and > > stuff like that. Maybe you just want RedirectPermanent instead of > > Rewrite(Cond|Rule)? > > Ladies and Gentlemen: > > This past Friday, the cached challenge result expired, and so this past > Monday, I ran another certbot test. > > With the rewrite in place for our "subdomain of interest," the cert > covering everything else served by the httpd server renewed without > incident, but the separate cert covering this subdomain failed completely. > > I commented out the rewrite, and ran the test again, and both renewed > without incident. > > I posted a redacted version of the complete VirtualHost blocks back on > August 24th. And after I'd run my tests this week, I've also posted it > to ServerFault, at > https://serverfault.com/q/1041047/498231 > > I'm intrigued by Mr. Schultz's suggestion of > > > Maybe you just want RedirectPermanent instead of > > Rewrite(Cond|Rule)? > > Would that make a difference? Or is it just a matter of altering the > RewriteCond clause to specifically ignore anything that looks like a > Let's Encrypt challenge? Or is there something I can put on the default > landing page for the subdomain, rather than in the VirtualHost, to cause > the redirection? > > As I recall (unless there's a way to force-expire the cached challenge > result on a certbot call), I have to wait until December to run another > test. > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
On 8/21/20 1:02 PM, logo wrote:
From my experience I have excluded .well-known from the redirect.
That appears to be the correct answer. I probably didn't see that line
back in August, or I probably would have replied by asking something
like, "Ok, and how do I do that?"
Be that as it may, Andrew Schulman came up with an answer on my
ServerFault thread (https://serverfault.com/a/1041882/498231) to the
effect of changing the rewrite block from:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
to:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]
While I'm not going to be certain until December, when the cached
challenge expires, it certainly seems to work: if I go to
http://sub.domain.com, it immediately redirects me to
https://sub.domain.com, and I get the Tomcat server, whereas if I try to
go to http://sub.domain.com/.well-known/acme-challenge/foo, it remains
http, and gives me the expected "Not Found" error.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
On 8/24/20 9:57 AM, Christopher Schultz wrote: So your RewriteCond[ition] is expected to always be true? Okay. Maybe remove it, then? BTW I think your rewrite will strip query strings and stuff like that. Maybe you just want RedirectPermanent instead of Rewrite(Cond|Rule)? Ladies and Gentlemen: This past Friday, the cached challenge result expired, and so this past Monday, I ran another certbot test. With the rewrite in place for our "subdomain of interest," the cert covering everything else served by the httpd server renewed without incident, but the separate cert covering this subdomain failed completely. I commented out the rewrite, and ran the test again, and both renewed without incident. I posted a redacted version of the complete VirtualHost blocks back on August 24th. And after I'd run my tests this week, I've also posted it to ServerFault, at https://serverfault.com/q/1041047/498231 I'm intrigued by Mr. Schultz's suggestion of Maybe you just want RedirectPermanent instead of Rewrite(Cond|Rule)? Would that make a difference? Or is it just a matter of altering the RewriteCond clause to specifically ignore anything that looks like a Let's Encrypt challenge? Or is there something I can put on the default landing page for the subdomain, rather than in the VirtualHost, to cause the redirection? As I recall (unless there's a way to force-expire the cached challenge result on a certbot call), I have to wait until December to run another test. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
I think I found something. At the very bottom of LE's FAQ page, https://letsencrypt.org/docs/faq (under "I successfully renewed a certificate but validation . . ."), I found: Once you successfully complete the challenges for a domain, the resulting authorization is cached for your account to use again later. Cached authorizations last for 30 days from the time of validation. If the certificate you requested has all of the necessary authorizations cached then validation will not happen again until the relevant cached authorizations expire. In other words, the authorization cache is likely invalidating the tests I ran with the rewrite in place! The more you overthink the plumbing, the easier it is to stop up the drain! Last night, after I discovered this, I set an alarm for myself (using a 1970s-vintage Los Angeles County Fire Station alarm*, because it's impossible to ignore), to try another forced renewal next month, one month after the original certificate issuance, and see what happens. If the renewal fails, it will give me two months to solve the problem. __ * FWIW, one of many online copies of the Station 51 alarm (from "Emergency!") can be found at https://tvshrine.com/Emergency/ebuzzer.wav JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
I had to write some custom code to look for the lets encrypt headers
then respond appropriately for verification. It wasn't too bad,
although I don't like having that entity-specific code in there so
I've isolated and commented it.
On 8/25/20, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> James,
>
> On 8/24/20 13:24, James H. H. Lampert wrote:
>> On 8/24/20 9:57 AM, Christopher Schultz wrote:
>>> So your RewriteCond[ition] is expected to always be true? Okay.
>>> Maybe remove it, then? BTW I think your rewrite will strip query
>>> strings and stuff like that. Maybe you just want
>>> RedirectPermanent instead of Rewrite(Cond|Rule)?
>>>
>>> Okay, so everyone gets redirected from http://exmaple.com/ to
>>> https://example.com/. If LE requests
>>> http://example.com/.well-known/uherfhuerhfiu then it will be
>>> redirected to https://example.com/.well-known/uherfhuerhfiu,
>>> presumably locate the correct file and authorize the certificate
>>> request, right?
>>>
>>> But you have said that "everything is unconditionally passed to
>>> Tomcat". You posted some config that definitely passes some
>>> things to Tomcat, but without seeing the rest of the
>>> configuration it's not possible to know for sure
>>> nothing else is going on.
>>
>> Ok. In the original post, I posted the virtual host configuration
>> as it was at the time, with meaningful domain names and IP
>> addresses redacted, and some commented-out, abandoned-in-place
>> lines removed.
>>
>> Here is what I currently have in place, albeit with names and IP
>> addresses "changed to protect the innocent." I'm sending you the
>> uncensored version off-List.
>>
>> ServerName foo.frobozz.com # ServerAlias
>> bar.frobozz.com DocumentRoot /var/www/html/test ServerAdmin
>> i...@frobozz.com AllowOverride All
>> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\.
>> [NC] RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
>> [R=301,L]
>>
>> ServerName
>> foo.frobozz.com # ServerAlias bar.frobozz.com DocumentRoot
>> /var/www/html/test ServerAdmin i...@frobozz.com # > /var/www/html/test> # AllowOverride All # # > "https://foo.frobozz.com/manager/html/*;> # Require ip
>> aa.bb.cc.dd # # > "https://bar.frobozz.com/manager/html/*;> # Require ip
>> aa.bb.cc.dd #Require ip aa.bb.cc.dd
>> ww.xx.yy zz pp.dd.qq.xx
>> Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
>> ProxyPass "/" "http://127.0.0.1:8080/; ProxyPassReverse "/"
>> "http://127.0.0.1:8080/; ProxyRequests Off Include
>> /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile
>> /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
>> SSLCertificateKeyFile
>> /etc/letsencrypt/live/foo.frobozz.com/privkey.pem
>>
>
> Yeah... that''s pretty straightforward. Hmm.
>
> No other VirtualHosts? Non other web servers in the mix (e.g.
> load-balancer which alreaddy redirects to HTTPS), etc.?
>
> That seems pretty mysterious to me, too.
>
> Are you using VH-based authentication with LE? Meaning, you aren't
> using DNS authentication or anything like that?
>
> I think once you have configured the server once with an LE
> certificate, renewals can use the existing certificate as
> proof-of-ownership without having to put the file into /.well-known.
> Or something. I have forgotten the details.
>
> So maybe that's it: you've already bootstrapped the process and so
> it's smoother, now. Maybe?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9FHD0ACgkQHPApP6U8
> pFi58xAAvux94C7QCOUkLj8MLGiQV57/ImcTa85nMme2H2ywpZ7JQozlssU6CSpH
> FAYFCOP3U3EH6A9AzFeSZhW+sKMeBt6uF3QR/2QF3vGmg5/KcB0srcdBcn6eejVc
> KrUnVKx5lcK+hmyXPlIVdGb+koiDl1D1omkeOxdQOaniNfGvW1LgUxouRXpUBTfJ
> JK5oe7yV5U8Ge5Wm+pOIrpf/4Y0JqluNJplQIEVWv3x7EsJtSKVKIoCXfPyGf36g
> aGmFRsh6XvndllaV/FBxx/K9zh5TG1GijkfO+vsl4l3ZXnljJm1h4Vx/1Y6KEUbM
> x9Zv8QgNpXsmZ+ylfi3hK0l9V7rkUB6ZX5mYJa9ABPXYtkE/rvCpG6RijVgY9WA4
> 4LXKW74+QR9R352OLBCgvE2gjRgVTX/KmoGasBrB3mDYd+vELkBCcXlHAQkYBVqw
> KL4UIL3SUEnV4jDfrJ/g2ujyPKd9+ED7EECM91lWg6Lcunc5865qJfPvykIDaBnZ
> kASElxqRGqmTUEi57z+BKJNRBs+ME9f7JOlT8iaoB2wKJC8CrUnGNtrFpvBxhehb
> GY4uPrUZro7NjuJ/jALnb1CeedeL9+OohxqbTYECaoeS4Op8vNNU6/FtUH9BTjWD
> mlaXkhrGr7puf4AjPg9geE/0h5Bg+ltTh8yrK1o+4jrct34S438=
> =6dbK
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 8/24/20 13:24, James H. H. Lampert wrote:
> On 8/24/20 9:57 AM, Christopher Schultz wrote:
>> So your RewriteCond[ition] is expected to always be true? Okay.
>> Maybe remove it, then? BTW I think your rewrite will strip query
>> strings and stuff like that. Maybe you just want
>> RedirectPermanent instead of Rewrite(Cond|Rule)?
>>
>> Okay, so everyone gets redirected from http://exmaple.com/ to
>> https://example.com/. If LE requests
>> http://example.com/.well-known/uherfhuerhfiu then it will be
>> redirected to https://example.com/.well-known/uherfhuerhfiu,
>> presumably locate the correct file and authorize the certificate
>> request, right?
>>
>> But you have said that "everything is unconditionally passed to
>> Tomcat". You posted some config that definitely passes some
>> things to Tomcat, but without seeing the rest of the
>> configuration it's not possible to know for sure
>> nothing else is going on.
>
> Ok. In the original post, I posted the virtual host configuration
> as it was at the time, with meaningful domain names and IP
> addresses redacted, and some commented-out, abandoned-in-place
> lines removed.
>
> Here is what I currently have in place, albeit with names and IP
> addresses "changed to protect the innocent." I'm sending you the
> uncensored version off-List.
>
> ServerName foo.frobozz.com # ServerAlias
> bar.frobozz.com DocumentRoot /var/www/html/test ServerAdmin
> i...@frobozz.com AllowOverride All
> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\.
> [NC] RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
> [R=301,L]
>
> ServerName
> foo.frobozz.com # ServerAlias bar.frobozz.com DocumentRoot
> /var/www/html/test ServerAdmin i...@frobozz.com # /var/www/html/test> # AllowOverride All # # "https://foo.frobozz.com/manager/html/*;> # Require ip
> aa.bb.cc.dd # # "https://bar.frobozz.com/manager/html/*;> # Require ip
> aa.bb.cc.dd #Require ip aa.bb.cc.dd
> ww.xx.yy zz pp.dd.qq.xx
> Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
> ProxyPass "/" "http://127.0.0.1:8080/; ProxyPassReverse "/"
> "http://127.0.0.1:8080/; ProxyRequests Off Include
> /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile
> /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
> SSLCertificateKeyFile
> /etc/letsencrypt/live/foo.frobozz.com/privkey.pem
>
Yeah... that''s pretty straightforward. Hmm.
No other VirtualHosts? Non other web servers in the mix (e.g.
load-balancer which alreaddy redirects to HTTPS), etc.?
That seems pretty mysterious to me, too.
Are you using VH-based authentication with LE? Meaning, you aren't
using DNS authentication or anything like that?
I think once you have configured the server once with an LE
certificate, renewals can use the existing certificate as
proof-of-ownership without having to put the file into /.well-known.
Or something. I have forgotten the details.
So maybe that's it: you've already bootstrapped the process and so
it's smoother, now. Maybe?
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9FHD0ACgkQHPApP6U8
pFi58xAAvux94C7QCOUkLj8MLGiQV57/ImcTa85nMme2H2ywpZ7JQozlssU6CSpH
FAYFCOP3U3EH6A9AzFeSZhW+sKMeBt6uF3QR/2QF3vGmg5/KcB0srcdBcn6eejVc
KrUnVKx5lcK+hmyXPlIVdGb+koiDl1D1omkeOxdQOaniNfGvW1LgUxouRXpUBTfJ
JK5oe7yV5U8Ge5Wm+pOIrpf/4Y0JqluNJplQIEVWv3x7EsJtSKVKIoCXfPyGf36g
aGmFRsh6XvndllaV/FBxx/K9zh5TG1GijkfO+vsl4l3ZXnljJm1h4Vx/1Y6KEUbM
x9Zv8QgNpXsmZ+ylfi3hK0l9V7rkUB6ZX5mYJa9ABPXYtkE/rvCpG6RijVgY9WA4
4LXKW74+QR9R352OLBCgvE2gjRgVTX/KmoGasBrB3mDYd+vELkBCcXlHAQkYBVqw
KL4UIL3SUEnV4jDfrJ/g2ujyPKd9+ED7EECM91lWg6Lcunc5865qJfPvykIDaBnZ
kASElxqRGqmTUEi57z+BKJNRBs+ME9f7JOlT8iaoB2wKJC8CrUnGNtrFpvBxhehb
GY4uPrUZro7NjuJ/jALnb1CeedeL9+OohxqbTYECaoeS4Op8vNNU6/FtUH9BTjWD
mlaXkhrGr7puf4AjPg9geE/0h5Bg+ltTh8yrK1o+4jrct34S438=
=6dbK
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
On 8/24/20 9:57 AM, Christopher Schultz wrote:
So your RewriteCond[ition] is expected to always be true? Okay. Maybe
remove it, then? BTW I think your rewrite will strip query strings and
stuff like that. Maybe you just want RedirectPermanent instead of
Rewrite(Cond|Rule)?
Okay, so everyone gets redirected from http://exmaple.com/ to
https://example.com/. If LE requests
http://example.com/.well-known/uherfhuerhfiu then it will be
redirected to https://example.com/.well-known/uherfhuerhfiu,
presumably locate the correct file and authorize the certificate
request, right?
But you have said that "everything is unconditionally passed to
Tomcat". You posted some config that definitely passes some things to
Tomcat, but without seeing the rest of the configuration
it's not possible to know for sure nothing else is going on.
Ok. In the original post, I posted the virtual host configuration as it
was at the time, with meaningful domain names and IP addresses redacted,
and some commented-out, abandoned-in-place lines removed.
Here is what I currently have in place, albeit with names and IP
addresses "changed to protect the innocent." I'm sending you the
uncensored version off-List.
ServerName foo.frobozz.com
# ServerAlias bar.frobozz.com
DocumentRoot /var/www/html/test
ServerAdmin i...@frobozz.com
AllowOverride All
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
ServerName foo.frobozz.com
# ServerAlias bar.frobozz.com
DocumentRoot /var/www/html/test
ServerAdmin i...@frobozz.com
#
# AllowOverride All
#
# https://foo.frobozz.com/manager/html/*;>
# Require ip aa.bb.cc.dd
#
# https://bar.frobozz.com/manager/html/*;>
# Require ip aa.bb.cc.dd
#
Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
ProxyPass "/" "http://127.0.0.1:8080/;
ProxyPassReverse "/" "http://127.0.0.1:8080/;
ProxyRequests Off
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/foo.frobozz.com/privkey.pem
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 8/24/20 11:45, James H. H. Lampert wrote:
> On 8/22/20 7:35 AM, Christopher Schultz wrote:
>
>>> (1) every http request is unconditionally redirected to https:
>>>
>>> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
>>> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
>>> [R=301,L]
>>
>> This is not unconditional. That's what "RewriteCond" does: it
>> sets up a condition :)
>>
>> If Let's Encrypt requests http://www.yoursite.com/ then it won't
>> be redirected.
> . . .
>> What domains are you asking LE to certify?
>
> Except that the "www." prefix subdomain is undefined. There's no
> entry for it in Amazon Route 53; it was deliberately *not* given in
> the initial provisioning of the cert from LE, and it's *not* in the
> certbot configuration file for the subdomain.
So your RewriteCond[ition] is expected to always be true? Okay. Maybe
remove it, then? BTW I think your rewrite will strip query strings and
stuff like that. Maybe you just want RedirectPermanent instead of
Rewrite(Cond|Rule)?
Okay, so everyone gets redirected from http://exmaple.com/ to
https://example.com/. If LE requests
http://example.com/.well-known/uherfhuerhfiu then it will be
redirected to https://example.com/.well-known/uherfhuerhfiu,
presumably locate the correct file and authorize the certificate
request, right?
But you have said that "everything is unconditionally passed to
Tomcat". You posted some config that definitely passes some things to
Tomcat, but without seeing the rest of the configuration
it's not possible to know for sure nothing else is going on.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9D8WcACgkQHPApP6U8
pFiyMRAAyS+lAy91W8/6aB2I1NnbxbmX1EB1pACnr7MzT35Z6LPttNXNRPNXufN0
hxJfoeep/4HBjd3m7v3n/NZAYle2/qfzhEb4LGvkVDwlznXeOYKUr4OV16NkhYvO
G6mtLi+dIe23LCh8hsIeabcT+Ggds59cLyScsV5g9ID+DcAUyDN6XOnZRGjqlGRo
jabdf1Ae+tjaWOSSQ1gseeK5s9ZliFvALh8qNSQMTj4txa5UJ9sUJbBbKm3NtQQT
fFHFw7qeMfP1ROAW49FE8QqHKaVScG1g4xsGbtkgahqiDyS8EF0FTgResxJiVLYy
FM0NZH8q8RAQEyeZUr9Vyq8YsRSII/4NTaeH29oiE8k33ipV8SzC18e58a1Lo1e8
kQj9F8c6cQkZiLDmte0TfeKem+bSv2aUtt6XhVNRBKv28Tvb8Vml+cMiuoMQktyg
8C8tn9ZxRQlsNF1YbpSTRf4xGHEiSg23u5zPWohCMi8nOwom3gf1UexEMIb9hvbj
qn3Or2P7l6nn8Ij3bTYejoIFDo647t1cRmgnb9C4nxXgGFR2kNVLVKZVehnWUYxQ
2A7No7CeLfJSEui3NowKy/WLwUkR+dX65hSaC3qZFpNpg6TzixqqGHOaGLLkCfoZ
jxnfhhs3Zk3j3Ipz2rZsUdT2Mwaytw750UNfZbuSWF9/F0C8f+0=
=50tL
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
On 8/22/20 7:35 AM, Christopher Schultz wrote:
(1) every http request is unconditionally redirected to https:
RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule
^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
This is not unconditional. That's what "RewriteCond" does: it sets up
a condition :)
If Let's Encrypt requests http://www.yoursite.com/ then it won't be
redirected.
. . .
What domains are you asking LE to certify?
Except that the "www." prefix subdomain is undefined. There's no entry
for it in Amazon Route 53; it was deliberately *not* given in the
initial provisioning of the cert from LE, and it's *not* in the certbot
configuration file for the subdomain.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 8/21/20 13:14, James H. H. Lampert wrote:
> On 8/21/20 9:30 AM, Christopher Schultz wrote:
>
>> Why would you think that redirecting from http -> https would
>> block renewal?
>
> Because, at least if I correctly understand what I set up,
>
> (1) every http request is unconditionally redirected to https:
>
> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule
> ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
This is not unconditional. That's what "RewriteCond" does: it sets up
a condition :)
If Let's Encrypt requests http://www.yoursite.com/ then it won't be
redirected.
> (2) every https request is unconditionally passed to Tomcat.
>
> ProxyPass "/" "http://127.0.0.1:8080/; ProxyPassReverse "/"
> "http://127.0.0.1:8080/; ProxyRequests Off
>
> and (3) Let's Encrypt rechecks domain control when it renews, and
> therefore Certbot needs to put something where the Let's Encrypt
> server can find it.
>
> Are any of these assumptions wrong?
What domains are you asking LE to certify?
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9BLSAACgkQHPApP6U8
pFjFIQ//cO9QGyqvHZzmWm1m28CCCZ4bjG/LpLH8QbflQHrum39wV1b5l+idWdST
QlnBV9ZWmFlHFqLw/NyHXUW6o3GHZRv0ObKJ+qVBZlSQ2dS1IZ4DQkQBuq7qq2ZK
PNg2Z8Gu9TkaGAbn7G6VqOht+AQ5BdnjSkQLKlA/9goJIx/vt7oqZusXk9eAHL06
hoKr44+LzhgdkoLI4fAFNBeHx9tSnOluovT75/cHRTMcOoyIOAOXn0sjeQTiJZw/
i/yBjp3SkSZCvmzWj0rpOfmrvb3Fe+s/yXtvNWdsWptVUuDEeFcGKq+syVPuRB0I
K37q/FFEKmeQyOsqqKdwHv0kiWOASoFRqt+Or5Rvqo22MhV2abhkJ2P2u23BkLOy
nTA6deeHZOXzSptjzVrgzAXpNO88dL0WFarMONLs/hffCIGVSRbVgzUS3vawS5z1
Ar+DM26Hna2ZB7VjjgpXMivsXAPUJWxxZhMJt0tniq6T1YHHJJdpIUh6QYsGR6Tg
Oo6aSNK7tPPDdgmCEkuqB1S3qEmhNvD4AKVlkZ/L9PVqGOUDEMNn5DRGduobNz+B
eTiYIImIovIQhRy2cRmNmgSotOlwxkJMFX+eat9eJT/0NTKG0tlwajBculzEIPH3
3CConKkHXAuzTj1KZbVMYon2fAfuN6VbOkEdl4bEWNBm2NFnfAk=
=R0qT
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
Chris
> Am 21.08.2020 um 18:30 schrieb Christopher Schultz
> :
>
> Signierter PGP-Teil
> James,
>
> On 8/18/20 19:47, James H. H. Lampert wrote:
> > Something just worked, that I wasn't expecting to work. Or rather,
> > I was expecting it to work, but kill cert renewal.
> >
> > The port 80 virtual host had
> >> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
> >> RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI}
> >> [R=301,L]
> >
> > which I commented out, because https for that virtual host is a
> > pure front-end for Tomcat, and of course, Certbot needs to stick
> > something on the server that Let's Encrypt is expecting to be able
> > to find.
> >
> > So a few minutes ago, just for test purposes, I uncommented the
> > above lines. Initially, it didn't work (it redirected the browser
> > from http://foo.bar.com to a nonexistent https://www.foo.bar.com),
> > but when I removed the "www" in the RewriteRule, changing the block
> > to
> >> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
> >> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
> >
> > it worked just fine.
> >
> > So then, I did a "certbot renew --force-renewal" (expecting it to
> > fail on the relevant cert, but in fact, it renewed just fine.
> >
> > Not to look a gift equine in the masticatory orifice, but what am
> > I missing here? What went right, when I was expecting it to go
> > wrong? Why didn't the "rewrite" lines break renewal?
>
> Why would you think that redirecting from http -> https would block
> renewal?
>
From my experience I have excluded .well-known from the redirect.
LE will request initially on port 80.
And if the cert hast expired it may be happier when renewing on port 80.
Peter
> -chris
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
Something just worked, that I wasn't expecting to work. Or rather, I was
expecting it to work, but kill cert renewal.
The port 80 virtual host had
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
which I commented out, because https for that virtual host is a pure
front-end for Tomcat, and of course, Certbot needs to stick something on
the server that Let's Encrypt is expecting to be able to find.
So a few minutes ago, just for test purposes, I uncommented the above
lines. Initially, it didn't work (it redirected the browser from
http://foo.bar.com to a nonexistent https://www.foo.bar.com), but when I
removed the "www" in the RewriteRule, changing the block to
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
it worked just fine.
So then, I did a "certbot renew --force-renewal" (expecting it to fail
on the relevant cert, but in fact, it renewed just fine.
Not to look a gift equine in the masticatory orifice, but what am I
missing here? What went right, when I was expecting it to go wrong? Why
didn't the "rewrite" lines break renewal?
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
-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-ow...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
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): 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: 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"> certificateKeyFile="[REDACTED].key" certificateChainFile="[REDACTED].ca.crt" /> 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
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
On 09/01/2020 08:27, calder wrote: > Moderators ? The moderators can be contacted via users-ow...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
Moderators ? On Wed, Jan 8, 2020, 20:44 Zahid Rahman 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, > 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): > > > > 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: > > > > 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"> > > >> >certificateVerification="none" sslProtocol="TLS"> > > > > certificateKeyFile="[REDACTED].key" > > > certificateChainFile="[REDACTED].ca.crt" /> > > > > > > > > > > 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) > > >
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
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"> > certificateVerification="none" sslProtocol="TLS"> *cat a.out* *cat b.out* 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 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): > > 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: > > 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"> > >>certificateVerification="none" sslProtocol="TLS"> > > certificateKeyFile="[REDACTED].key" > > certificateChainFile="[REDACTED].ca.crt" /> > > > > > > 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 >
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
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, 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, 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, >> 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): >>> > >> 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: >>> > >> 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"> >>> > >> >certificateVerification="none" sslProtocol="TLS"> >>> > >> certificateKeyFile="[REDACTED].key" >>> > certificateChainFile="[REDACTED].ca.crt" /> >>> > >>> > >>> >>> 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 >>>
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
https://confluence.atlassian.com/confkb/ssl-connector-fails-to-initialize-during-tomcat-startup-646251490.html On Thu, 9 Jan 2020, 02:44 Zahid Rahman, 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, > 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): >> > > 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: >> > > 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"> >> > > >certificateVerification="none" sslProtocol="TLS"> >> > > certificateKeyFile="[REDACTED].key" >> > certificateChainFile="[REDACTED].ca.crt" /> >> > >> > >> >> 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 >>
Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
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, 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): > > 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: > > 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"> > >>certificateVerification="none" sslProtocol="TLS"> > > certificateKeyFile="[REDACTED].key" > > certificateChainFile="[REDACTED].ca.crt" /> > > > > > > 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 >
Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?
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): to this: 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/8/20 12:35 PM, James H. H. Lampert wrote: > On 1/8/20 5:18 AM, Christopher Schultz wrote: . . . >> Now the URL line becomes (for me, using a management port): >> >> http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtoco lHa >> >> ndler,port%3D8215=reloadSslHostConfigs > . . . >> Have you configured any elements, or are you >> using the old-style configuration like: >> >> > > I just have a connector definition in server.xml, almost exactly > the same as I've been using in Tomcat 7 installations. I don't > think prior to this discussion, I'd even *heard* of > "SSLHostConfig." > >> You may need to change your connector configuration to use >> nested elements if it's not that way already. >> >> Try invoking the "findSslHostConfigs" operation to see if it >> completes. That will at least tell you if you have your >> objectname correct. >> >> Like this: >> >> $ curl -k -u "test:test" >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto col >> >> Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs" > > This gave me a stacktrace: >> curl -k -u "test:test" >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto colHandler,port%3D8443,ad >> >> >> dress%3D127.0.0.1=findSslHostConfigs" > > But omitting the address parameter, as in your own test, gave me > this: >> curl -k -u test:test >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto colHandler,port%3D8443& >> >> >> op=findSslHostConfigs" >> OK - Operation findSslHostConfigs returned: >> org.apache.tomcat.util.net.SSLHostConfig@1a9b80c2 > >> curl -k -u test:test >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto colHandler,port%3D8443& >> >> >> op=reloadSslHostConfigs" >> OK - Operation reloadSslHostConfigs without return value > > And I just now confirmed that the latter did indeed reload the > keystore when I swapped between the regular keystore and a > self-signed one, even though I just have the old-style connector > definition. > > So apparently, it was the "address" parameter that was killing me. > Interesting. > > The idea was to put the Tomcat server on the same certificate and > private key files as the httpd server on the same EC2 box. Do I > need this newfangled "SSLHostConfig" for that? > > At any rate, I think we have another breakthrough here, but at the > same time, I think I also need to disable the "test" user, and get > back to another project I have going, at least for now. Glad you got it working. The next releases of Tomcat will give you a better error message from JMXProxyServlet in cases like these. No more NPEs. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4WXLQACgkQHPApP6U8 pFgVRw/+O3zCPWww0FgzSp46NIkqh50j6bGwu95N9mM9r43DNHZ4XOBNoZ/04khc 0otFGF0xnCvXX/3s3RPvYHeV+ZggMhtb8Sd/IZjHAWArVPC1+iXOlydIniaqXeJ5 jEvF4fu67FVLIFRz625gHVGrERwIfUM4om7qo3KYaOOA8+KQY/pCEZGPqMV90FRy Dx2n2ifLEwSFV9lq1yDaqelhW2YgvqaAaoocRoRBaEBnWtgMl+vAtTpWTCFk5bwM iH2mgdc9DIUawjLpIjuCsXb7AlAI4GrB4ATSpMIcvHNkyWSubxvm9PpdYSbwR4vQ N5QJGOdYbpNdY9kylyKi5AteS0IpCBD+iXwTn5QJIxwarIlluIj9pGhZbibumg9M JhwzLpyK90OF6lFlNNWLuc5frC8R2rJFEWCPwGPwml7V8RCzNi8YzTi13UyyaMJi 1wa6uyICKGJIWexyz5sLG/Juo9wDqZzojN4Bxl2AxMWHDpN6M/fXMeesB3B5ScKg kBoHf+1SZTjD5j61QarkyUgfskgG7oH+PaZkQNudggZ/QghuuSmSHjGcIECbRaiC oSWdlv2acRs5eExXu5PedLrQO66HoecMlOA1Sl/B5gajlZCerhTEBqLq6ebwIefF U4sQsBwmwfwo6U1wd0377nTGj/+zWV31BqXfAP3cZ/duyo9g9kA= =oXVx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
On 1/8/20 5:18 AM, Christopher Schultz wrote: . . . Now the URL line becomes (for me, using a management port): http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa ndler,port%3D8215=reloadSslHostConfigs . . . Have you configured any elements, or are you using the old-style configuration like: I just have a connector definition in server.xml, almost exactly the same as I've been using in Tomcat 7 installations. I don't think prior to this discussion, I'd even *heard* of "SSLHostConfig." You may need to change your connector configuration to use nested elements if it's not that way already. Try invoking the "findSslHostConfigs" operation to see if it completes. That will at least tell you if you have your objectname correct. Like this: $ curl -k -u "test:test" "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocol Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs" This gave me a stacktrace: curl -k -u "test:test" "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443,ad dress%3D127.0.0.1=findSslHostConfigs" But omitting the address parameter, as in your own test, gave me this: curl -k -u test:test "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443; op=findSslHostConfigs" OK - Operation findSslHostConfigs returned: org.apache.tomcat.util.net.SSLHostConfig@1a9b80c2 curl -k -u test:test "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443; op=reloadSslHostConfigs" OK - Operation reloadSslHostConfigs without return value And I just now confirmed that the latter did indeed reload the keystore when I swapped between the regular keystore and a self-signed one, even though I just have the old-style connector definition. So apparently, it was the "address" parameter that was killing me. Interesting. The idea was to put the Tomcat server on the same certificate and private key files as the httpd server on the same EC2 box. Do I need this newfangled "SSLHostConfig" for that? At any rate, I think we have another breakthrough here, but at the same time, I think I also need to disable the "test" user, and get back to another project I have going, at least for now. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/7/20 8:24 PM, James H. H. Lampert wrote: > On 1/7/20 4:19 PM, Christopher Schultz wrote: > >> You probably "spelled" something incorrectly. It might be a >> quoting/escaping issue. It might be a literal misspelling/typo. >> >> The JMXProxyServlet shouldn't NPE like that, though. >> >> I'll take a look and see if we can give you a better error >> message than that when it happens. > > Well given that (1) there's no production data at stake, (2) you > don't know where this server is, (3) the test user will be removed > permanently and replaced with something else once this problem is > resolved, and (4) the test user will never be active if I'm not > running actual tests, there's no reason to censor the curl call. > > curl -k -u test:test > https://localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProto colHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostCon figs > > > > > I tried it with or without quote marks around the URL; I tried it > both with the user in a "-u" clause, as above, or with the user > prefixing the domain. In all four cases, I get what appears to be > the exact same stacktrace as before. You will absolutely have to quote the whole URL, otherwise the embedded "&" character will cause the shell to do weird things. In a local VisualVM, I grabbed the path to a random protocol handler. The JMX bean object name was: Catalina:type=ProtocolHandler,port=8215 I'm only missing the address portion, because I haven't set any address in the configuration. I don't believe any of those characters need to be escaped except for the "=" because the object name needs to be a parameter value. That would give me: Catalina:type%3DProtocolHandler,port%3D8215 Now the URL line becomes (for me, using a management port): http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa ndler,port%3D8215=reloadSslHostConfigs This gives me the same stack trace as you; same line numbers, etc. In my case, I have no SSL configured, so maybe I can't reload those configs for some reason. If I call an arbitrary other method, it works: http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa ndler,port%3D8215=findSslHostConfigs OK - Operation findSslHostConfigs returned: There is no other output. So there aren't any SSLHostConfigs. Have you configured any elements, or are you using the old-style configuration like: ? You may need to change your connector configuration to use nested elements if it's not that way already. Try invoking the "findSslHostConfigs" operation to see if it completes. That will at least tell you if you have your objectname correct. Like this: $ curl -k -u "test:test" "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocol Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs" > I can't tell any difference, other than the user, and specifying a > port, between that and the "hard-coded" curl call on slide 35 of > the presentation. And if I leave out the port number, I get > "connection refused." > > FYI, the relevant lines in tomcat-users.xml (with the actual admin > user definition redacted) are: > >> >> [line redacted] > roles="manager-gui,manager-jmx"/> Your role is fine, now. You would have gotten a 401 response if you didn't have the right credentials. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4V1okACgkQHPApP6U8 pFgdjw//SJZPMvvfo322JDngUr6Sdv5MAmV0rfJZ0CQYmQ54LnhAIVX4I3TsgXae OwDtoQqi9tBk/1qhv9a9GZneXfox28FFb8PiTcwmUSAMcJfzoNFAESqC1HPZGqtD ET+cNXAde7N4bfaV/+HJGkTUEl5Ze2SBnONBxaBwMQgSUiYCwfr9iv/K2LIpGnjt PdCts7/XuvGmbWLsZFUpR6tWOwVYUGjXlT042mBegJPQoHkabAFv0xknrgk8oKaD bUKk2MSB/KZvR6Pzeq+pltSsjoE4C5zMx04gmMndcD7costp+1l2gXk7yOuC2qlI IRY3LxfI2qIstxcbX9DeuPuQcR0NBsUCcC4CNfBldJy2MEexiwlYp61JPwWr51f3 2gR9MKO11uAlVI1+xXXUsd5wTaXWOvAniphhO35ef88iLsNKQCEo24XhC0x9fYX9 MvbOMFO6w5jlslnrfTxSJyqMm1MT/uBnhoZx1lGHwTswF2/Zp9VDSgOiFCzNLkc9 UfRd+KY/Bk3pDkkkQ3BvEjLg/Lirudtaa9xTjfHDjpEIOUXFsYmALY9cqBvocrtF BVJIMUrvv4LlzzOtFXEqhnr5nh9HZJR9+3AggY0yy3gqa3fdiSli/I3JZNfYBSWx c0XR/sex2+vMeIAL+F89Bwp5AV5Q3ncs5Dp8xYIHnCx8yRd2eDo= =Yj+m -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
On 1/7/20 4:19 PM, Christopher Schultz wrote: You probably "spelled" something incorrectly. It might be a quoting/escaping issue. It might be a literal misspelling/typo. The JMXProxyServlet shouldn't NPE like that, though. I'll take a look and see if we can give you a better error message than that when it happens. Well given that (1) there's no production data at stake, (2) you don't know where this server is, (3) the test user will be removed permanently and replaced with something else once this problem is resolved, and (4) the test user will never be active if I'm not running actual tests, there's no reason to censor the curl call. curl -k -u test:test https://localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs I tried it with or without quote marks around the URL; I tried it both with the user in a "-u" clause, as above, or with the user prefixing the domain. In all four cases, I get what appears to be the exact same stacktrace as before. I can't tell any difference, other than the user, and specifying a port, between that and the "hard-coded" curl call on slide 35 of the presentation. And if I leave out the port number, I get "connection refused." FYI, the relevant lines in tomcat-users.xml (with the actual admin user definition redacted) are: [line redacted] -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/7/20 1:33 PM, James H. H. Lampert wrote: > This just gets weirder and weirder. > > I added manager-jmx to the admin account. I continued to get "401 > unauthorized." > > I then tried setting up another user, temporarily, with a > URL-friendly user-ID and password. If I just gave that user > "manager-gui," I got "403 access denied" instead, regardless of > whether I put the user-ID and password into the URL, or into a -u > clause. > > But then, when I tried adding "manager-jmx" to the temporary user, > I got a null pointer exception! > >> java.lang.NullPointerException at >> org.apache.catalina.manager.JMXProxyServlet.invokeOperationInternal(J MXProxyServlet.java:264) >> >> >> at >> org.apache.catalina.manager.JMXProxyServlet.invokeOperation(JMXProxyS ervlet.java:207) >> >> >> at >> org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.jav a:116) >> >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:231) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:166) >> >> >> at >> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52 ) >> >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:193) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:166) >> >> >> at >> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCh aracterEncodingFilter.java:109) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:193) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:166) >> >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:199) >> >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:96) >> >> >> at >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:610) >> >> >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:137) >> >> >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:81) >> >> >> at >> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAcce ssLogValve.java:660) >> >> >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:87) >> >> >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:343) >> >> >> at >> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java :798) >> >> >> at >> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLig ht.java:66) >> >> >> at >> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(Abstract Protocol.java:808) >> >> >> at >> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpo int.java:1498) >> >> >> at >> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBas e.java:49) >> >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1149) >> >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:624) >> >> >> at >> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskTh read.java:61) >> >> >> at java.lang.Thread.run(Thread.java:748) > > What I have on this box is Tomcat 8.5.40, under JVM 1.8.0_201-b09 > > Anybody know what's wrong now? You probably "spelled" something incorrectly. It might be a quoting/escaping issue. It might be a literal misspelling/typo. The JMXProxyServlet shouldn't NPE like that, though. I'll take a look and see if we can give you a better error message than that when it happens. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VICUACgkQHPApP6U8 pFgpHRAAquY32hPePQt4UBarAvgr1WkryFCoHXO+thEvVtpOj6/S/GBS3L6+Hxlu muT90BbQsFy4fhGM7cmSSeC44GQB5FV0EXiMskDnlqohM0BwgiwGUEVaXW9L7UwA G4KrOCRzYdgzjpdEmS2k1s71bcarawKD2sA7EB/GFmIZjTDj1Lgs66hGNNXsyy4e vrWAYWpp3omSh40a5Z5+ROwOvyjI6hgft33UXFwZbbGQdTmpbx5Y8f9mTRnhh8R0 EMq1Olu9ONsbOi0SPHb4/8DHoBIT4cHgrBtV8mqX3MrSn91D55rVouZzmyOttgXO txdH4mku8z8rr/C7+A8NG/Uc2R3YfH4tzYvzum+DavhL6HQ3N+Ob4GcRWwzR/RXN D35zI4trxtELYpnwJ3nNnSms9J79CIO/jfODubsRlWmBQuKcDww4sWyHQGvMbMGZ JW1MjCywXdcuKe9DXynxkTjjbbJktQEsszBhaFptJBzg7iG1BJXQmgXG70npj1pc FZiqvyKF7fATkZLEeumYmeKzKAb3F2M8l8ZuInscaiBWwHskb6JNkKeZNzvMdiGn kZibenXy78dhaYaldXrTzea7DYHFUdzaEL/1vRh6tdYM8OMHQBF+YIa41A5ICrPY Tx5Oav1yO9QQpsgu+BYjxrrK536g6ezLc8d7HjXh6lmq5K+CFHc= =jukF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
-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 '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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
This just gets weirder and weirder. I added manager-jmx to the admin account. I continued to get "401 unauthorized." I then tried setting up another user, temporarily, with a URL-friendly user-ID and password. If I just gave that user "manager-gui," I got "403 access denied" instead, regardless of whether I put the user-ID and password into the URL, or into a -u clause. But then, when I tried adding "manager-jmx" to the temporary user, I got a null pointer exception! java.lang.NullPointerException at org.apache.catalina.manager.JMXProxyServlet.invokeOperationInternal(JMXProxyServlet.java:264) at org.apache.catalina.manager.JMXProxyServlet.invokeOperation(JMXProxyServlet.java:207) at org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:116) at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:610) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:660) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:808) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) What I have on this box is Tomcat 8.5.40, under JVM 1.8.0_201-b09 Anybody know what's wrong now? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-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=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=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: 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
-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 [400: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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
James,
> Am 07.01.2020 um 03:11 schrieb James H. H. Lampert :
>
> 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=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=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?
I‘d prefer them in -u.
for separation of concerns, add a separate user with a longer one and shell
friendly password only with the role below...
> Or do I need to give the manager user an additional role? Currently, I have:
>
manager-jmx
(and maybe for other script-actions manager-script)
Peter
> --
> JHHL
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
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,
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=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=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:
>
>
> --
> JHHL
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
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=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=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:
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Question about iptables, Re: Let's Encrypt with Tomcat?
Ladies and Gentlemen: As I said earlier today, I have # 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 [400: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 But viewing Mr. Schultz's presentation, I see that it also calls for an output redirect. I don't have that second redirect, and yet the Tomcat server works fine. Why? Is that something to do with the "proxyPort" clause on the connector? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Heureka! Actually, I was thinking more "Sokath, his eyes uncovered!" And actually, at this point, I'm thinking I'm better off with Apache httpd handling port 80, since it would only be used for Let's Encrypt, and Let's Encrypt and certbot currently play much more nicely with it than with Tomcat. But that puts at least the next step of this exercise outside the scope of this List. It may be time to view Mr. Schultz's presentation again. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
James, >> Am 06.01.2020 um 22:28 schrieb James H. H. Lampert >> : >> >> 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 [400: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. Heureka! So you may add the like for Port 80 and you are set for LE! Peter > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Breakthrough, Re: Let's Encrypt with Tomcat?
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 [400: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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
$ 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
> 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, 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, > > 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-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Let's Encrypt with Tomcat?
-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, > 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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
》> 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, 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Let's Encrypt with Tomcat?
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
-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): >> ServerName foo.bar.net Redirect >> permanent / https://foo.bar.net:8000/ > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
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): ServerName foo.bar.net Redirect permanent / https://foo.bar.net:8000/ 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Chris & James, Sorry for topposting. Is Tomcat really the SSL endpoint that takes the cert? Then it wouldn’t matter if there is a loadbalancer or the like. Maybe it’s just authbind or iptables natting? that would be a common way to have a non-root service to listen externally on 443. If not and there is a proxy like apache or nginx, the way to handle certbot would be completely different, right? Like James said before he uses the cert also on apache! But how do you separate 443 for the services you have on apache and tomcat? However, we still need the port 80 endpoint to deploy the acme-challenge to! No way around that without DNS-01 or TLS-ALPN-01, which are only complicating the process! if httpd is serving your hostname on port 80 and you are able to write to httpd-webroot, point certbot’s —webroot to that directory. if httpd is not on port 80, you could do the same that you did for 443 forwarding to redirect 80 to tomcat port 8080. IIKS, hope I was not too confusing??? Peter Peter Kreuser > Am 30.12.2019 um 20:01 schrieb Christopher Schultz > : > > -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: >> > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
James, > Am 28.12.2019 um 00:33 schrieb James H. H. Lampert : > > >>> >>> 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
-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 < > jam...@touchtonecorp.com> wrote: > As it happens, one way or another (and I'm not entirely sure *which* way; I'd have to look at my notes), we *do* have Tomcat listening directly on 443 (but not 80; nothing there is currently listening on 80) on that particular EC2 instance (and I'm pretty sure we have HTTPD running on a *different* port, for the SVN and Trac sharing the box). >> >> Hmm. It seems I was mistaken about two things: (1) that the >> Tomcat server under discussion is listening *directly* on 443, >> and (2) that I could find my notes on how I set the box up. >> >> What I can find is the server.xml file, and the active connector >> definition: >> >> > protocol="org.apache.coyote.http11.Http11NioProtocol" . . . >> clientAuth="false" sslProtocol="TLS" /> >> >> The thing that catches my eye is port="8443" proxyPort="443" >> >> I hope that indicates how it is I'm getting this to look like >> port 443 to the outside world, because I honestly can't remember >> what I did (even though it looks like it's only been six months >> since I did it). >> >> -- James H. H. Lampert >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
-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: > > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Chris, Peter Kreuser > Am 27.12.2019 um 21:14 schrieb Christopher Schultz > : > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > >> > 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? Like you said something like tomcatctl graceful that you could just simply call from $CATALINA_BASE/bin. Maybe another option to catalina.sh that just calls the internals of tomcat. Restarting the whole tomcat with big webapps is simply not an option. > >>> 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. The way it is right now works. But it’s simply not for the regular admin. The frequent questions about the initial setup of the manager app and the clumsy jmx activation show that - in my opinion. (We’re not even talking about auth or ssl for jmx)! Peter > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GZh8ACgkQHPApP6U8 > pFjw8hAAqpsfbF/25K9A8l6ZFLoLrO+9C7z+86i1KLI/91VMylTxe/9Im8+Id/jG > 4AOXOov5m8SvzBQIDnjnSbUrVAvZ9J36pzlH4FoAxDQoZY3DWmyGPPa7S56OKG0g > Ha3rS5QziBjV9XbSuCL+6hbt4VBLVY0aRT9dvkDahiN42j2cczc2AOi1GxSf1WbY > iIYO8c1yfJvF/4wo7lBE6WpLRJb3RVI9psRuDm/yaMGY/nBzzNbYvhgB+pM/m0dw > Ls+w2HC6X8dq+0jV33FH1MdEY6yroH2gapclLcaeJ1yB2uke2cvGo0/vi3MdzOYK > CndNSfQrXTeyawWcgj4DjQZy9koBeXfdDXC18cFOKLvceMmV6UG8jwSBSVDjhYml > Ut9W7+GPYn8fBej9I/PaLRB3VAS47pRjY6MjA+AEMZxdowyOiNpc6E5snP4N+J9u > s3wTL9gfPGIOrrIilSPD9eIIHGExZ5na3FxuVV1grGSOMAq8EoJRn9iCBjyrYwuF > JsKXtvG2e91r/pvSL/zTDufoZysVvf4aUrgnxA9kY8lp+3O6+3U/5FTLWWtc7Fcj > ljjb87yda57Zvb/KU95GBakDt8+3fbMMyhHeUAANWrSMPIN5astpacBdDRD5F1KH > HNW5QTmxG56D0yaM3/pKPpoFBMqojtCen6MO8ZVkSN9Qv4H3NKo= > =SHiE > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Something else I noticed, just now: If I do an "ss -tulwn" on the EC2 instance under discussion, it only lists 8443, not 443. And yet if I look at the AWS management console, the security group I set up allows 443, but not 8443, and I don't see anything external to the box that would be doing the port remapping. Of course, if (as per my previous post) I can (1) get Tomcat sharing the same actual certificate and private key files as HTTPD, and (2) get HTTPD to open up on 80, then *how* 8443 gets remapped to 443 becomes moot. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
As it happens, one way or another (and I'm not entirely sure *which* way; I'd have to look at my notes), we *do* have Tomcat listening directly on 443 (but not 80; nothing there is currently listening on 80) on that particular EC2 instance (and I'm pretty sure we have HTTPD running on a *different* port, for the SVN and Trac sharing the box). Hmm. It seems I was mistaken about two things: (1) that the Tomcat server under discussion is listening *directly* on 443, and (2) that I could find my notes on how I set the box up. What I can find is the server.xml file, and the active connector definition. The thing that catches my eye is port="8443" proxyPort="443" I hope that indicates how it is I'm getting this to look like port 443 to the outside world, because I honestly can't remember what I did (even though it looks like it's only been six months since I did it). I now know one thing that I apparently did *not* do: I did *not* have HTTPD handle the public-facing TLS for Tomcat, because when I swapped in a self-signed keystore on Tomcat, and used the new "Re-read TLS configuration files" button in Manager, the self-signed cert is what was visible to browsers. Trac and SVN do indeed appear to be set up through HTTPD. And the Tomcat and Apache files appear to share a common keypair and certificate, and I'm pretty sure I remember *starting with* a Java Keystore (since it's very familiar territory for me, and since I have KeyStore Explorer on my Mac), and exporting files from it, i.e., (the names have been changed to protect the innocent), I started with "/etc/tomcat8/foo.bar.net.ks," and derived "/etc/pki/tls/certs/foo.bar.net.cer," "/etc/pki/tls/certs/foo.bar.net.ca.crt," and "/etc/pki/tls/private/foo.bar.net.key" from it. Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt" and ".key" files directly, instead of the Java Keystore file? If so, then that could potentially simplify things: if I have HTTPD listen on 80, and Tomcat sharing the same actual certificate and private key *files* that HTTPD uses, then the only other thing I have to automate would be a cron job to either restart Tomcat, or just do a programmatic "re-read TLS configuration," whenever the regular Let's Encrypt job for HTTPD completes. Does any of this make any sense at all, or am I sucking antimatter? -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Hi All, If possible, I think it's better to let 443 (https) requests hitting an instance be redirected to 80 so you don't have to configure an SSL locally in the instance itself. It's very cumbersome to do it that way. You can also use a single instance behind an AWS LB if you only have one instance to use. Just my two cents worth - Andy s. On Fri, Dec 27, 2019 at 2:08 PM James H. H. Lampert < jam...@touchtonecorp.com> wrote: > >> As it happens, one way or another (and I'm not entirely sure > >> *which* way; I'd have to look at my notes), we *do* have Tomcat > >> listening directly on 443 (but not 80; nothing there is currently > >> listening on 80) on that particular EC2 instance (and I'm pretty > >> sure we have HTTPD running on a *different* port, for the SVN and > >> Trac sharing the box). > > Hmm. It seems I was mistaken about two things: (1) that the Tomcat > server under discussion is listening *directly* on 443, and (2) that I > could find my notes on how I set the box up. > > What I can find is the server.xml file, and the active connector > definition: > > protocol="org.apache.coyote.http11.Http11NioProtocol" >. . . > clientAuth="false" sslProtocol="TLS" /> > > The thing that catches my eye is > port="8443" proxyPort="443" > > I hope that indicates how it is I'm getting this to look like port 443 > to the outside world, because I honestly can't remember what I did (even > though it looks like it's only been six months since I did it). > > -- > James H. H. Lampert > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Andrew G. Stanton CEO/Founder/Principal Engineer, Stanton Web Applications, Inc. Founder, GetMorty.io and UniversalWallet.io email: andrewgstan...@gmail.com also: a...@stantonweb.com web: www.stantonweb.com *mobile: 415-793-4072* tel/fax: 415-738-8501 linkedin: https://www.linkedin.com/in/andrew-g-stanton/ twitter: https://twitter.com/andrewgstanton This message and any attachments are solely for the individual(s) named above and others who have been specifically authorized to receive such and may contain information which is confidential, privileged or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, copying, use or distribution of the information included in this message and any attachments is strictly prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you.
Re: Let's Encrypt with Tomcat?
As it happens, one way or another (and I'm not entirely sure *which* way; I'd have to look at my notes), we *do* have Tomcat listening directly on 443 (but not 80; nothing there is currently listening on 80) on that particular EC2 instance (and I'm pretty sure we have HTTPD running on a *different* port, for the SVN and Trac sharing the box). Hmm. It seems I was mistaken about two things: (1) that the Tomcat server under discussion is listening *directly* on 443, and (2) that I could find my notes on how I set the box up. What I can find is the server.xml file, and the active connector definition: protocol="org.apache.coyote.http11.Http11NioProtocol" . . . clientAuth="false" sslProtocol="TLS" /> The thing that catches my eye is port="8443" proxyPort="443" I hope that indicates how it is I'm getting this to look like port 443 to the outside world, because I honestly can't remember what I did (even though it looks like it's only been six months since I did it). -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 12/27/19 14:22, James H. H. Lampert wrote: > On 12/26/19 8:31 PM, Igal Sapir wrote: >> You should check out Chris' presentations on the topic. He >> outlines a very efficient process. There is probably more >> materials out there, but a quick search brings up the video [1] >> and slides [2] from his presentation at ApacheCon earlier this >> year, as well as his shell script for automating the process. > > Excellent video. I'm glad you think so. Before the recording begins, there are ~10 minutes worth of shenanigans where 4 Tomcat PMC members try to figure out how to get the projector working. And no, Rémy, it wasn't because I was using a Mac :) > As it happens, one way or another (and I'm not entirely sure > *which* way; I'd have to look at my notes), we *do* have Tomcat > listening directly on 443 (but not 80; nothing there is currently > listening on 80) on that particular EC2 instance (and I'm pretty > sure we have HTTPD running on a *different* port, for the SVN and > Trac sharing the box). ACME almost requires port 80 to be opened. There are other opens, but the simplest is to open port 80[1]. > At this point, I think I'm going to have to go through the video > at least once more, just to come up with intelligent questions to > ask, other than "What is JMX?" (I've already got the Wikipedia > article up, but it seems to be more about the internal nuts and > bolts of it than about how to use it.). When the subject first > comes up in the presentation, I saw some sort of JMX GUI in use, > that was evidently something the attendees were already familiar > with, but I'm completely in the dark. Honestly, you don't even have to understand JMX itself (spoiler alert: it's a protocol which lets you manage stuff, like SNMP does. It's Java-specific, requires RMI and an odd configuration. I wouldn't recommend using it directly unless you want to use a GUI client like VisualVM or one of the Java IDEs that has one bundles into it. I always recommend using the JMXProxyServlet which is a part of the manager webapp. It gives you access to all the MXBean stuff that you can get via the full JMX protocol without having to have complicated (JMX) configuration, additional ports opened on your firewall, or a GUI available at all. (I tend to work on headless Linux-based servers, so a GUI isn't convenient at all. Likewise, running a GUI to ping an MXBean in a crontab isn't something you want to do.) If you have a Tomcat running on your localhost desktop, this will be easy to explore: just fire-up VisualVM (which you may have to download[1] and install) or jvisualvm (if you have a JDK) and attach to the JVM running Tomcat. Under the "MBeans" tab, there is a tree of ... stuff. Poke-around in there and have a look at the things under "Catalina". Many of them are read-only, but some of them have writable values and also "operations" that you can invoke to cause something to happen on the server. At $work, we have an MBean for reloading system announcements from our database. We can push an announcement into a table in our database and every 5 minutes our application servers refresh their list of announcements from the db. This allows us to have mostly-current information available to the application server without having to hit the db for every single user hitting a certain set of pages. That MBean just has a "reload" operation which takes no arguments and returns nothing. When it runs, it refreshes the announcements from the database. Tomcat has something similar for the TLS configuration. If you reload that, it will re-load the keystores, truststores, certificates, etc. that were in the original configuration. - -chris [1] https://jmorahan.net/article/lets-encrypt-without-port-80 [2] https://visualvm.github.io/ -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GeEMACgkQHPApP6U8 pFjLghAAq0R7SxJbkmQTOd4/M/fbdkEk5ybjarXGFG4/+PeSzavdIShbI2QEx7VD 1ymtN9IHCRCA786llno0+YJqzRMkW5XTQ89+ggH5/gGshTvtYmeaIBhCjxyqeBiQ bOO1va5bWDXFCdDsDRJFHyZ42tT52G27F0CZZgzaXlrxu0peWm2oZFGtcim1hxFY bh6MIq13pPIBWZTNk4DRLBn/rTnop/yHTU+RC916ZVnvycMrhgEl6BOWiB1Tbm1o jtCABd8xkz9o+Ozzm0NfEKYBbZFozLA4WL+hOObzdPaKcixLtAdsU2ZBMCjM9bmS mthISotVTCI6ypNSCjISAg3aA+1rfSUh1Si40moAK+H939Adwt4mM+J4L54xXZxh qvy4YgwHUScycYMAvCJA+j/PONldsDJJ0QMiDO1Ihb4PnZKhaXcI+6tmb1fjwvL/ ifunV6InrLrHVKLcpvhdA3QKw2+TlsmZXdoGJUiaDn/UjAwvGkw9GhxLd0UVE/B3 Tdv19dkxQnJjaef+SE1Zci2CSgVV4VlvKUcJ9HlyJvi0IIvWIR9nRzagDjUEiosA c9WsQVyfdu5+unkjyQXmY/NZNt1um0XfF5qBLqucfdS2ccsUPyE5EbHwso83yaCn iftxyTNhiTj6GwR5kpKyb0lbXPDchEJzPoQ9F6Er12HB5Inmf9w= =v9pw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter,
On 12/27/19 11:27, logo wrote:
> Am 2019-12-27 16:40, schrieb Christopher Schultz: That's the plan.
> In Las Vegas, Christopher Tubbs did say to me "aw, I was really
> hoping for you to tell us that you just set letsEncrypt="true" in
> your configuration and you are done". So there is definitely more
> that can be done, here.
>
> The plan was to try to get someone to integrate my script (or
> equivalent) into certbot or other ACME clients. Maybe what we
> really need is a command that can be run that "gracefully" restarts
> the server -- like httpd already does. There is no reason to
> actually restart the server -- just reinitialize the TLS engine for
> the connector. So maybe what we need is a script that basically
> just hits the jmxproxy to reinit the connector and tell certbot to
> use that when it's done with the ACME stuff.
>
>> oh I get the idea! a hook-script, right?
Yeah, I guess. certbot basically runs "apachectl graceful" when you
are using the "apache" plug-in. If we had a "tomcat" plug-in, maybe
that could run "tomcatctl graceful" and that just pings the manager
application. Unfortunately, it needs a bunch of configuration like the
hostname and port number to use, username/password, which connector to
bounce, etc.
>> Like the 2nd part of your script. well specifically it could
>> reload only the SSLHostConfig affected by this new cert curl
>> "https:/$JMXUSER:$JMXPASSWORD@localhost:${SERVICE_PORT}/manager/jmxpr
oxy?invoke=Catalina:type=ProtocolHandler,port={CONNECTOR_PORT}=reload
SslHostConfig=${HOSTNAME}"
Right,
>>
but the idea is that certbot has "plug-ins" and we'd need to
supply a "tomcat" plug-in that did things like this. I'm not sure
where the best place to keep configuration would be. Someone who
understands certbot (or autobot, etc.) would be a better resource than m
e.
>> Or did you think about a bin/version.sh type script? That would
>> get a +1 from me.
What do you mean?
>> What I don't like is, that one needs to add credentials in
>> tomcat-users.xml and expose the manager-interface.
You can use other authentication mechanisms... it's just that usually
nobody bothers since it's easy to configure tomcat-users.xml. Exposing
the manager interface is a bit of pain, but it can be scripted. Our
deployments install a proper tomcat-users.xml file and enable the
manager, locked-down to localhost connections.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GZh8ACgkQHPApP6U8
pFjw8hAAqpsfbF/25K9A8l6ZFLoLrO+9C7z+86i1KLI/91VMylTxe/9Im8+Id/jG
4AOXOov5m8SvzBQIDnjnSbUrVAvZ9J36pzlH4FoAxDQoZY3DWmyGPPa7S56OKG0g
Ha3rS5QziBjV9XbSuCL+6hbt4VBLVY0aRT9dvkDahiN42j2cczc2AOi1GxSf1WbY
iIYO8c1yfJvF/4wo7lBE6WpLRJb3RVI9psRuDm/yaMGY/nBzzNbYvhgB+pM/m0dw
Ls+w2HC6X8dq+0jV33FH1MdEY6yroH2gapclLcaeJ1yB2uke2cvGo0/vi3MdzOYK
CndNSfQrXTeyawWcgj4DjQZy9koBeXfdDXC18cFOKLvceMmV6UG8jwSBSVDjhYml
Ut9W7+GPYn8fBej9I/PaLRB3VAS47pRjY6MjA+AEMZxdowyOiNpc6E5snP4N+J9u
s3wTL9gfPGIOrrIilSPD9eIIHGExZ5na3FxuVV1grGSOMAq8EoJRn9iCBjyrYwuF
JsKXtvG2e91r/pvSL/zTDufoZysVvf4aUrgnxA9kY8lp+3O6+3U/5FTLWWtc7Fcj
ljjb87yda57Zvb/KU95GBakDt8+3fbMMyhHeUAANWrSMPIN5astpacBdDRD5F1KH
HNW5QTmxG56D0yaM3/pKPpoFBMqojtCen6MO8ZVkSN9Qv4H3NKo=
=SHiE
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
On 12/26/19 8:31 PM, Igal Sapir wrote: You should check out Chris' presentations on the topic. He outlines a very efficient process. There is probably more materials out there, but a quick search brings up the video [1] and slides [2] from his presentation at ApacheCon earlier this year, as well as his shell script for automating the process. Excellent video. As it happens, one way or another (and I'm not entirely sure *which* way; I'd have to look at my notes), we *do* have Tomcat listening directly on 443 (but not 80; nothing there is currently listening on 80) on that particular EC2 instance (and I'm pretty sure we have HTTPD running on a *different* port, for the SVN and Trac sharing the box). At this point, I think I'm going to have to go through the video at least once more, just to come up with intelligent questions to ask, other than "What is JMX?" (I've already got the Wikipedia article up, but it seems to be more about the internal nuts and bolts of it than about how to use it.). When the subject first comes up in the presentation, I saw some sort of JMX GUI in use, that was evidently something the attendees were already familiar with, but I'm completely in the dark. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Chris,
Am 2019-12-27 16:40, schrieb Christopher Schultz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter,
On 12/27/19 07:24, logo wrote:
Hi James,
Am 2019-12-27 05:31, schrieb Igal Sapir:
James,
On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:
We have a Tomcat (8.5.40) server running on an Amazon EC2
instance, currently using a Java Keystore for the SSL support.
We would like to be able to use Let's Encrypt, but I've learned
that Let's Encrypt and Tomcat don't get along all that well
together. The best I've found so far are article at:
<
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-
3db8a469e3d2
and this thread in the Let's Encrypt community forum:
<
https://community.letsencrypt.org/t/how-can-i-automate-renewals-with
- -tomcat/81423
Does anybody here have any experience with situations like
this? Does anybody here have any suggestions? Or, as another
alternative, does anybody here know of some Amazon AWS product
that could front-end a single-box, non-load-balanced Tomcat
server, and use Amazon's free "Public Certificates"? (I've
already posted that last to the relevant Amazon forum.)
You should check out Chris' presentations on the topic. He
outlines a very efficient process. There is probably more
materials out there, but a quick search brings up the video [1]
and slides [2] from his presentation at ApacheCon earlier this
year, as well as his shell script for automating the process.
Igal
[1] https://www.youtube.com/watch?v=BWUjvmJgSeE [2]
<https://people.apache.org/~schultz/ApacheCon%20NA%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):
After certbot has finished, reload the SSL config for the updated
Host through the jmxproxy and you are done.
That's the plan. In Las Vegas, Christopher Tubbs did say to me "aw, I
was really hoping for you to tell us that you just set
letsEncrypt="true" in your configuration and you are done". So there
is definitely more that can be done, here.
The plan was to try to get someone to integrate my script (or
equivalent) into certbot or other ACME clients. Maybe what we really
need is a command that can be run that "gracefully" restarts the
server -- like httpd already does. There is no reason to actually
restart the server -- just reinitialize the TLS engine for the
connector. So maybe what we need is a script that basically just hits
the jmxproxy to reinit the connector and tell certbot to use that when
it's done with the ACME stuff.
oh I get the idea! a hook-script, right?
Like the 2nd part of your script. well specifically it could reload only
the SSLHostConfig affected by this new cert
curl
"https:/$JMXUSER:$JMXPASSWORD@localhost:${SERVICE_PORT}/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port={CONNECTOR_PORT}=reloadSslHostConfig=${HOSTNAME}"
Or did you think about a bin/version.sh type script? That would get a +1
from me. What I don't like is, that one needs to add credentials in
tomcat-users.xml and expose the manager-interface.
I don't think it's necessary to build ACME into Tomcat itself when
tools like certbot already exist for that purpose, and admins will be
more familiar with those than some server-specific configuration.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJeMACgkQHPApP6U8
pFj6gA/+NS5ZO6IJZ8W8/XT7usLq8wG+B0VuRFGzPhERam0XqBFEe59AvW+LXpIa
ChUy/eZYkrtGmRX7ZhSr/njD3mEhp+3R2XVgM91kPg4WWIkpAeLixuJOaoqn5QZU
jDr9sWpe190i2RI/OKlki/ADJ6oEemJsF3HElW4YcSYtWnqgmjAzncCJDJd3xvrq
bCskiXd4ru7Afg0T0hv/B8B62W5DgtuvB0GqmTsQBElZ9cTpGMJFJFH3WUfVBwZV
jpE/X/jmArYnU/lJIf22of8+zZgCYxEDGmiNGhZxPMh+A8lkn71fyfXJ3ZojijIm
p29KSSWJX0GPcJpIq7xxs4tmvmehIErjxPyacTcGwEhhY0TCKA7aGnh8yrVrFJcs
Tvz/2CmPvDva37/d32Knv9mv+Niw2ia8TGD6SFmaxmlNLxWR9nB9i+VobY
Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alex, On 12/27/19 10:07, Alex O'Ree wrote: > i use letsencrypt with tomcat. i adopted a cronjob/bash script that > auto renews the cert before expiration, it then stops tomcat, > refreshes the jks files, then restarts tomcat. yeah it's down time, > but it is minimal and it works You can do better, depending upon your version of Tomcat. https://tomcat.apache.org/presentations.html#latest-lets-encrypt - -chris > On Thu, Dec 26, 2019 at 7:49 PM James H. H. Lampert < > jam...@touchtonecorp.com> wrote: > >> We have a Tomcat (8.5.40) server running on an Amazon EC2 >> instance, currently using a Java Keystore for the SSL support. >> >> We would like to be able to use Let's Encrypt, but I've learned >> that Let's Encrypt and Tomcat don't get along all that well >> together. The best I've found so far are article at: >> >> < >> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3 db8a469e3d2 >>> >> >> >> and this thread in the Let's Encrypt community forum: >> >> >> < >> https://community.letsencrypt.org/t/how-can-i-automate-renewals-with- tomcat/81423 >>> >> >> >> Does anybody here have any experience with situations like this? Does >> anybody here have any suggestions? Or, as another alternative, >> does anybody here know of some Amazon AWS product that could >> front-end a single-box, non-load-balanced Tomcat server, and use >> Amazon's free "Public Certificates"? (I've already posted that >> last to the relevant Amazon forum.) >> >> James H. H. Lampert Touchtone Corporation >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJisACgkQHPApP6U8 pFhZdg//RU4E6kqOFnfbUtU0K7qqle2wTZ4E4RJ6dykWiXM9rtP3MiSGf/UgYMiA aK/0m/s00pmv06T9tCwGVbQetf2xXbwYsI47Dv4mood70PnWTnpGv5CKpt2tuGP0 mQSAnRpPIogHdViSmnwcpBAk5DN2HlHbF+nXvVg1tAlubKQFD2p5uD7ycebjYzmq K2HTda71pUDh6pZ5ZNhUOu+NMbMWhOZeEAJzCM1lC2BM4M+J3BLGEvhaFiZOLmb0 QwqcilBktqL0XJhcHSbMQyJWlLoHPQz/XpPLdCn7MeHgmi9ejOT0bBZNkn6D7pmt u0P87hrT7ixgnI5Te52JkdzKIPV+ohBfDIUTQfx1uKoPbP5u7BPpA2zuxgxGrQVJ A2/kitNmYYklf9dF8OyzlVfNTWj+nonEC87UMPmYyJn2voe8TyDwPGBRyiE4Kpqx zMPfAR7on2deaC8ifqXbWlfmINjxMt3Yinj/I2awebbhU+smkPUix3qgB5+ukj+W t7V/uGHSs5FZA2R75TujazLbnBNxfDEXhSnggvn5eWCYUF4YKSqhimjY8OX9zM7U h1cJ0gipVgVlElI62tfL8HhyJVHml/8zqBv3+g90gWazOWMe21KNyC2U/98BVih+ j3UwrcXE486p/HUmeTY9O2nEbLk0FUxuoRGv9xZOXwk58Js2yJs= =hogF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter,
On 12/27/19 07:24, logo wrote:
> Hi James,
>
> Am 2019-12-27 05:31, schrieb Igal Sapir:
>> James,
>>
>> On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
>> jam...@touchtonecorp.com> wrote:
>>
>>> We have a Tomcat (8.5.40) server running on an Amazon EC2
>>> instance, currently using a Java Keystore for the SSL support.
>>>
>>> We would like to be able to use Let's Encrypt, but I've learned
>>> that Let's Encrypt and Tomcat don't get along all that well
>>> together. The best I've found so far are article at:
>>>
>>> <
>>> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-
3db8a469e3d2
>>>
>>>
>>>
>
>>>
>>> and this thread in the Let's Encrypt community forum:
>>>
>>> <
>>> https://community.letsencrypt.org/t/how-can-i-automate-renewals-with
- -tomcat/81423
>>>
>>>
>>>
>
>>>
>>> Does anybody here have any experience with situations like
>>> this? Does anybody here have any suggestions? Or, as another
>>> alternative, does anybody here know of some Amazon AWS product
>>> that could front-end a single-box, non-load-balanced Tomcat
>>> server, and use Amazon's free "Public Certificates"? (I've
>>> already posted that last to the relevant Amazon forum.)
>>>
>>
>> You should check out Chris' presentations on the topic. He
>> outlines a very efficient process. There is probably more
>> materials out there, but a quick search brings up the video [1]
>> and slides [2] from his presentation at ApacheCon earlier this
>> year, as well as his shell script for automating the process.
>>
>> Igal
>>
>> [1] https://www.youtube.com/watch?v=BWUjvmJgSeE [2]
>> <https://people.apache.org/~schultz/ApacheCon%20NA%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):
>
> certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"
> certificateFile="${catalina.base}/conf/ssl/cert.pem"
>
> certificateChainFile="${catalina.base}/conf/ssl/chain.pem"
> type="RSA" />
>
> After certbot has finished, reload the SSL config for the updated
> Host through the jmxproxy and you are done.
That's the plan. In Las Vegas, Christopher Tubbs did say to me "aw, I
was really hoping for you to tell us that you just set
letsEncrypt="true" in your configuration and you are done". So there
is definitely more that can be done, here.
The plan was to try to get someone to integrate my script (or
equivalent) into certbot or other ACME clients. Maybe what we really
need is a command that can be run that "gracefully" restarts the
server -- like httpd already does. There is no reason to actually
restart the server -- just reinitialize the TLS engine for the
connector. So maybe what we need is a script that basically just hits
the jmxproxy to reinit the connector and tell certbot to use that when
it's done with the ACME stuff.
I don't think it's necessary to build ACME into Tomcat itself when
tools like certbot already exist for that purpose, and admins will be
more familiar with those than some server-specific configuration.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJeMACgkQHPApP6U8
pFj6gA/+NS5ZO6IJZ8W8/XT7usLq8wG+B0VuRFGzPhERam0XqBFEe59AvW+LXpIa
ChUy/eZYkrtGmRX7ZhSr/njD3mEhp+3R2XVgM91kPg4WWIkpAeLixuJOaoqn5QZU
jDr9sWpe190i2RI/OKlki/ADJ6oEemJsF3HElW4YcSYtWnqgmjAzncCJDJd3xvrq
bCskiXd4ru7Afg0T0hv/B8B62W5DgtuvB0GqmTsQBElZ9cTpGMJFJFH3WUfVBwZV
jpE/X/jmArYnU/lJIf22of8+zZgCYxEDGmiNGhZxPMh+A8lkn71fyfXJ3ZojijIm
p29KSSWJX0GPcJpIq7xxs4tmvmehIErjxPyacTcGwEhhY0TCKA7aGnh8yrVrFJcs
Tvz/2CmPvDva37/d32Knv9mv+Niw2ia8TGD6SFmaxmlNLxWR9nB9i+VobYdeQeCL
xOvksLYZluhLcvTpKgxutv+S7utt+i5QuuvjphWxzT5ro0x6ZBMuPGBdhFHzo4M2
bVljArD183gM46navyBk9xHxjaTHckGu5dramqyUYYvlG4HwGdvLk2CP780DT/Ik
Ntacf1O3KIDUyDqKxZepSeqExWuBZc1hco08lsk+un1kF3uFIQlspCwz/8laErh5
eQZs2Yf8GCksO0piXX1Ojo7nbG4vjuh+kwotkIcxUl2Ww/jnerE=
=L67K
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
i use letsencrypt with tomcat. i adopted a cronjob/bash script that auto renews the cert before expiration, it then stops tomcat, refreshes the jks files, then restarts tomcat. yeah it's down time, but it is minimal and it works On Thu, Dec 26, 2019 at 7:49 PM James H. H. Lampert < jam...@touchtonecorp.com> wrote: > We have a Tomcat (8.5.40) server running on an Amazon EC2 instance, > currently using a Java Keystore for the SSL support. > > We would like to be able to use Let's Encrypt, but I've learned that > Let's Encrypt and Tomcat don't get along all that well together. The > best I've found so far are article at: > > < > https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2 > > > > and this thread in the Let's Encrypt community forum: > > > < > https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423 > > > > Does anybody here have any experience with situations like this? Does > anybody here have any suggestions? Or, as another alternative, does > anybody here know of some Amazon AWS product that could front-end a > single-box, non-load-balanced Tomcat server, and use Amazon's free > "Public Certificates"? (I've already posted that last to the relevant > Amazon forum.) > > James H. H. Lampert > Touchtone Corporation > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Let's Encrypt with Tomcat?
Hi James,
Am 2019-12-27 05:31, schrieb Igal Sapir:
James,
On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:
We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
currently using a Java Keystore for the SSL support.
We would like to be able to use Let's Encrypt, but I've learned that
Let's Encrypt and Tomcat don't get along all that well together. The
best I've found so far are article at:
<
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
>
and this thread in the Let's Encrypt community forum:
<
https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423
>
Does anybody here have any experience with situations like this? Does
anybody here have any suggestions? Or, as another alternative, does
anybody here know of some Amazon AWS product that could front-end a
single-box, non-load-balanced Tomcat server, and use Amazon's free
"Public Certificates"? (I've already posted that last to the relevant
Amazon forum.)
You should check out Chris' presentations on the topic. He outlines a
very
efficient process. There is probably more materials out there, but a
quick
search brings up the video [1] and slides [2] from his presentation at
ApacheCon earlier this year, as well as his shell script for automating
the
process.
Igal
[1] https://www.youtube.com/watch?v=BWUjvmJgSeE
[2]
<https://people.apache.org/~schultz/ApacheCon%20NA%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):
certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"
certificateFile="${catalina.base}/conf/ssl/cert.pem"
certificateChainFile="${catalina.base}/conf/ssl/chain.pem"
type="RSA" />
After certbot has finished, reload the SSL config for the updated Host
through the jmxproxy and you are done.
Hope that helps.
Peter
[4]
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig
James H. H. Lampert
Touchtone Corporation
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
James, On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert < jam...@touchtonecorp.com> wrote: > We have a Tomcat (8.5.40) server running on an Amazon EC2 instance, > currently using a Java Keystore for the SSL support. > > We would like to be able to use Let's Encrypt, but I've learned that > Let's Encrypt and Tomcat don't get along all that well together. The > best I've found so far are article at: > > < > https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2 > > > > and this thread in the Let's Encrypt community forum: > > < > https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423 > > > > Does anybody here have any experience with situations like this? Does > anybody here have any suggestions? Or, as another alternative, does > anybody here know of some Amazon AWS product that could front-end a > single-box, non-load-balanced Tomcat server, and use Amazon's free > "Public Certificates"? (I've already posted that last to the relevant > Amazon forum.) > You should check out Chris' presentations on the topic. He outlines a very efficient process. There is probably more materials out there, but a quick search brings up the video [1] and slides [2] from his presentation at ApacheCon earlier this year, as well as his shell script for automating the process. Igal [1] https://www.youtube.com/watch?v=BWUjvmJgSeE [2] <https://people.apache.org/~schultz/ApacheCon%20NA%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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Let's Encrypt with Tomcat?
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 < jam...@touchtonecorp.com> wrote: > We have a Tomcat (8.5.40) server running on an Amazon EC2 instance, > currently using a Java Keystore for the SSL support. > > We would like to be able to use Let's Encrypt, but I've learned that > Let's Encrypt and Tomcat don't get along all that well together. The > best I've found so far are article at: > > < > https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2 > > > > and this thread in the Let's Encrypt community forum: > > > < > https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423 > > > > Does anybody here have any experience with situations like this? Does > anybody here have any suggestions? Or, as another alternative, does > anybody here know of some Amazon AWS product that could front-end a > single-box, non-load-balanced Tomcat server, and use Amazon's free > "Public Certificates"? (I've already posted that last to the relevant > Amazon forum.) > > James H. H. Lampert > Touchtone Corporation > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Andrew G. Stanton CEO/Founder/Principal Engineer, Stanton Web Applications, Inc. Founder, GetMorty.io and UniversalWallet.io email: andrewgstan...@gmail.com also: a...@stantonweb.com web: www.stantonweb.com *mobile: 415-793-4072* tel/fax: 415-738-8501 linkedin: https://www.linkedin.com/in/andrew-g-stanton/ twitter: https://twitter.com/andrewgstanton This message and any attachments are solely for the individual(s) named above and others who have been specifically authorized to receive such and may contain information which is confidential, privileged or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, copying, use or distribution of the information included in this message and any attachments is strictly prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you.
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
