Like many of you, I was dismayed to see that Apple has decided to effectively abandon the macOS Server app that I used to set up my simple static web sites. Once one updates to macOS Mojave, most of the features of the Server app are just gone, and one is left to fend for one's self in a maze of twistly little forum posts, all different, trying to figure out how to get things working again.

My use case is relatively simple: I'm not trying to run a mail server, or a wiki, or any sort of fancy active web content like WordPress and the like. I just had a giant pile of static content -- photos, mainly -- that I wanted to keep hosting with a minimum of fuss. (Most of it is of no interest to the public, but you might enjoy some high quality images of the Charters of Freedom.) I thought: surely, somebody somewhere has written a simple step-by-step guide for how to deal with this. And probably someone has, and I just wasn't able to find it. In the meantime, in the hope that the next poor schmuck who finds themselves in my shoes can benefit, here's a discussion of what I've done to get my static site working well again after updating from High Sierra (macOS 10.13) to Mojave (macOS 10.14).

The warning given by our MacStadium friends here if anything understates how much of a nuisance this update will be. I recommend doing a test run on an entirely separate and expendable Mac before you try updating any machine you care about. If you have a less expensive Mac like mine without solid state storage, be prepared to be off-line for at least four hours. Just installing Mojave and the subsequent updates will take that long.

That said, here is a step-by-step guide showing what worked for me. I hope you find it helpful. If it breaks your Mac, you get to keep both pieces: no warranty is express or implied.

