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 > <ch...@christopherschultz.net>: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > James, > > On 12/27/19 17:07, James H. H. Lampert wrote: >>>> As it happens, one way or another (and I'm not entirely sure >>>> *which* way; I'd have to look at my notes), we *do* have >>>> Tomcat listening directly on 443 (but not 80; nothing there is >>>> currently listening on 80) on that particular EC2 instance (and >>>> I'm pretty sure we have HTTPD running on a *different* port, >>>> for the SVN and Trac sharing the box). >> Hmm. It seems I was mistaken about two things: (1) that the Tomcat >> server under discussion is listening *directly* on 443, and (2) >> that I could find my notes on how I set the box up. >> What I can find is the server.xml file, and the active connector >> definition: >> <Connector port="8443" proxyPort="443" >> protocol="org.apache.coyote.http11.Http11NioProtocol" . . . >> clientAuth="false" sslProtocol="TLS" /> >> The thing that catches my eye is port="8443" proxyPort="443" >> I hope that indicates how it is I'm getting this to look like port >> 443 to the outside world, because I honestly can't remember what I >> did (even though it looks like it's only been six months since I >> did it). > > This means that you are listening on port 443, but when Tomcat builds > URLs for redirection, etc. the port 443 will be used (and, actually, > as likely secure="true", then the port will be omitted because the > default port for https is 443 of course). > > There is no proxying going on in Tomcat; this configuration is named > for the use-case: you must have a reverse-proxy somewhere which is > terminating TLS (and likely re-establishing a separate secure link > with Tomcat, since sslProtocol="TLS" in your config). It's probably a > load-balancer which is essentially synonymous with a reverse-proxy in > this context. It's possible to have one without the other, but they > are often performing both functions. > > netstat on *NIX should give you the IP(s) of the clients, so you can > probably pretty easily see the IP address of the reverse proxy. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4KSWsACgkQHPApP6U8 > pFhgpA/+PVIwacQPcjbaHMPwEz+JfVMzZubjzQDxM6u0gSRTpH3z8PRHPvm/DPZN > FJhNHEZhpbdXVA5ypsg5LIHShqIOh716Rp/mIObIWn2Z+NK2x5uLytBhIOt6w1fZ > Qsqy4f+jFUesRp3Y5/wWu6plIvB5y3c+RzGVt7Q4fX5XKTMKuP5DueHC57qaY6LL > V28qwyRQCBPMJV89pb3rKICzQEf8uSCVFjV/xKU7/0IamHKh3MfVXrUikFJB8/ex > CiHLsmc2FGSxERHvHOPxnKaGA/EFa3Lu3p0VrdSbczsmtS/cCmlrBUz0pmcqQLQ/ > wm0OOfQ2aTvU42E0E3bgc014dOsrC2zugrjGNrZTQqyCXbBN065iZoi9RT3Hl8vN > lAfS83rF0E4eTNlB2E3qRZTFVGPSaNS5MPnl4RXC8F9c2/vukIY0Xb9DWi4Hf6f+ > 8tSZHer24uD8nR928p78mbiqoI1NMZaM9CwIN0XhJzjb2XzhZF9pgfmjAvbdV8vo > AtWauUHw1BictxXdVtmZ2xY3dYsK0RDPqX/K9u053rPOfweYTCCVn5lcRUzhITmr > sf8pP/8vRiXQAIyH0JjvCXJIUIIJGo7xofJQcs2RPA8qt+aukQC3OpB7UdpKOHv0 > P/7zx+mWDyCH5A9fIfT16H6kgRfxoyUi19X6pFMPuzXNpiZP2zU= > =9vaq > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-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
