HTTPS, finally

Thursday, June 28th, 2018 10:34

In further news of updating my personal web presence, I have finally set up HTTPS for As I write this I'm working on updating all the links to it that I control.

The thing I found underdocumented in Let's Encrypt/Certbot is: if you want to (or must) manually edit the HTTP configuration, what should the edits be? What I concluded was:

<VirtualHost *:443>
  Include /etc/letsencrypt/options-ssl-apache.conf
  SSLCertificateFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/chain.pem of configuration for this virtual host...


  • /etc/letsencrypt/options-ssl-apache.conf (which of course may be in a different location depending on your OS and package manager) contains the basic configuration to enable SSL (SSLEngine on) and certbot-recommended cipher options.
  • You have to have a separate VirtualHost entry for *:443 and *:80; there's no way to copy the common configuration as far as I heard.
  • By "CERT NAME" I mean the name assigned to a multi-domain-name certificate if you have requested one. You can find out the certificate names with the command certbot certificates. For a single domain it will be identical to the domain name.

A machine I used to use to host some web services, bots, and repositories became no longer accessible from the Internet, as a result of which I've had to move what I was serving from it; some to, some to personal machines.

I took the opportunity to clean things up a bit, as a result of which I now have better backups, more polished services, and know a little bit more about configuring Apache — though not as much as I perhaps should.

  • My Subversion repositories are now served over HTTP, and therefore browsable; and they are now backed up daily (using svnsync triggered by a cron job) to my laptop, and thence to all its backups.

    (I wasted several minutes on remembering that cron will ignore the last line of a crontab file if it doesn't end with a newline; after listening to me grumbling about this, someone made a suggestion to end the file with a comment, so that the last line is harmless whether ignored or not, and also reminds one of the issue.)

    If you have a working copy of one of my repositories (E-on-CL, E-on-JavaScript, MudWalker, Den, etc.), here's a guide to the changed URLs.

  • My other Tahoe-LAFS volunteer grid storage node is now residing on a machine on my home LAN.

  • Finally, some simple data-querying web services I wrote for Waterpoint's word games have now been moved to; I also took the time to prettify their URLs (no cgi-bin or .cgi) and write documentation.

I haven't yet gotten to working on the bots, darcs repositories, or miscellaneous other stuff I had there.

(Pondering moving my blog over to as well so as to not have ads, especially now that I found I can still have LJ-friends by way of OpenID. (Hm, but reading friends-locked posts over RSS might not work since there's no username+password for LJ to accept. Anyone have experience with that situation?))

Apache configuration questions:

  1. If I have multiple variants of a document (e.g. foo.html foo.pdf foo.txt) handled by MultiViews, so the canonical URL of the document is extensionless (“foo”), how do I properly control the default variant to serve in the event that the client does not express a preference via the Accept header? (Without doing so, I found that it would serve the .txt version, whereas I would prefer the HTML.) All that I found that worked was to create a type map file named “foo” with quality values, and force it to be interpreted as a type map using <FilesMatch>. This seems kludgy to me.
  2. What is the right way to serve CGIs, not in a designated cgi-bin directory, and without any .cgi extension in the URL? I initially tried to apply mod_rewrite, but I couldn't get it to work such that /foo internally contacted foo.cgi whereas /foo.cgi redirected to /foo. I resorted to another <FilesMatch> explicitly listing the name of each CGI and doing SetHandler cgi-script.
  3. What is the right way to handle “testing” vs. “deployment” configurations, where the relevant Directory, Location, etc may be different depending on which server or subdirectory the site is set up on? I see that one may use environment variables — should I just set up variables containing the path prefixes for the particular host before including the generic configuration file?