• Review the information provided by Apple here. I only needed the section on Websites, which I found to be incomplete and rife with errors. Still, it's a starting point.
• Uninstall Xcode and the command line tools, if you happen to have installed them on your Mac. I didn't, and got stuck in an endless loop where my updated Mojave system insisted that it needed to update the command line tools... over, and over, and over. That process eventually ended with a command-R reinstall of the OS and another four hours down the drain. See here for some suggestions that may help.
• Back up your whole machine, especially the contents of /Library/Server. You might need them later.
• Use the macOS Server App one last time to turn off your web sites. Sigh.
• Install the update to macOS Mojave (10.14) and then the update to the latest point release (10.14.1 at the time of writing.)
• Install the Command Line Tools for macOS 10.14, last updated on November 2, 2018, and available as a convenient .dmg file here. You might need to register as an Apple Developer to access that .dmg, I'm not sure. If that doesn't work, you can also try running the command xcode-select --install from a terminal window; that didn't work for me, although it has worked fine for me with older macOS releases.
• Install Homebrew, following the instructions here. Homebrew will try and install the Command Line Tools from the previous step for you if you haven't done so already, but it often fails for one reason or another. Just install the Command Line Tools manually, first.
• Install certbot, the EFF's ACME client so that your new websites can use https in addition to http. Do brew install certbot from a terminal window.
• Using your favorite text editor, update /etc/apache2/httpd.conf and /etc/apache2/extra/httpd-ssl.conf. You can see my httpd.conf and httpd-ssl.conf. No doubt a clever mean person will take one look at these files and use them to p0wn my machine. If you're a clever nice person and see that I've done something horribly stupid, by all means drop me a line at adam.greenblatt at gmail dot com and let me know, thanks.
• Use your favorite text editor to create /etc/apache2/sites/sites.conf, where we'll store information about all of the web sites being served from our Mac. (You could just as easily use a separate .conf file for each site, but I find it to be more convenient to have everything in one place for ease of editing. Your mileage may vary.) Here's an excerpt from my sites.conf file that shows how I set up the nara.cyclecounters.org site mentioned above.

  # When letsencrypt tries to create your certificate, it will use plain
  # http to fetch some magic URLs that certbot will create for you behind
  # the scenes in the ".well-known/acme-challenge" directory.  This proves
  # to letsencrypt that you control the domains you're getting certificates
  # for.  The first "RewriteRule" below uses a "-" to do *nothing* to those
  # special letsencrypt requests, passing them unaltered through to the
  # (normally not present, but created temporarily by certbot) directory
  # /Volumes/4M1/adam/sites/nara/.well-known.
  #
  # All other plain http requests to nara.cyclecounters.org are rewritten
  # into equivalent requests to https://nara.cyclecounters.org by the
  # second RewriteRule.  As a result, the DocumentRoot and Directory
  # for this host aren't used for anything else -- we only need them
  # when getting or renewing certificates.
  <VirtualHost *:80>
          ServerName http://nara.cyclecounters.org:80
          RewriteEngine On
          RewriteCond %{SERVER_PORT} 80
          RewriteRule ^/.well-known/(.*) - [L]
          RewriteRule ^(.*)$ https://nara.cyclecounters.org$1 [R,L]
          DocumentRoot "/Volumes/4M1/adam/sites/nara"
          <Directory "/Volumes/4M1/adam/sites/nara/.well-known">
                  Require all granted
                  Options All -Indexes -ExecCGI -Includes +MultiViews
                  AllowOverride none
                  <IfModule mod_dav.c>
                          DAV Off
                  </IfModule>
          </Directory>
  </VirtualHost>
  
  # This second virtual host redirects anyone still using
  # http://www.nara.cyclecounters.org to the equivalent
  # http://nara.cyclecounters.org URL.  We don't need any trickery
  # for certificates, since certbot will use different temporary
  # filenames in /Volumes/4M1/adam/sites/nara/.well-known/acrme-challenge
  # when establishing that we control both www.nara.cyclecounters.org
  # and nara.cyclecounters.org.  (We could, in principle, share the
  # same ".well-known" directory among all sites on the machine if
  # we wished.)
  <VirtualHost *:80>
          ServerName http://www.nara.cyclecounters.org:80
          RewriteEngine On
          RewriteCond %{SERVER_PORT} 80
          RewriteRule ^(.*)$ http://nara.cyclecounters.org$1 [R,L]
  </VirtualHost>
  
  # We can't just start creating virtual hosts that use SSL until
  # we have valid certificates, but we need to serve something to
  # get the certificates in the first place, creating a chicken-and-egg
  # problem.  We work around this by first disabling ssl in httpd.conf,
  # which turns off these two virtual hosts since the IfModule will no
  # longer be true.  Then, once certbot has installed the certificates
  # (recall that letsencrypt will validate using plain http, not https),
  # we'll re-enable SSL in httpd.conf and restart apache.  More on that
  # below.
  <IfModule ssl_module>
          # This third virtual host redirects anyone using
          # https://www.nara.cyclecounters.org to the equivalent
          # https://nara.cyclecounters.org URL.  No trickery here,
          # but note that apache requires a valid set of SSL directives
          # here -- the redirect will be properly encrypted, so folks
          # using https://www.nara.cyclecounters.org should still be
          # safe from eavesdropping.  When we create the cyclecounters.org
          # certificate, we request that certbot make the one certificate
          # valid for both nara.cyclecounters.org and www.nara.cyclecounters.org
          <VirtualHost *:443>
                  ServerName https://www.nara.cyclecounters.org:443
                  RewriteEngine On
                  RewriteCond %{SERVER_PORT} 443
                  RewriteRule ^(.*)$ https://nara.cyclecounters.org$1 [R,L]
                  SSLEngine on
                  SSLCertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/cert.pem"
                  SSLCACertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/fullchain.pem"
                  SSLCertificateKeyFile "/private/etc/letsencrypt/live/cyclecounters.org/privkey.pem"
          </VirtualHost>
  
          # Finally, the fourth virtual host has the actual content of interest.
          <VirtualHost *:443>
                  ServerName https://nara.cyclecounters.org:443
                  DocumentRoot "/Volumes/4M1/adam/sites/nara"
                  SSLEngine on
                  SSLCertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/cert.pem"
                  SSLCACertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/fullchain.pem"
                  SSLCertificateKeyFile "/private/etc/letsencrypt/live/cyclecounters.org/privkey.pem"
                  DirectoryIndex index.html
                  <Directory "/Volumes/4M1/adam/sites/nara">
                          Require all granted
                          Options All -Indexes -ExecCGI -Includes +MultiViews
                          AllowOverride none
                          <IfModule mod_dav.c>
                                  DAV Off
                          </IfModule>
                  </Directory>
          </VirtualHost>
  </IfModule>
  

  The same disclaimers apply: mean clever people will no doubt use this information against me, if you're a nice clever person and you see something stupid, please let me know, thanks!
