First off, “thank you!” to EFF & the Certbot team for making this available, it’s truly appreciated!
I’m trying to work out how to make Certbot work when the web server is on one VM (acting as a “front end” so to speak), & various subdomains are redirected to other VMs running Tomcat & Liferay. My boss has told me that the front-end VM should be the one running Certbot - for all domains. (It’s probably worth noting that I was able to get it working with Certbot running on the subdomain VMs.)
Our setup is as follows:
WWW server (CentOS 6.9 & Apache httpd 2.2.15-60.el6.centos.6)
App server (CentOS 6.9 running Apache Tomcat 7 and Liferay Portal Community Edition 6.2)
Hosting provider is Digital Ocean, yes to root login access, no use of any control panel.
I’ve spent a good bit of time reading the documentation before beginning this post, but I haven’t found anything that addresses this one (two-part) question -
Is it possible to make Certbot work when running on the front-end web server for domains that are re-routed to “secondary” servers? And if so, how??
(I would prefer not to use the DNS challenge, only because our DNS is hosted by a separate provider whose interface is distinctly NOT automation-friendly.)
If you're forwarding or redirecting connections in some other way, the advice to run TLS on the front-end VM might be less relevant or less applicable.
While I’m still learning the details of our setup here, I believe that your guess is correct. I do know that SSL is terminated at the “front-end” Apache (www) server.
I am currently looking at specifically defining a ‘.well-known’ directory within the config for each subdomain that will not be redirected to the various application back-end servers, but will live on the WWW server instead - from what I can see, that seems to be the most-efficient way to accomplish what’s been requested. Doing that might very well be outside the scope of this ticket, but if you have any suggestions/pointers, I’d be glad to learn of them.
If you’re using a recent version of Certbot, you may be able to accomplish this automatically with certbot --apache even though the rest of the content of the web sites is proxied to other servers.
However, if not, or if this doesn’t work, you can try to exclude /.well-known/acme-challenge from the proxying and serve it from a particular location on disk (which could potentially be the same for all of the subdomains); then you can specify the directory that contains that location with -w when using certbot --webroot.
I believe it is well within scope.
If all the names on the cert (be them one or many) resolve to the same IP, then they will all go through the "front-end" and actually never hit the "back-end".
That is, from a client perspective, there is only one site.
All TLS/SSL connections will be passing through that one system.
So you only need to run certbot on that one system and can even combine all names onto the same cert.
Unless you will be providing links to alternate ports which will be bypassing the "front-end" and hitting "back-ends" directly, this is a straight-forward reverse-proxy setup.
Yes, you can exclude the /.well-known/acme-challenge/ requests from being proxied so the "front-end" can respond and pass the challenge.
Something like this should work when included above your ProxyPass line: ProxyPass /.well-known/acme-challenge !
@schoen, @rg305, thank you for the replies! I haven't responded before now because I've been trying to work it out myself without getting the answer "spoon-fed" to me...
I tried to use the --apache "module" but it was unsuccessful. IIRC, it returned the 'unauthorized' return code that indicates that it was unable to write to the directory.
I'm trying to exclude the .well-known directory from the proxying, but currently getting a 404 back when I try to access the .../.well-known directory. (I'm using a custom index.html page for confirmation.)
The proxying is being done via AJP, the relevant line (JkMount) just sends everything to the worker process. I've tried adding the line
JkUnMount /.well-known/* worker7
immediately after the JkMount line, but that wasn't successful. FWIW, I've also added the following in the "conf.d/subdomain.tld.conf" file:
Alias .well-known /var/www/SUBDIR/.well-known
<Directory /var/www/SUBDIR>
AllowOverride None
Order Deny,Allow
Allow from all
</Directory>
If all fails, try using: --webroot -w /var/www/SUBDIR
Which should point http://your.site/.well-known/acme-challenge/1234
to /var/www/SUBDIR/.well-known/acme-challenge/1234
[you can even create the folder/path structure ahead of time and place a test file there to insure that this method will work]
If all the names on the cert (be them one or many) resolve to the same IP, then they will all go through the “front-end” and actually never hit the “back-end”.
That is, from a client perspective, there is only one site.
I'm pretty sure that's what we're dealing with - I know that the different AJP workers utilize different TCP ports, but as far as accessing the various subdomains, it's not necessary to specify a port number.
Also - I saw your suggestion to use 'ProxyPass' - how is that more appropriate the 'Alias'?? (I'm not being critical, just trying to understand.)
If you can run this with --debug-challenges , Certbot will pause after modifying your Apache configuration with the challenge response.
If you can copy paste the modified virtualhost at that moment and post it, we could take a look at why your particular combination of mod_jk and Certbot's Apache authenticator doesn't succeed..
(I think you can also run with --debug-challenges -v and the modified virtualhost also should get written to /var/log/letsencrypt/letsencrypt.log).
Thanks again for the replies everyone. I’m at the point now where I can browse to both the .well-known directory and the acme-challenge directory, & I can view the sample index.html file that I created as an aid for testing, so I’m going to call this issue resolved, & allow this ticket to close. (I’m now trying to work through a couple of separate issues which I’ll create a new ticket for, so as not to “muddy the waters” for anyone else with this same issue.)