Using Let’s Encrypt to acquire widely accepted SSL certificates for my hosted sites and services before it was enough to just run
/letsencrypt-auto certonly --webroot
to validate access. Under the hood, the toolchain would create an acme challenge file in a directory called .well-known located in the servers web root directory. With the servers new proxy however traffic would be redirected to the calendar service who serves up a different content than our web root and in turn the tool would fail to verify access to the domains.
The fix is fairly robust: If we look at the last line of the proxy configuration file
/Library/Server/Web/Config/Proxy/apache_serviceproxy.conf it looks something like this:
That means that we can create custom configurations that would not get overwritten every time we use the server.app to change any configuration!
I created the following file
and it contains the following content:
ProxyPass /.well-known/acme-challenge http://127.0.0.1:34543/.well-known/acme-challenge
ProxyPassReverse /.well-known/acme-challenge http://127.0.0.1:34543/.well-known/acme-challenge
This should let the proxy server instance pass all access to the acme-challenge folder to the apache instance hosting my websites where access to the .well-known folder still redirects to the calendar server.
The proxy server is not exposed through the server.app UI and doesn’t restart together with the Webserver instance. One can restart the proxy through the command line though by issuing the following commands:
sudo launchctl stop com.apple.serviceproxy
sudo launchctl start com.apple.serviceproxy
Now Let’s encrypt should be able to access the acme-challenge folder in the .well-known directory and the calendar service should still be able to rely on his portion of said folder functionality. 01/12/2016