• Here's an example of a subdomain that uses a simple password protection scheme to restrict access to authorized users. In the pre-ssl days, using this technique left the passwords vulnerable to interception by a man in the middle attack. Using https:// ensures that these passwords are never sent unencrypted. This example is almost identical to the one for nara.cyclecounters.org, only the differences are highlighted.

  <VirtualHost *:80>
          ServerName http://hilohigh.cyclecounters.org:80
          RewriteEngine On
          RewriteCond %{SERVER_PORT} 80
          RewriteRule ^/.well-known/(.*) - [L]
          RewriteRule ^(.*)$ https://hilohigh.cyclecounters.org$1 [R,L]
          DocumentRoot "/Volumes/4M1/adam/sites/hilohigh"
          <Directory "/Volumes/4M1/adam/sites/hilohigh/.well-known">
                  Require all granted
                  Options All -Indexes -ExecCGI -Includes +MultiViews
                  AllowOverride none
                  <IfModule mod_dav.c>
                          DAV Off
                  </IfModule>
          </Directory>
  </VirtualHost>
  
  <VirtualHost *:80>
          ServerName http://www.hilohigh.cyclecounters.org:80
          RewriteEngine On
          RewriteCond %{SERVER_PORT} 80
          RewriteRule ^(.*)$ http://hilohigh.cyclecounters.org$1 [R,L]
  </VirtualHost>
  
  <IfModule ssl_module>
          <VirtualHost *:443>
                  ServerName https://www.hilohigh.cyclecounters.org:443
                  RewriteEngine On
                  RewriteCond %{SERVER_PORT} 443
                  RewriteRule ^(.*)$ https://hilohigh.cyclecounters.org$1 [R,L]
                  SSLEngine on
                  SSLCertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/cert.pem"
                  SSLCACertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/fullchain.pem"
                  SSLCertificateKeyFile "/private/etc/letsencrypt/live/cyclecounters.org/privkey.pem"
          </VirtualHost>
  
          # The fourth virtual host is the only one that needs to change; it uses
          # a different "require" line to turn on passwords, which are stored
          # outside the document root so they can't be downloaded and cracked offline.
          <VirtualHost *:443>
                  ServerName https://hilohigh.cyclecounters.org:443
                  DocumentRoot "/Volumes/4M1/adam/sites/hilohigh"
                  SSLEngine on
                  SSLCertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/cert.pem"
                  SSLCACertificateFile "/private/etc/letsencrypt/live/cyclecounters.org/fullchain.pem"
                  SSLCertificateKeyFile "/private/etc/letsencrypt/live/cyclecounters.org/privkey.pem"
                  DirectoryIndex index.html
                  <Directory "/Volumes/4M1/adam/sites/hilohigh">
                          Options All -Indexes -ExecCGI -Includes +MultiViews
                          AllowOverride none
                          AuthUserFile /Volumes/4M1/adam/sites/hilohigh.htpasswd
                          AuthName photos
                          AuthType Basic
                          require valid-user
                          <IfModule mod_dav.c>
                                  DAV Off
                          </IfModule>
                  </Directory>
          </VirtualHost>
  </IfModule>
  

• I use a single certificate for cyclecounters.org and all of it's various subdomains (www.cyclecounters.org, nara.cyclecounters.org, www.nara.cyclecounters.org, and so forth.) I wasn't able to get the standard certbot --apache to work, so instead I use the rather lengthy certbot command below to create the .pem files referenced above:

     $ # Stop the currently running web server, if any.
     $ sudo apachectl stop
     $ # Temporarily disable SSL in your httpd.conf.
     $ sudo sed -i -e 's/LoadModule ssl_module/#LoadModule ssl_module/g' /etc/apache2/httpd.conf
     $ # Create empty certificate files to placate "apachectl configtest" below.
     $ # These empty certificate files won't be used, and will be overwritten
     $ # by certbot later with the real copies.
     $ sudo mkdir -p /etc/letsencrypt/live/cyclecounters.org
     $ sudo touch /etc/letsencrypt/live/cyclecounters.org/cert.pem
     $ sudo touch /etc/letsencrypt/live/cyclecounters.org/fullchain.pem
     $ sudo touch /etc/letsencrypt/live/cyclecounters.org/privkey.pem
     $ # If you don't get "Syntax OK", don't even bother trying the rest.
     $ # Instead, fix the problems exposed by configtest first.
     $ sudo apachectl configtest
     Syntax OK
     $ sudo apachectl start
     $ # This creates a single certificate file valid for all six domain names.
     $ # You could also create separate certificates for each, it's up to you.
     $ # If you have a lot of subdomains, combining them into fewer certificates
     $ # makes it easier to avoid the letsencrypt rate limits.
     $ sudo certbot certonly --webroot --rsa-key-size 4096 \
       -w /Users/adam/sites/main \
         -d cyclecounters.org \
         -d www.cyclecounters.org \
       -w /Users/adam/sites/nara \
         -d nara.cyclecounters.org \
         -d www.nara.cyclecounters.org \
       -w /Users/adam/sites/hilohigh \
         -d hilohigh.cyclecounters.org \
         -d www.hilohigh.cyclecounters.org
     A bunch of certbot output, hopefully ending in:
     IMPORTANT NOTES:
      - Congratulations! Your certificate and chain have been saved at:
        /etc/letsencrypt/live/cyclecounters.org/fullchain.pem
        Your key file has been saved at:
        /etc/letsencrypt/live/cyclecounters.org/privkey.pem
        Your cert will expire on 2019-02-03. To obtain a new or tweaked
        version of this certificate in the future, simply run certbot
        again. To non-interactively renew *all* of your certificates, run
        "certbot renew"
      - If you like Certbot, please consider supporting our work by:
  
        Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
        Donating to EFF:                    https://eff.org/donate-le
     $ # Stop the currently running web server
     $ sudo apachectl stop
     $ # Now re-enable SSL since the certificates have been created
     $ sudo sed -i -e 's/#LoadModule ssl_module/LoadModule ssl_module/g' /etc/apache2/httpd.conf
     # # Restart apache, and you should be up and running with SSL!
     $ sudo apachectl start
  

