-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 James,
On 4/6/20 15:53, James H. H. Lampert wrote: > Here is the situation: > > We have an existing Amazon EC2 instance, running Amazon Linux 2, > with an Apache httpd server already running our web sites (for > argument's sake, "foo.com," "bar.com," and "baz.com."), and already > getting its certs from Let's Encrypt, using "foo.com" as the CN, > with "www.foo.com," "bar.com," "www.bar.com," "baz.com," and > "www.baz.com" as SANs. And it seems to be working quite nicely. > > Now, we want to add a Tomcat server, which would then serve > several webapp contexts at "qux.baz.com," and maybe also > "corge.baz.com," running behind the httpd server (which is > something I've never done before; I've always set up Tomcat > directly facing the outside world, so with this, I frankly haven't > a clue what I'm doing). > > First of all, which is currently considered the easier/better way > to get Tomcat running behind httpd, given the above scenario? > "mod_proxy," or "mod_jk?" Or is there something else I haven't > heard of? > > Second of all, I found this step-by-step procedure. > >> https://preview.tinyurl.com/vwnutqj > > Is it any good? > > Third, am I correct in assuming that all we need to do in order for > the existing Let's Encrypt setup to cover the new "qux" and > "corge" subdomains is to add them to the SANs already listed? > > Finally, are there any "gotchas" I need to be concerned with? I've just read through your saga thus-far, and I have some comments that I hope will help you with your efforts. First of all, definitely use mod_proxy and definitely use mod_proxy_http (and not mod_proxy_ajp). Once you have made those decisions (or had them made for you), it should be as simple as this: 0. DO NOT TRY TO USE YOUR PROXY TO RE-WRITE URL-SPACES If you have an application hosted on Tomcat in /foo then map it to /foo on the proxy. If you want it on /bar, then re-name the darned thing on the Tomcat side so it's got the context-path you want FIRST, then map it through the proxy. To do otherwise is to descend into a whirling maelstrom of unending pain and torture, and you'll get nothing but "change your application context-path" responses if you ask for help "fixing" your configuration so it works. 1. Configure your Tomcat connector <Connector port="1234" protocol="HTTP/1.1" [etc] /> 2. Configure mod_proxy to act as a proxy ProxyRequests Off # this is to disable forward-proxying (!!) ProxyPass /context1/ http://localhost:1234/context1/ ProxyPassReverse /context1/ http://localhost:1234/context1/ 3. Celebrate There are a bunch of other things you can do, too. Some additional thoughts: 4. If localhost, use http; otherwise, use https. This requires a TLS cert, which may be irritating to accomplish with an "internal" host. Note that httpd isn't terribly picky about the signature on the TLS certificate of the origin server (Tomcat), so you can self-sign if you'd like. 5. Without additional configuration on the Tomcat side, you'll find that your access logs tell you that all visitors have the same IP address (surprise! it's your reverse-proxy!). Have a look at the RemoteIPValve[1] to get that all fixed up. 6. If you have your static content files on the web server, you may be able to improve performance a bit by NOT proxying requests to the static content. Be very careful with this: you probably do NOT want to: Alias /context1/ /var/tomcat/webapps/mywebapp/ ProxyPassMatch /context1/.*\.xml ! With that configuration (which may be invalid; it's just an example), any remote user can read your application's WEB-INF/web.xml file. Or whatever else you have laying around. Make sure you secure your disk-files from the incoming URL space. 7. Adding more origin servers requires a slightly different configuration. It looks like this: <Proxy "balancer://context1"> BalancerMember https://host1:1234/context1/ BalancerMember https://host2:1234/context1/ [etc] </Proxy> ProxyPass /context1/ balancer://context1 ProxyPassReverse /context1/ balancer://context1 If you intend to use a load-balancer, you should make sure you read all about the various parameters for the balancer members (like timeouts, live-checks, ttl, etc.) to maintain a sane configuration. I hope that helps, - -chris PS If ApacheCon NA happens this year, I'm expecting to give a talk on migrating from mod_jk to mod_proxy if anyone if interested. [1] http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valv e -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6Poj8ACgkQHPApP6U8 pFghpA/8DP8tbNTzoOC12dg1D3JxI9QFEB1psXv8yZcqhNzYy5fr7iWm9aWAQJYC j5TuBD4lbp3dR2jzjVFu7BKUDX/vwLdqQyZ3+EedBZQbMia5sq4tHDxce9oOzC52 nrAcJfvISuMVcfY6UE6VfYTIaRCO4V3GdRo2r0d2E6+tjnZxYYyIu8HsORZy7BRK +NVRJOUllbNVM13F7SqCE+JnOqO+v718Suj6ClxwiIDaXwb0POKr9YZgdapeiuYX k/OMf9iyf74+3IW2Aub4b8/ufT53jrr/LYcn24aQzt+n2lxzoe9bZcAMkDevNjSN Ymjo70kjlxJbck38eRm3P6HXEPW2Jru41bHhjnXrfzXcSkVECWBLzvHekXIWZ+Tk RCd3i8XtJ42D3G6GN8XOy+ocRQ7+kDMBKSCh8JU3Kbd9F9N0MrpQC0TaXaEyr/vD CH5z/r9a9mJ5+hRwbGsEcgpwOyE5xA3BNc7eBRynVCDmV1yglr0j2tyFl3QBHvr+ QmYNU/lOevefcJPEs7j7PmuzNaH/V8E6ij/2bkXJYcLiUlb0zeGlTq6n0gbc4AeU /El1yCMYnE0BSKQ3N+ezN6j2DfLDcLp0/GV1zbS/XwA7G+S16sfxec3Zyhok848g K8wk8oumnfQExK1dKaQ/MUGUvZQxN2GQGKDb9DU06v4mPZctvcA= =5OZf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
