(Or, letsencrypt macOS Server if you prefer)
I have been using CACert as my free SSL certificate for some time now, and it’s fine, with one exception—CACert root certificates are not trusted by default by many systems, including most significantly, iOS and Andriod. That in turn means that I can’t retrieve email off my home server from a company provided iPhone, since the company mandated security profile demands SSL authentication.
Letsencrypt aims to address this problem (among others) with their free certificates, which are trusted by Android and iOS. However, Letsencrypt uses a highly automated system (to make things easy for the user) which originally did not support OS X (macOS).
I recently decided to revisit Letsencrypt and have indeed managed to get it to do what I want, albeit with some interesting discoveries along the way.
Measure Twice, Cut Once
Since I did not wish to blow up my existing home server, especially the current certificate, I decided to test things out in a Parallels virtual machine. So, I duly fired up Parallels and started a clean install of El Capitan.
Other things can go wrong
It failed. It said the installer image could not be verified. So I tied a backup image, and got the same result. So I tried a Yosemite install, and it failed with the same error.
A little research showed a possible reason, so I tried resetting the clock, but to no avail. Then I had a light bulb moment. The page says “the date must be correct in order to install OS X, specifically the year, because if the date set is prior to the release of OS X, the error will trigger.” It turns out that it’s important not only that the date not be too far in the past, it can’t be too recent either. In particular, the current date is too recent to install older releases!
The solution is to decouple the clock from the Parallels virtual machine (Parallels will keep the virtual clock synchronised to the real machine’s clock) and then set the date back a year or so to a little after the release of the relevant operating system. Voilà! It installed.
I then ran the certbot certonly script in the VM and, after a little fiddling, got things installed.
The Real Thing (with the fiddling done)
The certbot page for Apache on OS X shows how to create the certificate for OS X. It doesn’t work—or at least not on OS X Server.
The problem is neatly explained in the file /Library/Server/Web/Config/apache2/httpd_server_app.conf in the comments at the top:
#
# macOS Server
#
# When macOS Server is installed and set up (promoted), this file is copied
# to /Library/Server/Web/Config/apache2/httpd_server_app.conf. Both macOS
# and macOS Server use the same httpd executable, but macOS uses the config
# file in /etc/apache2.httpd.conf while macOS Server’s Websites service uses
# this config file.
#
The $ certbot –apache command works on the file in the macOS config file, not the macOS Server config file.
The solution is to use the $ certbot certonly command, and then select webroot, as follows:
Place the files in /Library/Server/Web/Data/Sites/Default
Import the files into Server’s Certificates and all is good.