Installing a wildcard certificate on Linux using 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 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 DNS plugins available.


sudo su
git clone
cd ./
./ --install

Get API key from Gandi

Go to 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 DNS API instructions at GitHub.

Now use the staging environment (–test) for the certificate issuing. This will save you on the issuing limits of production platform. --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/*.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/*.domain.tld

Now run the issuing command twice (it will fail on the first run) just changing –test to –force --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/ may change in the future.

Certificate deployment instructions for Apache at GitHub --install-cert -d *.domain.tld -d domain.tld \
--cert-file /etc/apache2/*.domain.tld/*.domain.tld.cer \
--key-file /etc/apache2/*.domain.tld/*.domain.tld.key \
--fullchain-file /etc/apache2/*.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/*.domain.tld/*.domain.tld.key
   SSLCertificateFile /etc/apache2/*.domain.tld/*.domain.tld.cer
   SSLCertificateChainFile /etc/apache2/*.domain.tld/fullchain.cer

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 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 will read it from the config file from the file /root/ --issue --config-home /root/ --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/\*.domain.tld

Now install the certificate

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

./ --install-cert --config-home /root/ -d *.domain.tld -d domain.tld \ 
--cert-file /etc/apache2/\*.domain.tld/\*.domain.tld.cer \ 
--key-file /etc/apache2/\*.domain.tld/\*.domain.tld.key \ 
--fullchain-file /etc/apache2/\*.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, 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 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/

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 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 … addresses since 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

Installing a Kubuntu 17.04 (again)

This is a blog post mainly about how to flexibly reinstall Kubuntu 17.04 GNU/Linux OS after the previous install running into troubled waters and break down.

Cycle through more than one disk in the install clean approach so get an USB-to-SATA3 casing and some hard drives. The idea is that to install the next OS you do not need to overwrite the previous OS.

  • Get FireFox sync. This way you don’t need to import your bookmarks as sync does it for you.
  • Take previous disk out of the computer and insert another disk, connect the USB installation medium (and select boot order in BIOS or UEFI) and power up.
  • Install Kubuntu.
  • Boot Kubuntu
  • Open a shell and run ‘sudo apt update && sudo apt upgrade’ to get the installed software to the latest version.
  • Install software
    • Monitoring: ‘sudo apt install htop atop iotop glances’ (glances will install python)
    • Database: ‘sudo apt install mariadb-server’
    • Graphics and video: ‘sudo apt install inkscape gimp kdenlive’
    • Audio: ‘sudo apt install linux-lowlatency audacity fluidsynth patchage’
    • Shell multiplexer: ‘sudo apt install tmux’
    • Virtual machine: ‘sudo apt install virtualbox’
  • Copy files:
    • Connect the old disk to the computer with the USB-to-SATAIII casing and mount it
    • I am trying to avoid getting broken confs from the old machine so only conf file I will take is in /media/username/UUID/username/.config/kdenlive. I used cp command in the shell to get it
    • Copy all files and directories from your old home directory to the new home directory, tick “apply to all” and select “write into” when it asks what to do with directories that exist.
    • Copy any other files you need. Unmount the external drive and remove and put in a cool and dry place.

How to set up a GNU/Linux server at ecohosting

Consumerium banner – Enhancing Consumer Informedness gets its first ecoserver.



Trollböle et al gets its gear and moves to Björneborg. acquires its first ecoserver from a company that uses electricity sourced from renewable sources only.

Going under the granite to work on electricity from the wind above the granite and the sunshine and rainfall. Seems someone stuck a huge fusion reactor in the sky, which is nice.


Objective: Set up a stack in efficient and clear manner in order to move the current development wiki onto the new ecological server paying mind to also future needs of upcoming services. Document process.

Information: Today I purchased a VPS server from, a Finnish hosting services provider that has been operating since 2007. To the international clientele they cater with the brand Price is same but in dollars. Costs a hell lot more than the global price leader as always but the laws, the laws. logo uses exclusively renewable sourced electricity for their operations and has been operating since 2007. Of the non-transnational i.e. small and local hosting guys they as of 2016 have the best price in Finland. Their hosting site is also slightly security enhanced since it is located inside the Finnish granite bedrock in Björneborg in a cave system that formerly belonged to the Finnish Defence Forces until bought it.






Their main selling points were the wind powered computers, their data center which is built into a cave system in Finnish bedrock in Björneborg and naturally being local (not multinational giant with huge deep financial pockets to absorb short term losses in gaining market share) and naturally the Finnish law that protects various parties very well.

Step #1: Purchase and pay in webbank. Server is activated very rapidly upon webshop receiving information from webbank that the funds have been debited and are on their way to their bank account. Default OS is Debian GNU/Linux and others are available on request.

Step #2 Login with the root account details given by the GUI. System language seems to be set to Finnish. Can change the locale later on so not very relevant, I hope.

Step #3 Change root pass. Don’t lose it. Resetting will be terribly expensive.

Step #4 Update installed software ‘apt update && apt upgrade’ will get the base system to latest good version. Running it you one notices they run a Debian mirror at their site. Ecological and fast, good citizen.

( Step #5 install tmux session multiplexer and detacher ‘apt install tmux’ and run tmux (not a necessary step but it is good idea. alternative program is ‘screen’ but I use tmux )

Step #6 Add the command ‘sudo‘ with ‘apt install sudo’. This also creates the ‘/etc/sudoers’-file.

Step #7 Now add a normal user and give sudo rights (command ‘useradd’) and add it to sudoers (edit /etc/sudoers). I used ‘useradd -m -s /bin/bash usernamegoeshere’ and ‘nano /etc/sudoers’ and naturally set a password for the usernamegoeshere (‘passwd usernamegoeshere’)

Step #8 Log-out and log-in as the user you just gave sudo rights to. Check that you can sudo. ‘sudo ls’ will do just fine.

Step #9 (Unless causing something unwanted) Disable root logins. There is no reason to allow anyone to attempt to login as root to the sshd. As the normal user with sudo rights you can always ‘sudo su’ if you need the superuser shell. Do so with ‘sudo nano /etc/ssh/sshd_config’ and edit till it says ‘PermitRootLogin no’. Apply changes with ‘sudo service sshd reload’ and test by opening another shell and attempting to login to sshd as root. It should now complain that you have wrong password, excellent. Now log in as the normal user.

Step #10 Set up a stash for storing backups. You do want it outside of your home directory so you can backup that without complications. Start moving your backups from other machines to the server with ‘scp’ or some other more advanced system like rsync over ssh.

Step #11 Install and use nmap: ‘sudo apt install nmap’. Scan localhost from inside and scan the external server address from an outside machine to quickly see what are the firewall settings. Looks like the hosting guys are showing a filtered SMTP port to the Internet even if ‘nmap localhost’ does not see it.

Step #12 Get your firewall in place. I use a simple setup where 22, 80 and 443 are open for incoming traffic and everything else is blocked. This is straightforward and easy to verify to function correctly. Find out about iptables kernel level firewall at The Debian Wiki.

Step #13 Get some monitoring gear ‘sudo apt install htop atop iotop glances

Step #14 Start ‘glances’ and have some snacks and refreshments.

From hereon one probably wants to install a LAMP and LNMP stack as well. I stop here for now because I must contemplate choices as I am moving some sites to this new server and I do not want to make questionable rushed choices.

To be continued..

Relevant reading: