You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2020/01/03 00:45:19 UTC
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):
> <VirtualHost _default_:81>
> ServerName foo.bar.net
> Redirect permanent / https://foo.bar.net:8000/
> </VirtualHost>
the unsecured Port 81 now redirects to 80. Conversely, if I leave out
the :8000 it redirects to the Tomcat server.
* Like a complete and utter idiot, I left no notes whatsoever about how
I set this thing up in the first place. Probably because I didn't fully
understand what I'd done, or how.
* Just as it was when I *was* setting this thing up in the first place,
httpd configuration files (that can be all over the place) make me long
for the simplicity of Tomcat configuration files.
I *think* I can *probably* get Apache (and a cron job running certbot)
on Let's Encrypt, and Tomcat using its certs (and a cron job reloading
them), without understanding what I'd done to get Tomcat showing up on
443 to the outside world, but it would be nice if I *did* understand
what I'd done.
--
James H. H. Lampert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
> Did I? I don't recall recommending purchasing a certificate
Purchase a domain name not certificate.
On Mon, 6 Jan 2020, 16:45 Christopher Schultz, <ch...@christopherschultz.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Zahid,
>
> On 1/6/20 10:08, Zahid Rahman wrote:
> > 》> If, however, I do curl https://foo.bar.net from my Mac, I get a
> >> response, but if I do curl https://localhost, it doesn't get
> >> anywhere.
> >
> > This may be relevant. In the video mentioned earlier in the thread
> > the let's encrypt expert says let's encrypt doesn't work on
> > localhost but it only works on actual domain.
>
> Correct. You cannot obtain a certificate from Let's Encrypt for
> "localhost"; it's got to be something Let's Encrypt can resolve and
> contact from their infrastructure. For that reason, LE doesn't work
> very well for internal networks.
>
> > He goes on to say you should purchase one "it is not very expensive
> > ".
>
> Did I? I don't recall recommending purchasing a certificate during a
> presentation on zero-cost certificates.
>
> I'd never bother paying for a certificate for an internal network.
> Just self-sign and establish your own trust. The purpose of LE is for
> environments where you need *public* trust, not private trust. Private
> trust is easy to establish: you get to decide all by yourself! :)
>
> - -chris
>
> > On Mon, 6 Jan 2020, 14:57 Christopher Schultz,
> > <ch...@christopherschultz.net> wrote:
> >
> > James,
> >
> > On 1/3/20 13:47, James H. H. Lampert wrote:
> >>>> On 1/3/20 9:57 AM, Christopher Schultz wrote:
> >>>>> Is perhaps the AWS firewall (which is a Load Balancer,
> >>>>> right?) redirecting the port?
> >>>>>
> >>>>> Easy test (from the server):
> >>>>>
> >>>>> $ telnet localhost 443
> >>>>
> >>>> I hadn't thought of that. But alas, that instance doesn't
> >>>> have Telnet on it.
> >>>>
> >>>>> If it connects, you have something on the host making this
> >>>>> work. If it fails to connect, the 443 -> 8443 magic is
> >>>>> outside the host itself.
> >>>>
> >>>> If, however, I do curl https://foo.bar.net from my Mac, I get
> >>>> a response, but if I do curl https://localhost, it doesn't
> >>>> get anywhere.
> >
> > So your instance is indeed listening on 8443 and the host (at least
> > on the loopback interface) isn't doing any port 443
> > funny-business.
> >
> >>>>> Note that if you are using AWS load-balancer, AWS provides
> >>>>> free certificates that auto-renew; just configure them and
> >>>>> you are done forever.
> >>>>
> >>>>> Let me know about the Load-Balancer. That's probably the
> >>>>> piece of the puzzle you aren't looking at quite yet.
> >>>>
> >>>> No; we *have* load-balanced clusters, and they *are* (as of
> >>>> last month) on AWS's certificate system, so I know what that
> >>>> looks like. This is completely different; when I connect, I
> >>>> see the certificate that is currently active on the Tomcat
> >>>> server (and if I plug a different cert into Tomcat, I see the
> >>>> change from my browser).
> >
> > There are also load-balancers that just move bytes and don't
> > terminate TLS. It's also possible to have the same certificate
> > installed in multiple places. I think you are going to have to look
> > around your network a little more to figure out what's happening.
> >
> > Maybe simply try:
> >
> > $ host foo.bar.net
> >
> > And check the IP versus the IP of the Tomcat node?
> >
> > -chris
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TZB0ACgkQHPApP6U8
> pFib/A//TRP6v+GXvkDw7DXMcP3EzQSCEZ6yzdKoL4cblDLwW1Upe5TWVtEvHdiG
> IoqKesMwIUQQQDlv2Z3x6N5iCe9G5cTyFsz0JlSPZxGiHNGF1viwVrH/fGSsDLbp
> V2Q9HDdmp6zApl12+8HI1akCxHTPfySKg3j9NjEJlpbEA8w+Gzok+5UbjI3LzQgK
> c2iCN2Uj2mLoH135jMrdBbmYOb3rD0oEiiZY/fNch5C9bVGI5hiP7APTz8EEsjiq
> ei7eL4X0B/p+q6lgDSmvylD42TrTnpfESpiSitSZoFtM03alFdRm4OySzXuXK8za
> tYtAIha+VQs1i3y7LdRB6mIsl5xsU1NtrqGDl9lSg5ciFjuLpIQNRFDI3kqa8KwA
> FgiYOLsQZASK4bjoULQCAlcK55TBCALnbjL8PGu55YAPXO895hkeFtWokDciX+8B
> RRMqRyY2OWOoUNDZKan9icEk93vArKPU4JoVGJyvH0HCFTk+HL2B9F5s2PYvc3WO
> g+iVQdXBlDi4ngYsY0TXWC4GKBPgKVBuylJbAwbyBumpLYExIiYANn9ldtxtK9mr
> ukdlo5fvvlGclVgfL9CygsHiGgz6+aeo/n+3VkOSBsfxRHbYuw0JERicRnVImt2r
> O5ulCHoN4LwdRqhAc4BxzrnTsdrqKeyv2Qn3ANhJbpz7qNImI5o=
> =kBdi
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Zahid,
On 1/6/20 10:08, Zahid Rahman wrote:
> 》> If, however, I do curl https://foo.bar.net from my Mac, I get a
>> response, but if I do curl https://localhost, it doesn't get
>> anywhere.
>
> This may be relevant. In the video mentioned earlier in the thread
> the let's encrypt expert says let's encrypt doesn't work on
> localhost but it only works on actual domain.
Correct. You cannot obtain a certificate from Let's Encrypt for
"localhost"; it's got to be something Let's Encrypt can resolve and
contact from their infrastructure. For that reason, LE doesn't work
very well for internal networks.
> He goes on to say you should purchase one "it is not very expensive
> ".
Did I? I don't recall recommending purchasing a certificate during a
presentation on zero-cost certificates.
I'd never bother paying for a certificate for an internal network.
Just self-sign and establish your own trust. The purpose of LE is for
environments where you need *public* trust, not private trust. Private
trust is easy to establish: you get to decide all by yourself! :)
- -chris
> On Mon, 6 Jan 2020, 14:57 Christopher Schultz,
> <ch...@christopherschultz.net> wrote:
>
> James,
>
> On 1/3/20 13:47, James H. H. Lampert wrote:
>>>> On 1/3/20 9:57 AM, Christopher Schultz wrote:
>>>>> Is perhaps the AWS firewall (which is a Load Balancer,
>>>>> right?) redirecting the port?
>>>>>
>>>>> Easy test (from the server):
>>>>>
>>>>> $ telnet localhost 443
>>>>
>>>> I hadn't thought of that. But alas, that instance doesn't
>>>> have Telnet on it.
>>>>
>>>>> If it connects, you have something on the host making this
>>>>> work. If it fails to connect, the 443 -> 8443 magic is
>>>>> outside the host itself.
>>>>
>>>> If, however, I do curl https://foo.bar.net from my Mac, I get
>>>> a response, but if I do curl https://localhost, it doesn't
>>>> get anywhere.
>
> So your instance is indeed listening on 8443 and the host (at least
> on the loopback interface) isn't doing any port 443
> funny-business.
>
>>>>> Note that if you are using AWS load-balancer, AWS provides
>>>>> free certificates that auto-renew; just configure them and
>>>>> you are done forever.
>>>>
>>>>> Let me know about the Load-Balancer. That's probably the
>>>>> piece of the puzzle you aren't looking at quite yet.
>>>>
>>>> No; we *have* load-balanced clusters, and they *are* (as of
>>>> last month) on AWS's certificate system, so I know what that
>>>> looks like. This is completely different; when I connect, I
>>>> see the certificate that is currently active on the Tomcat
>>>> server (and if I plug a different cert into Tomcat, I see the
>>>> change from my browser).
>
> There are also load-balancers that just move bytes and don't
> terminate TLS. It's also possible to have the same certificate
> installed in multiple places. I think you are going to have to look
> around your network a little more to figure out what's happening.
>
> Maybe simply try:
>
> $ host foo.bar.net
>
> And check the IP versus the IP of the Tomcat node?
>
> -chris
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TZB0ACgkQHPApP6U8
pFib/A//TRP6v+GXvkDw7DXMcP3EzQSCEZ6yzdKoL4cblDLwW1Upe5TWVtEvHdiG
IoqKesMwIUQQQDlv2Z3x6N5iCe9G5cTyFsz0JlSPZxGiHNGF1viwVrH/fGSsDLbp
V2Q9HDdmp6zApl12+8HI1akCxHTPfySKg3j9NjEJlpbEA8w+Gzok+5UbjI3LzQgK
c2iCN2Uj2mLoH135jMrdBbmYOb3rD0oEiiZY/fNch5C9bVGI5hiP7APTz8EEsjiq
ei7eL4X0B/p+q6lgDSmvylD42TrTnpfESpiSitSZoFtM03alFdRm4OySzXuXK8za
tYtAIha+VQs1i3y7LdRB6mIsl5xsU1NtrqGDl9lSg5ciFjuLpIQNRFDI3kqa8KwA
FgiYOLsQZASK4bjoULQCAlcK55TBCALnbjL8PGu55YAPXO895hkeFtWokDciX+8B
RRMqRyY2OWOoUNDZKan9icEk93vArKPU4JoVGJyvH0HCFTk+HL2B9F5s2PYvc3WO
g+iVQdXBlDi4ngYsY0TXWC4GKBPgKVBuylJbAwbyBumpLYExIiYANn9ldtxtK9mr
ukdlo5fvvlGclVgfL9CygsHiGgz6+aeo/n+3VkOSBsfxRHbYuw0JERicRnVImt2r
O5ulCHoN4LwdRqhAc4BxzrnTsdrqKeyv2Qn3ANhJbpz7qNImI5o=
=kBdi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
》> If, however, I do curl https://foo.bar.net from my Mac, I get a
> response, but if I do curl https://localhost, it doesn't get
> anywhere.
This may be relevant. In the video mentioned earlier in the thread the
let's encrypt expert says let's encrypt doesn't work on localhost but
it only works on actual domain. He goes on to say you should purchase one
"it is not very expensive ".
On Mon, 6 Jan 2020, 14:57 Christopher Schultz, <ch...@christopherschultz.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> James,
>
> On 1/3/20 13:47, James H. H. Lampert wrote:
> > On 1/3/20 9:57 AM, Christopher Schultz wrote:
> >> Is perhaps the AWS firewall (which is a Load Balancer, right?)
> >> redirecting the port?
> >>
> >> Easy test (from the server):
> >>
> >> $ telnet localhost 443
> >
> > I hadn't thought of that. But alas, that instance doesn't have
> > Telnet on it.
> >
> >> If it connects, you have something on the host making this work.
> >> If it fails to connect, the 443 -> 8443 magic is outside the host
> >> itself.
> >
> > If, however, I do curl https://foo.bar.net from my Mac, I get a
> > response, but if I do curl https://localhost, it doesn't get
> > anywhere.
>
> So your instance is indeed listening on 8443 and the host (at least on
> the loopback interface) isn't doing any port 443 funny-business.
>
> >> Note that if you are using AWS load-balancer, AWS provides free
> >> certificates that auto-renew; just configure them and you are
> >> done forever.
> >
> >> Let me know about the Load-Balancer. That's probably the piece of
> >> the puzzle you aren't looking at quite yet.
> >
> > No; we *have* load-balanced clusters, and they *are* (as of last
> > month) on AWS's certificate system, so I know what that looks like.
> > This is completely different; when I connect, I see the certificate
> > that is currently active on the Tomcat server (and if I plug a
> > different cert into Tomcat, I see the change from my browser).
>
> There are also load-balancers that just move bytes and don't terminate
> TLS. It's also possible to have the same certificate installed in
> multiple places. I think you are going to have to look around your
> network a little more to figure out what's happening.
>
> Maybe simply try:
>
> $ host foo.bar.net
>
> And check the IP versus the IP of the Tomcat node?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TSsMACgkQHPApP6U8
> pFgvHw//fBItKsqFiCNeA5lLwo6hi6tZaZY6BxC24SQfMPFe4TaQKkvl/ziGdvpc
> E7afIiahzkksZ5Afeq08xx5yE16XVWNDfXy005x5TjosK9tq+msYQU0RUXiHolPo
> iTNMfVAi7vHx4OYciJzDzV34vb8pF4Xl4AlMj/ESh38BUPsZWQtcpzmMi9Nf9+/q
> grQonVVKHBIydBSbygpiHBGcPesJX0kRUtpArVIWJZdw+V+lKApeo32Xw1Y+Dm0q
> 1knwGFzHYGdxROCCpez8dq83ABI5l4tmVMPYpTZsTxBrebZxXxy2GUfrRHTH8UaC
> E1ew1jHhYwyPWIUQjEAWynKqVZ8OFcBlRN3DwFvNCGMyd5c9vyE50qfRwzYqeQMk
> tEnNafRgWGdsiw0El79m6Xl3LVOd9psSYTgvobqICPk27YhPbpk7izR5td2stvxu
> wnmfgxBJd9lL/ckwkvQfKgsdQSnCx8ULJgNUWyCv/gKrhBuBK1gkRrHj3MbJM5Cf
> A7fquztvXVZdTnAuEBLvAhKdmIYX6k7W/TnX1kvJcBQ0AN1WhcbmnxQhcww2bn5s
> LB2VA91XKg8BaNItodEx03EsUEpbjIvxmnBoCbTgYxcVaKs76qxzP9DENZmGNV/b
> JTSEo7xAyGnRQ42l4pm1Lxj/8kAZLrZ5VfNK2DBmmDTeZ8eCUAI=
> =372g
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/6/20 11:29 AM, Christopher Schultz wrote:
> I think Route 53 always uses a load-balancer, doesn't it?
No. A load balancer implies the existence of a cluster, and this is a
single instance, with a fixed IP address, and that is the address in the
A record under Route 53.
And if a load balancer were involved, then something would show up under
load balancing: either a load balancer specific to this instance, or
something tying this instance to a load balancer on one of our two clusters.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/7/20 4:54 PM, Christopher Schultz wrote:
> I have further confused you, because TCP packets+connections also have
> state, and I misspoke.
Think nothing of it: at my age, I'm easily confused.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/7/20 7:22 PM, James H. H. Lampert wrote:
> On 1/7/20 4:17 PM, Christopher Schultz wrote:
>> iptables doesn't work on pipes, it works on packets. So you have
>> to redirect both incoming AND outgoing packets. That's why you
>> have the "output redirect" as well as the (more obvious) "input
>> redirect".
>
> Well, that just leaves me more puzzled than ever: why would our
> webapp (and Manager, for that matter) "work just fine" even though
> there's no sign of an output redirect in the iptables-save output
> (which I posted in its entirety)?
I have further confused you, because TCP packets+connections also have
state, and I misspoke. For UDP, you'd need the output redirect. The
TCP stack knows where the packets from a particular connection came
from, so responses along the same connection will go back the way they
came (this is NAT).
I'm not sure under what circumstances you need an OUTPUT redirect. I
seem to remember in my testing that I did indeed require the OUTPUT
redirect for things to work properly, but I may be making that up. The
slides mention that you "may need" those, and so I went ahead and put
the commands into the slides to show how to do it, if necessary.
Actually, it's not INPUT and OUTPUT, it's PREROUTING and POSTROUTING.
But those are basically the same concept for NAT as INPUT/OUTPUT are
for the "filter" tables.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VKC8ACgkQHPApP6U8
pFjqSRAAtKLif+WBswtmW8jOswhHn2SNRX2jUPm/RYOf7YqEFMYgeunA6GqewcT0
E2AVcBangWNGLuMWaaDhmFb5S4KcgW2c5HlbafBVtdggESkfjzozJnBw+sg6ShbZ
SxRQ4Lty/WwczAwduHkOaG7pFIeQlTKLSA1wL5zCJ02hQllYa1CYGIxMRAbwqu/m
1oC0jgiJs1zGXQN7XlgZdTD6uyHuUEhSLzh0it8+QtWEoLtki+LcvRy+Bmv+nEtw
ssqHpCX+TD4PnhcLpgFqWzy3DrUJYPUdV6dExnBujrFe2tzBAYtZfDy+Gshb6efo
LtGdLwaHgd6BLA71wEUEGMr85o9Opeuu1l3niENP/WaOuELidre3+umAVWr5Ypdq
zSGhO6clt6V9JCpXqM1EWh18hjDomKLb6Q1V9hpeTbBodmr8yFGo6D9pv9lddRyD
ArXxmqvL3aUSWXb80zrsUuPYXTO+SIbIXJRSJGPVRWM7eCrO8o1VpeTcD1bsXnPz
3l32YDEd6hbWjwLMWKzWu4oIuoZlHiCgsx4Tm2T0KtdBRn2/kStTLIoXOF5s129Y
ewZ0ygViiPqnTL1QD1jwnKG7EuAplx9ppKXCRM1MSbbB/+VSjdwDFvQCAnVykLhg
IB0AniJsaYP6BnPIGHcihPU3mj7Qp9uGcm/3QeAIwX0ULf1iEKs=
=tP73
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/7/20 4:17 PM, Christopher Schultz wrote:
> iptables doesn't work on pipes, it works on packets. So you have to
> redirect both incoming AND outgoing packets. That's why you have the
> "output redirect" as well as the (more obvious) "input redirect".
Well, that just leaves me more puzzled than ever: why would our webapp
(and Manager, for that matter) "work just fine" even though there's no
sign of an output redirect in the iptables-save output (which I posted
in its entirety)?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/7/20 12:28 PM, James H. H. Lampert wrote:
> On 1/7/20 7:32 AM, Christopher Schultz wrote:
>> Hah, sorry about that. Nobody thought of specifying that only
>> root can view the iptables stuff. :)
>
> Not your fault, nor that of anybody else here; I blame the author
> of iptables and iptables-save: it should either (a) allow *anybody*
> to *see* the information, or (b) *tell* the user that he/she is
> not authorized to see it.
>
> While I occasionally use "quiet failure" myself, when writing code
> to protect database fields from unauthorized modification, I
> generally do so only when it actually makes sense, and the user can
> actually *see* that his or her attempt to change the value(s) was
> quietly ignored.
>
> ***
>
> But I'm still puzzled about the "output redirect" specified in the
> presentation, but absent from this installation (and yet it still
> works just fine).
iptables doesn't work on pipes, it works on packets. So you have to
redirect both incoming AND outgoing packets. That's why you have the
"output redirect" as well as the (more obvious) "input redirect".
> Does the "proxyPort" clause on the connector have something to do
> with it "working just fine" without the "output redirect"?
The proxyPort is just a configuration option which overrides the port
that will be used when Tomcat is building URLs that point back to
itself (e.g. Location: for redirects). If Tomcat is listening on port
8443, then, obviously, port 8443 should be used. But if there is a
reverse-proxy in the way (or some other hand-wavy magic like
iptables), then you want to use the port that the CLIENT needs to use
to get back to you, regardless of the actual port being bound to by
Tomcat.
It's just like setting the virtual host hostname: you can't just
take-over "microsoft.com" by setting your <VirtualHost>'s hostname to
"microsoft.com". But if you don't do that, your users might be sent to
"node-1-6-2-4-6-32-34.binhost.net" which isn't quite what you want.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VH60ACgkQHPApP6U8
pFiW/g//VnCbgnHs/fbsxKANfdIwNGSZP37SEkfLMOzQxBK9eC6nb6LQeWHw5FQd
8yVFVP1LnbvM0ey+UDhWME7Chbm9iyLfpMO09BqAuzcJWopODk9JYQOn0YFJsiVh
kcKeoUGLV1nw4I3qPdh0fjVRV6GDwSpt9XXZvwOZdIbqBUrS+rGuobBDJU5SaA8y
SSVzTYKqoHryJAt7yNiPkulrqpS7rgmiLbm/RvDfF5VFnaYMfh3/Mz7kmBhcvDDC
lkG2+Zs29g/mQ3YyCoKCKLfs0m7bS3WHlxv9qwsZkJzx0Rql2LJ1PSgPnO9vh4VH
LecAk9/6rQGySVuDY4f8r265Gm/jDAn5z+WWT8mv6FsbZZckYbm4f+8DYhxzWjh0
jYJNJf0dOorjjUY7hIQKw9k+QQgBKdufKtfHpDK5u1MIYsC8pdrzyjN9LFl566ad
ESEtlXjnFCzCr9wobi7YJAJLXc9rFsd/IoN988Oui69RIroqZWL6Jjxetj4fDr+8
RiJiTiSl8yWXZuSpkHrQuIrD4eLSpdoOWkrNJOOzDExuJbTpPpFABjapqSrWDEV/
BP0+xAKzeH4RMHLyUciVzw4czRe8DB/0mOBIxSv5z2LXKlef07McFzg8ACOsMCS2
oCG7vXqh7iZbNdB+AKhFs0+TIxJNcBe8bT75t0LF7xgcD0nyXf4=
=67mG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/7/20 7:32 AM, Christopher Schultz wrote:
> Hah, sorry about that. Nobody thought of specifying that only root can
> view the iptables stuff. :)
Not your fault, nor that of anybody else here; I blame the author of
iptables and iptables-save: it should either (a) allow *anybody* to
*see* the information, or (b) *tell* the user that he/she is not
authorized to see it.
While I occasionally use "quiet failure" myself, when writing code to
protect database fields from unauthorized modification, I generally do
so only when it actually makes sense, and the user can actually *see*
that his or her attempt to change the value(s) was quietly ignored.
***
But I'm still puzzled about the "output redirect" specified in the
presentation, but absent from this installation (and yet it still works
just fine). Does the "proxyPort" clause on the connector have something
to do with it "working just fine" without the "output redirect"?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/6/20 4:28 PM, James H. H. Lampert wrote:
> I think I found something, with the help of "MLu" on ServerFault:
>
> He advised me to try "iptables -L" and "iptables-save" again, only
> this time "sudo" them.
Hah, sorry about that. Nobody thought of specifying that only root can
view the iptables stuff. :)
> When I did "iptables -L" under root privileges, I still only got
> column headings, but when I did "iptables-save" under root
> privileges, I hit what appears to be paydirt:
>> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020
>> *filter :INPUT ACCEPT [5018099:5766179544] :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [4555500:2863742410] COMMIT
This means "no filtering". You have a firewall, so that's fine.
>> # Completed on Mon Jan 6 21:17:22 2020 # Generated by
>> iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 *nat
>> :PREROUTING ACCEPT [41828:2351495] :INPUT ACCEPT [76356:4167904]
>> :OUTPUT ACCEPT [254990:18418937] :POSTROUTING ACCEPT
>> [254990:18418937] -A PREROUTING -p tcp -m tcp --dport 443 -j
>> REDIRECT --to-ports 8443 COMMIT
This means that the NAT table is being used to forward port 443 ->
8443 just like we were all assuming, but hadn't yet proven.
>> # Completed on Mon Jan 6 21:17:22 2020
>
> Other than the one obvious line near the bottom,
>> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports
>> 8443
> I'm not entirely sure what all of this means, nor do I remember
> what I did to set it up.
This definitely means that clients can connect to host:443 and will
actually communicate with host:8443. Mystery solved!
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4UpIQACgkQHPApP6U8
pFgHWg/9GkBh1aVeCqqUmKd4l8BcBTrYGCEdVf5FxirWHwWTbmqAY5NYwDPqNOEU
OzOrdbFr6O4tbrcrQGg78pD/ZqhyuwyTKN+NY41/IOFBegbB7ziHyGMNWt81mWbW
n9yYQblEHDkwrdLxu1p6l9DFLsNkWmZxbIE+Ktp8Dyvocv0rfeEh6Ht2jQGOyWKm
m4xhgIc9i9ewGglpRoOwJmfSYuHLs8ijw8CA7owfMz+A3brS4RzreNzLW1nxU7m0
1neLHu2e8AFHw0CPb8NAMt4kC1Rf67wyLbxE2umOPIK16V6yIY96fWmkFNqIlHCl
tiY2oncn6A9jG4r86W2i1MHMEust8a2d/F/bvL5Yjiw26TMr+T5rL/EFU6debTfW
jkFSCS2gFaUM/bBb78d6vQfmpHTj17lP87YK4YJtjQT5/SAXnnty8g7PtOO+jp+W
6gaHYKp1TSYPareexO9NcNd4QM6aWMjMqNgNqiPnggZ6We1Xc+eK7U7kmMpp3hee
7Jggk4oM7G7d8ld1KNW5lRvEGc15E39ZEstFP0UJ78qbHv0ROlh4xoD0lhkW00YB
fC4P4RQE4nwCbDRC7hd2vNPPrSKu6IKo/rwTcGl7yPpi0oX1eTg0AYkaxd2MOTX8
o7NemE0CY01Y65Fev7Yir/WRBxuC1wfuJb1U91t8WblAejQV5bU=
=z5M1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Breakthrough, Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
I think I found something, with the help of "MLu" on ServerFault:
He advised me to try "iptables -L" and "iptables-save" again, only this
time "sudo" them.
When I did "iptables -L" under root privileges, I still only got column
headings, but when I did "iptables-save" under root privileges, I hit
what appears to be paydirt:
> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020
> *filter
> :INPUT ACCEPT [5018099:5766179544]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [4555500:2863742410]
> COMMIT
> # Completed on Mon Jan 6 21:17:22 2020
> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020
> *nat
> :PREROUTING ACCEPT [41828:2351495]
> :INPUT ACCEPT [76356:4167904]
> :OUTPUT ACCEPT [254990:18418937]
> :POSTROUTING ACCEPT [254990:18418937]
> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
> COMMIT
> # Completed on Mon Jan 6 21:17:22 2020
Other than the one obvious line near the bottom,
> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
I'm not entirely sure what all of this means, nor do I remember what I
did to set it up.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with
Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/6/20 9:10 PM, James H. H. Lampert wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly
> brace, and an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent,
> and the -k!)
>
>> curl -k
>> "https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3A
type%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=relo
adSslHostConfigs"
>>
>
>>
> I get curl: (3) [globbing] unmatched brace in column xx
>
> If I change the curly brace to "%7B," I get:
>
>> curl -k
>> "https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%
3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=re
loadSslHostConfigs"
>>
>
>>
> I get curl: (3) Port number ended with 'n'
>
> And if I put the user-ID and password in with a -u clause on curl,
> rather than in the URL itself, I get "Unauthorized."
>
> What is wrong here? Are there characters it simply can't tolerate
> in passwords, even if URL-escaped?
>
> Or do I need to give the manager user an additional role?
> Currently, I have: <user username="foo" password="b?a{r"
> roles="manager-gui"/>
You need another role. The role necessary for jmxproxy is "manager-jmx".
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4Up+EACgkQHPApP6U8
pFjy0xAAmwbNbBSnW5mydxPPSD5OXyJW13wmLtZy2BoMyV5E6HR9wu/u79i27VbI
qfNoIMk3K1wAKNTzuBOtM+cUgXaiFBZeehXuN9lF2AvqiOnp948n3JXrY2JvAovk
Adr3tsx+21nZgNVaVTsEezdKcad+odCRVWER52eVKdnz8In3oh4bWXOEcHQ6T22o
/o+JvQY0kjrRFGMWGHGUu7EvtzM+zawf3RDMuRD2xdhMv3MWhH5o5nrt4DalglUU
qhvZQ5RfVcjMNC43clCjdRhoz7hhCAkf6GTCkqQmVGW0KYP4x8yGxM2NFV0ft8Vc
/DJiy3h3rX6j4lE1c7XXDksUqfPx70h8RJ1ApzcYumXrGxHDUsvYzkuzsGQCBMSF
5qo1lRCgK+qaITNuc9nZIhKdtai3iojjCUr0VNN9+3wI61rNBlncPyIRrNJR2pS7
m6IeML1cKxE7c4sWr7Th4egM+NOX65E4oyv1X6vqpWZYL5TrB2Eys+zcPdG981KI
OF06FybbBW4XDpyv9ECTE9gmtqiw0LYLTz8bg9ytRqOfCgSCmUxVzIc9CTk0glgZ
3AJA8QElFlibnORB7rD1nagDBO4VYmcSXnttHrXf47jjtchWEF+cI24IUUZnbWKb
+yVgFfBJS4mqIIe7IvxYjL2I2bMTx+FWGf7erAm+/WYbMt8DAEE=
=bHGS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
Posted by Zahid Rahman <za...@gmail.com>.
https://stackoverflow.com/questions/17560858/command-prompt-having-trouble-escaping-quotes-and-braces
You can use curl -g to turn off globbing:
On Tue, 7 Jan 2020, 02:11 James H. H. Lampert, <ja...@touchtonecorp.com>
wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly brace,
> and an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent, and
> the -k!)
>
> > curl -k "https://foo:b?a{r@localhost
> :8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
>
> I get curl: (3) [globbing] unmatched brace in column xx
>
> If I change the curly brace to "%7B," I get:
>
> > curl -k "https://foo:b?a%7Br@localhost
> :8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
>
> I get curl: (3) Port number ended with 'n'
>
> And if I put the user-ID and password in with a -u clause on curl,
> rather than in the URL itself, I get "Unauthorized."
>
> What is wrong here? Are there characters it simply can't tolerate in
> passwords, even if URL-escaped?
>
> Or do I need to give the manager user an additional role? Currently, I
> have:
> <user username="foo" password="b?a{r" roles="manager-gui"/>
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with
Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
Dear Mr. Schultz, et al.:
The manager password on this Tomcat server has an embedded curly brace,
and an embedded question mark.
If I do this (the names have been changed to protect the innocent, and
the -k!)
> curl -k "https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
I get curl: (3) [globbing] unmatched brace in column xx
If I change the curly brace to "%7B," I get:
> curl -k "https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs"
I get curl: (3) Port number ended with 'n'
And if I put the user-ID and password in with a -u clause on curl,
rather than in the URL itself, I get "Unauthorized."
What is wrong here? Are there characters it simply can't tolerate in
passwords, even if URL-escaped?
Or do I need to give the manager user an additional role? Currently, I have:
<user username="foo" password="b?a{r" roles="manager-gui"/>
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/6/20 13:05, James H. H. Lampert wrote:
>> $ host foo.bar.net
>>
>> And check the IP versus the IP of the Tomcat node?
>
> Doing a "host" on the domain gives me the same IP address where
> the instance itself lives, which is also the address given in Route
> 53.
I think Route 53 always uses a load-balancer, doesn't it?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TiowACgkQHPApP6U8
pFgiGw//bFJf2zl+A2FEDHl/vnFycLaW0VqzAkFtoG5Rwbzhim6788qTruJmzcR1
Bs/zmOVTJeoj7B8KQhmpO3+T6QLn+lrQ/Ik+AqBSZRAfTFcHEgeGQWrD8MuPadqI
vzu7VdDKI5QwPVzPoJPzf6UKb2cQgOrn7PP08wpvcm97UCKATXyYS6T2KsGqpo6x
nXL9BKcGcCYTDlkSK2V8f0wNLpocTVPnshm33eZz/EK6CLPbcj0A7lHBg7JscQlR
Ax7prdjhD80nY+4wK9rs9nZL5JTttrKzS+CXhECJPncGE8lswTWuIvmSFqdowZfw
biv6KJkiZlAdPzZthRWymt46njJzHumG7CY5WANU/Y3QezSCNmcXjG8VY8W3gWjS
sMM3+tPOcnRIHX5cJGswo+0QImhQCdxmZVKBt2imaXhvLUAyzDMi6NT3RyHWQxT2
kwmqJpmPurL3UAWeZslICAqjFPql6ADeLIoXgRdIxvYD0FAKBemz220FNaG8/Dil
hkitBAZf0dkdPfIYM3xLS5J2XoWxIcni3BZKXCeYYCC4sHth3SbT596N4KXeJamm
NUxQh5baPydZ38CmOtcnYiy2r4j/jz20B2VaPtp67jHtBtelmFx+yaVZvNHwxZ7V
tUJLvzwbcwGNMq+T2uxXM+NvDx65ruQHENtvp1lZepT2m/yCjdM=
=pf56
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
> $ host foo.bar.net
>
> And check the IP versus the IP of the Tomcat node?
Doing a "host" on the domain gives me the same IP address where the
instance itself lives, which is also the address given in Route 53.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/3/20 13:47, James H. H. Lampert wrote:
> On 1/3/20 9:57 AM, Christopher Schultz wrote:
>> Is perhaps the AWS firewall (which is a Load Balancer, right?)
>> redirecting the port?
>>
>> Easy test (from the server):
>>
>> $ telnet localhost 443
>
> I hadn't thought of that. But alas, that instance doesn't have
> Telnet on it.
>
>> If it connects, you have something on the host making this work.
>> If it fails to connect, the 443 -> 8443 magic is outside the host
>> itself.
>
> If, however, I do curl https://foo.bar.net from my Mac, I get a
> response, but if I do curl https://localhost, it doesn't get
> anywhere.
So your instance is indeed listening on 8443 and the host (at least on
the loopback interface) isn't doing any port 443 funny-business.
>> Note that if you are using AWS load-balancer, AWS provides free
>> certificates that auto-renew; just configure them and you are
>> done forever.
>
>> Let me know about the Load-Balancer. That's probably the piece of
>> the puzzle you aren't looking at quite yet.
>
> No; we *have* load-balanced clusters, and they *are* (as of last
> month) on AWS's certificate system, so I know what that looks like.
> This is completely different; when I connect, I see the certificate
> that is currently active on the Tomcat server (and if I plug a
> different cert into Tomcat, I see the change from my browser).
There are also load-balancers that just move bytes and don't terminate
TLS. It's also possible to have the same certificate installed in
multiple places. I think you are going to have to look around your
network a little more to figure out what's happening.
Maybe simply try:
$ host foo.bar.net
And check the IP versus the IP of the Tomcat node?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TSsMACgkQHPApP6U8
pFgvHw//fBItKsqFiCNeA5lLwo6hi6tZaZY6BxC24SQfMPFe4TaQKkvl/ziGdvpc
E7afIiahzkksZ5Afeq08xx5yE16XVWNDfXy005x5TjosK9tq+msYQU0RUXiHolPo
iTNMfVAi7vHx4OYciJzDzV34vb8pF4Xl4AlMj/ESh38BUPsZWQtcpzmMi9Nf9+/q
grQonVVKHBIydBSbygpiHBGcPesJX0kRUtpArVIWJZdw+V+lKApeo32Xw1Y+Dm0q
1knwGFzHYGdxROCCpez8dq83ABI5l4tmVMPYpTZsTxBrebZxXxy2GUfrRHTH8UaC
E1ew1jHhYwyPWIUQjEAWynKqVZ8OFcBlRN3DwFvNCGMyd5c9vyE50qfRwzYqeQMk
tEnNafRgWGdsiw0El79m6Xl3LVOd9psSYTgvobqICPk27YhPbpk7izR5td2stvxu
wnmfgxBJd9lL/ckwkvQfKgsdQSnCx8ULJgNUWyCv/gKrhBuBK1gkRrHj3MbJM5Cf
A7fquztvXVZdTnAuEBLvAhKdmIYX6k7W/TnX1kvJcBQ0AN1WhcbmnxQhcww2bn5s
LB2VA91XKg8BaNItodEx03EsUEpbjIvxmnBoCbTgYxcVaKs76qxzP9DENZmGNV/b
JTSEo7xAyGnRQ42l4pm1Lxj/8kAZLrZ5VfNK2DBmmDTeZ8eCUAI=
=372g
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 1/3/20 9:57 AM, Christopher Schultz wrote:
> Is perhaps the AWS firewall (which is a Load Balancer, right?)
> redirecting the port?
>
> Easy test (from the server):
>
> $ telnet localhost 443
I hadn't thought of that. But alas, that instance doesn't have Telnet on it.
> If it connects, you have something on the host making this work. If it
> fails to connect, the 443 -> 8443 magic is outside the host itself.
If, however, I do curl https://foo.bar.net from my Mac, I get a
response, but if I do curl https://localhost, it doesn't get anywhere.
> Note that if you are using AWS load-balancer, AWS provides free
> certificates that auto-renew; just configure them and you are done
> forever.
> Let me know about the Load-Balancer. That's probably the piece of the
> puzzle you aren't looking at quite yet.
No; we *have* load-balanced clusters, and they *are* (as of last month)
on AWS's certificate system, so I know what that looks like. This is
completely different; when I connect, I see the certificate that is
currently active on the Tomcat server (and if I plug a different cert
into Tomcat, I see the change from my browser).
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Let's Encrypt with Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 1/2/20 19:45, James H. H. Lampert wrote:
>>>>> Am I to understand that Tomcat 8.5.40 can use the ".cer,"
>>>>> ".ca.crt" and ".key" files directly, instead of the Java
>>>>> Keystore file?
>
> On 12/30/19 1:41 PM, Peter Kreuser wrote:
>> Correct!
>
> Great. Then if I can figure out how to get this thing
>
> I'm studying the server under discussion, and I can't figure out
> what I did, some six months ago, to make Tomcat look like 443 to
> the outside world.
>
> Here is what I do know: * It's an AWS EC2 instance.
>
> * There is no load balancer involved.
>
> * The only active connector in server.xml has it listening on 8443,
> with a proxyPort clause specifying 443.
>
> * If I do a netstat, I find that something is indeed listening on
> 8443, but nothing is listening on 443.
>
> * If I look at the AWS console, if there is something translating
> 443 to 8443, I can't find it.
>
> * If I do an "iptables -L," I get only column headings.
>
> * There are evidently two copies of Apache httpd on the box, one
> of which evidently came with the OS, and the other of which
> evidently came with the Bitnami SVN/Trac stack. Only the latter
> copy is active. It is listening on ports 81 (unsecured, but blocked
> by the firewall) and 8000 (secured).
>
> * If I open port 81 up to my own IP (in the AWS firewall), I can
> reach the same SVN/Trac landing page on unsecured port 81 that I
> can on secured port 8000.
Is perhaps the AWS firewall (which is a Load Balancer, right?)
redirecting the port?
Easy test (from the server):
$ telnet localhost 443
If it connects, you have something on the host making this work. If it
fails to connect, the 443 -> 8443 magic is outside the host itself.
Note that if you are using AWS load-balancer, AWS provides free
certificates that auto-renew; just configure them and you are done
forever.
Also, AWS will happily connect to an EC2 server with a self-signed
certificate, so there is no need to use Let's Encrypt for your
host-specific certificates. Just generate a long-lived self-signed
certificate and you are done for a while. You are still welcome to
rotate your certs as often as you'd like. The only reason to use Let's
Encrypt is if you want OTHER clients to trust your own certificate.
> * Tomcat is running completely independently of the active httpd:
> if I shut down the active httpd, Tomcat still responds.
>
> * I was able to find the apache VirtualHost configurations (in a
> file called bitnami.conf, naturally), and by replacing the one for
> port 81 with (and once again, domain names have been changed to
> protect the innocent):
>> <VirtualHost _default_:81> ServerName foo.bar.net Redirect
>> permanent / https://foo.bar.net:8000/ </VirtualHost>
> the unsecured Port 81 now redirects to 80. Conversely, if I leave
> out the :8000 it redirects to the Tomcat server.
>
> * Like a complete and utter idiot, I left no notes whatsoever about
> how I set this thing up in the first place. Probably because I
> didn't fully understand what I'd done, or how.
>
> * Just as it was when I *was* setting this thing up in the first
> place, httpd configuration files (that can be all over the place)
> make me long for the simplicity of Tomcat configuration files.
>
> I *think* I can *probably* get Apache (and a cron job running
> certbot) on Let's Encrypt, and Tomcat using its certs (and a cron
> job reloading them), without understanding what I'd done to get
> Tomcat showing up on 443 to the outside world, but it would be nice
> if I *did* understand what I'd done.
Let me know about the Load-Balancer. That's probably the piece of the
puzzle you aren't looking at quite yet.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4PgIEACgkQHPApP6U8
pFgvtg/8DPjUrMAsW6oreNhOK1Aj4GmKgZHUJZsW/RBkgg5CTvwiFnVAxfAF3SP6
0Lill24qp9ZGvoq3FQC9sKu68N7nQCfSbNn6D54by7YscAtAL42puUxOPXOTDlLl
sG0fHbZA6YAYuoVprpT5LuVODwSu13v9rOtCKJWZROWymKTuUf3C8oZgo2aYc/PS
FScWwcGbtPgkgO7tuOY9QsmuJMqOj73Z1lq86voU9cW0PCH8cik/Wp2iS+30XbRH
c+J+Yirie7WrDa7wVRBPm76sDGSmmyRy+DeR9dwuzFiixQOdsuP/Lsgp/2y+rc+M
VbBCiPWy/pS+kcJWP7R3JtfujgZzyyqkuTL/AlTnhW2OykNSoCzHHUgnTYcDdHps
udxUih+o5fikT5kJvxglvTECaY9QbizXN84Uy6S5rGCB2LMZtlDShTnF0cx+v2y1
zagbC1/5TDedGTCISqpCRu+RliuyvmPvUs8NoxgtIEvg5cqVOoVdaL9tLHZ+UxVC
0wLoboMdneyn0yEF5fe4ySefW7Do8pAyBNRJLpYg0wuQC3Q6j5Kv4CUAUOazrEyK
/AlxrhM3Zg82EecbjgfzNbq87vSQnQvosALCVvqcylC1TtWUaE1WWPhy+0hxo8y+
PVuw4KSg2BZnn2kCMlBLVNWOREDl8tTdZDfX7ASf8xaCdZx8LiE=
=ITNd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org