• Lastly, I need to ensure that the certificates get renewed automatically. I could just run certbot renew every couple months, but I'd eventually forget and break things. So instead I need to arrange to have my Mac run certbot renew every so often. In the good old days, I'd just use the standard cron built in to macOS, but that's apparently broken in Mojave, too. (If you can get it to work, by all means drop me a line and let me know how you did it, thanks!) So instead, I need to use macOS launchctl. Use your favorite text editor to create
  ~/Library/LaunchAgents/org.cyclecounters.renewcerts.plist, which should look like:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs\
  /PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
    <key>Label</key>
    <string>org.cyclecounters.renewcerts</string>
  
    <key>ProgramArguments</key>
    <array>
      <string>sudo</string>
      <string>/usr/local/bin/certbot</string>
      <string>renew</string>
    </array>
  
    <key>StartInterval</key>
    <integer>47000</integer>
  
    <key>RunAtLoad</key>
    <true/>
  
    <key>StandardErrorPath</key>
    <string>/dev/null</string>
  
    <key>StandardOutPath</key>
    <string>/dev/null</string>
  </dict>
  </plist>
  

  Of course, your version should call the file something different, like com.yourdomain.renewcerts.plist, and the Label key should use that name, too. Then tell launchd to run your program:

     $ # You must set the permissions on your .plist file for launchctl to use it.
     $ chmod 600 ~/Library/LaunchAgents/org.cyclecounters.renewcerts.plist
     $ sudo chown root:wheel ~/Library/LaunchAgents/org.cyclecounters.renewcerts.plist
     $ # This will only work while you are logged in to the desktop.
     $ # There are other directories you can use that will run things all the
     $ # time, cron-style, but I couldn't write to them without disabling
     $ # System Integrity Protection, which in turn is tricky to do when you cannot
     $ # easily boot your remotely co-located Mac into recovery mode.  Sigh.
     $ launchctl load ~/Library/LaunchAgents/org.cyclecounters.renewcerts.plist
     $ # This shows that the command ran successfully.  It'll run every 13 hours
     $ # and change -- the 47,000 seconds figure in the .plist -- which will prevent
     $ # it from hammering the letsencrypt servers at any specific time.
     $ launchctl list | grep cyclecounters
     -       0       org.cyclecounters.renewcerts
     $ date
     Sun Nov  4 21:45:44 HST 2018
     $ # Here we can see that the last renewal attempt worked fine.
     $ sudo tail -n 1 /var/log/letsencrypt/letsencrypt.log
     2018-11-04 21:43:40,079:DEBUG:certbot.renewal:no renewal failures
     $
  

• Now that you've got ssl working, you should probably test it. Qualsys offers a nice automated testing site here. Enter your domainname and see what it says, it only takes a minute or two.
• You may notice a line in the Qualsys results talking about "DNS CAA"; that's a handy way to add information to the DNS records for your domain to say that only certain certificate providers (in this case letsencrypt.org) are allowed to issue certificates for your domain. This, combined with certificate transparency, makes it easier for you to ensure that certificates are only being issued for your domains when requested by you, and not by a third party. Setting up the new DNS records you'll need is beyond the scope of this tutorial, but see here for a handy tool to generate the correct DNS records you'll need.