Installing a LetsEncrypt.org wildcard certificate on Linux using acme.sh and a DNS Api

Let’s Encrypt is a certificate authority (CA) that offers free SSL/TLS certificates

Objective: To acquire and install a wildcard SSL/TLS certificate from LetsEncrypt.org to a GNU/Linux system with automatic renewal enabled by using a registrar’s DNS API to prove the ownership of the domain. In this case I’m using the Gandi LiveDNS API but the instructions work with other DNS providers with APIs too that have acme.sh DNS plugins available.

Install acme.sh

sudo su
git clone https://github.com/Neilpang/acme.sh.git
cd ./acme.sh
./acme.sh --install

Get API key from Gandi

Go to https://account.gandi.net/ and click on “security” and generate an API key and store it in a safe place and export it with

export GANDI_LIVEDNS_KEY="fdmlfsdklmfdkmqsdfkthiskeyisofcoursefake"

Generate the cert

Followed the official acme.sh DNS API instructions at GitHub.

Now use the staging environment (–test) for the certificate issuing. This will save you on the issuing limits of LetsEncrypt.org production platform.

acme.sh --issue --test --log --dns dns_gandi_livedns --log -d *.domain.tld -d domain.tld

Notice that this will fail on the first run but succeed on the second one.

Once the –test finishes successfully you can switch to the production environment by deleting the /root/.acme.sh/*.domain.tld-directory (it contains the staging server’s information and will be regenerated with the production server’s info on next run)

rm -rf /root/.acme.sh/*.domain.tld

Now run the issuing command twice (it will fail on the first run) just changing –test to –force

acme.sh --issue --force --log --dns dns_gandi_livedns --log -d *.domain.tld -d domain.tld

Install the certificate in some sensible place as the directory structure of /root/.acme.sh may change in the future.

Certificate deployment instructions for Apache at acme.sh GitHub

acme.sh --install-cert -d *.domain.tld -d domain.tld \
--cert-file /etc/apache2/acme.sh/*.domain.tld/*.domain.tld.cer \
--key-file /etc/apache2/acme.sh/*.domain.tld/*.domain.tld.key \
--fullchain-file /etc/apache2/acme.sh/*.domain.tld/fullchain.cer \
--reloadcmd "service apache2 force-reload"

Edit Apache configuration to take the SSL/TLS protected site into use

Create a VirtualHost-directive for the SSL/TLS protected site

<VirtualHost *:443>
...
   SSLEngine on
   SSLCertificateKeyFile /etc/apache2/acme.sh/*.domain.tld/*.domain.tld.key
   SSLCertificateFile /etc/apache2/acme.sh/*.domain.tld/*.domain.tld.cer
   SSLCertificateChainFile /etc/apache2/acme.sh/*.domain.tld/fullchain.cer
</VirtualHost>


Once you are sure that the HTTPS site works redirect requests from the http-site to the HTTPS site with URL rewriting.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Enable forward secrecy in your Apache configuration

Enabling forward secrecy makes users of the site more secure. Instructions by SSLLabs research here at GitHub.


That’s it. The acme.sh installation added a cronjob to run it daily and it will renew the certificate automatically when it is nearing the end of it’s validity period.


 

UPDATE 2018-07-16: If you need to use more than one API Key do as follows. This usually occurs when you are hosting sites for many different registrants.

Export the API key if this is the first time you are using that key. If you have already created certificates with this API key the acme.sh will read it from the config file from the file /root/.acme.sh/yourconfigdirectory/account.conf

acme.sh --issue --config-home /root/.acme.sh/yourconfigdirectory --log --dns dns_gandi_livedns --log -d *.domain.tld -d domain.tld

First run will fail. Run it again.

Create the target directory for certificate installation.

mkdir /etc/apache2/acme.sh/yourconfigdirectory/\*.domain.tld

Now install the certificate

./acme.sh --install-cert --config-home /root/.acme.sh/yourconfigdirectory -d *.domain.tld -d domain.tld \
--cert-file /etc/apache2/acme.sh/yourconfigdirectory/\*.domain.tld/\*.domain.tld.cer \
--key-file /etc/apache2/acme.sh/yourconfigdirectory/\*.domain.tld/\*.domain.tld.key \
--fullchain-file /etc/apache2/acme.sh/yourconfigdirectory/\*.domain.tld/fullchain.cer \
--reloadcmd "service apache2 force-reload"

./acme.sh --install-cert --config-home /root/.acme.sh/yourconfigdirectory -d *.domain.tld -d domain.tld \ 
--cert-file /etc/apache2/acme.sh/yourconfigdirectory/\*.domain.tld/\*.domain.tld.cer \ 
--key-file /etc/apache2/acme.sh/yourconfigdirectory/\*.domain.tld/\*.domain.tld.key \ 
--fullchain-file /etc/apache2/acme.sh/yourconfigdirectory/\*.domain.tld/fullchain.cer \ 
--reloadcmd "service apache2 force-reload"

Now you are ready to proceed to configure your website’s Apache configuration as described in the original instructions (scroll up).


If you have any improvement suggestions or would just like to say thanks you can use the contact form below.

Migrating a Mediawiki to a new Linux server

To get you started: Get a Linux VPS.

I chose Tavu.io, an ecohosting company with the data center deep inside the Finnish granite bedrock, a “renewable electricity only”-policy and a cloud infrastructure built on top of OpenStack.

For OS I chose latest Debian Stable which was version 9 at the time of writing.

Mediawiki's logo
Mediawiki is a wiki system of awesome quality and reliability

Tavu.io created the VPS on their OpenStack based cloud in a matter of few tens of seconds.

Then the system gave a temporary password and on login via ssh the system required a new password was set.

Login with the new password and run

sudo apt update && sudo apt upgrade

This will get the pre-installed software to their latest version numbers and may take a while.

Then I added a user name I usually use on Linux systems by entering:

sudo useradd -m -s /bin/bash <username>

Now set a password for username with

sudo passwd <username>

and add the user to /etc/sudoers (make a copy of the line that says “root” and change ‘root’ to your user name of choice) and log out and log in as the newly created user.

Now is a good time to get an firewall going so do so.

Now grab a list of installed packages with

dpkg --get-selections > packages-YYYY-MM-DD.list

This could be useful for later use.

Now install some software

sudo apt install tmux nmap apache2 lynx
  1. tmux is a shell session multiplexer
  2. nmap is a port scanner
  3. apache2 is a web server
  4. lynx is a terminal-based web browser

And some more software

sudo apt install htop atop itop iotop glances chkrootkit
  1. htop, atop, itop and glances are system monitoring (for humans)
  2. iotop is a IO (Input/Output) monitoring system for humans (requires sudo)
  3. chkrootkit is a software for checking if your system has a known rootkit installed (bad for you)

Migrating the Mediawiki

First install the dependencies as described below and only then we switch to following the moving a wiki guide. which consists of actually three operations:

  1. Making a backup of the Mediawiki on the old server
  2. Moving the backup to the new machine
  3. Restoring Mediawiki from the backup.

Installing Mediawiki’s dependencies

Now we move on to installing the dependencies of Mediawiki. For this we will follow the Mediawiki installation guide for Debian and Ubuntu (generic guide here) up-to-the-point of actually installing one.

sudo apt-get install apache2 default-mysql-server default-mysql-client php php-mysql libapache2-mod-php php-xml php-mbstring

We installed MariaDB instead of MySQL. They are binary compatible so you can choose one or the other and also interchange them afterwards. Add the database and database user of your wiki and grant all rights on the database to the database user.

Those are the mandatory components and next up are the beneficial components out of which we chose the following

sudo apt-get install php-apcu php-intl imagemagick php-cli

Move required files and the database to new machine

If possible make sure that your Mediawiki is the latest version on the old server.

Next I packed and moved

  1. The database
  2. The Mediawiki directory /var/www/mediawiki
  3. The Mediawiki logs from /var/log/sites/mediawiki
  4. site configuration from /etc/apache/sites-available

and expanded them into the right place on the new server.

A sane approach to the Mediawiki files ownership is as follows

First recursively make you the owner of all of the Mediawiki directory and its subdirectories and files with

sudo chown -R <username> /var/www/mediawiki

and then explicitly making the images/-directory, where Mediawiki stores its writables, to be posession of user www-data (www-data is the user that Apache and Mediawiki run as) by

sudo chown -R www-data /var/www/mediawiki/images

Minimize downtime

The TTL (Time To Live) of the domain at the DNS also naturally affects the length of the outage so modifying it to very short time such as 15 minutes way in advance of commencing the migration.

I temporarily modified the domain name of the Mediawiki (in /etc/apache2/sites-available and also LocalSettings.php) to a temporary subdomain to test that the Mediawiki is working on the new server before doing the DNS change of the production Mediawiki. After you have viewed that the wiki is working on the new server change the domains back to the “real” one.

Following these two practices are simple practical things to do that help to make the imminent outage of your service as short as possible.


Configure Apache2

Link the .conf files with symbolic links from /etc/apache2/sites-available to /etc/apache2/sites-enabled.

ln -s ../sites-available/example.com example.com

Enable mod_rewrite which is needed for the pretty URLs to work.

sudo a2enmod rewrite

Test your Apache2 configuration with

sudo apachectl configtest

and fix your config untill the configuration says ‘Syntax OK’

The last step is that we need to make the Apache2 reload its configuration which is accomplished with

sudo service apache2 reload

Now navigate to the temporary subdomain’s /wiki/-directory and you should see your wiki there.

Warning: The Mediawiki extensions may have dependencies that are not satisfied so also check that each extension works.


If using reCAPTCHA

Google’s reCAPTCHA stopped working (CAPTCHA shows up but when it is time to approve the human as a human I got an error message that reCAPTCHA “cannot contact server”.

This seemed to be solved by logging in to the CAPTCHA management page at Google and deleting the old keys and generating new keys and naturally changing the keys to the new ones at Mediawiki’s LocalSettings.php


Important: Enable outgoing email for Mediawiki

Now we need to put in place a way for the Mediawiki to send emails (very important).

My registrar Gandi.net provides a mailing system which enables the one to use $wgSMTP (set this in LocalSettings) to send outgoing mailing. They also have 5 mailboxes and 1000 forwards included for each domain for all registrants so I can confidently use …@consumerium.org addresses since Gandi.net is rock-solid operation with a very wide palette of TLD’s though maybe 20% higher prices than the price leader which is often buggy, slow and unreliable if they just compete with the “cheapest on planet”.

Other method to get email to go outwards is to install a MTA (Mail Transfer Agent) such as Sendmail, Postfix or Nullmailer and configure it to send the messages.

Whichever method you chose to enable email do check that it works!

Happy wikiditing! – Juho