DNS over HTTPS with nginx, dnsdist and Pi-hole

When I was looking for something new to build I ended up building a DNS over HTTPS server. This way I can use my Pi-hole server wherever I am, without exposing port 53. I let nginx handle the encryption of the HTTPS connection, send the information to dnsdist for translation to DNS, and let Pi-hole filter the queries using my blocklists.

The following is assumed:

  • You have nginx up and running
  • You have a subdomain (doh.domain.tld, or dns.domain.tld) with valid certificates (Lets Encrypt, or commercial)
  • You have installed dnsdist, but not yet configured it
  • You have a Pi-hole server up and running, configured to your wishes

This instruction is based upon this tutorial from nginx.com, which I could not get to work.

So, that’s why I adopted their configuration to use dnsdist instead of their njs script language.


The configuration of nginx (saved as dns.domain.nl):

# Proxy Cache storage - so we can cache the DoH response from the upstream
proxy_cache_path /var/run/doh_cache levels=1:2 keys_zone=doh_cache:10m;

server {
    listen 80;
    server_name dns.domain.nl;
    return 301 https://dns.domain.nl/$request_uri;

# This virtual server accepts HTTP/2 over HTTPS
server {
    listen 443 ssl http2;
    server_name dns.domain.nl;

    access_log /var/log/nginx/doh.access;
    error_log /var/log/nginx/doh.error error;

    ssl_certificate /etc/letsencrypt/live/dns.domain.nl/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dns.domain.nl/privkey.pem;

    # DoH may use GET or POST requests, Cache both
    proxy_cache_methods GET POST;

    # Return 404 to all responses, except for those using our published DoH URI
    location / {
        try_files $uri $uri/ =404;

    # This is our published DoH URI
    location /dns-query {

      # Proxy HTTP/1.1, clear the connection header to enable Keep-Alive
      proxy_http_version 1.1;
      proxy_set_header Connection "";

      # Enable Cache, and set the cache_key to include the request_body
      proxy_cache doh_cache;
      proxy_cache_key $scheme$proxy_host$uri$is_args$args$request_body;

      # proxy pass to dnsdist

nginx sends an 404 error when you visit the address https://dns.domain.nl/. It is only a proxy to when data is sent to https://dns.domain.nl/dns-query.

Check the configuration of nginx

nginx -t

It should give the following output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Restart nginx to load the new configuration:

systemctl restart nginx.service


The (minimal working) configuration of dnsdist (saved as dnsdist.conf)

-- dnsdist configuration file, an example can be found in /usr/share/doc/dnsdist/examples/

-- disable security status polling via DNS
-- setSecurityPollSuffix("")

-- fix up possibly badly truncated answers from pdns 2.9.22
-- truncateTC(true)

-- Answer to only clients from this subnet

-- Define upstream DNS server (Pi-hole)
newServer({address="", name="Pi-hole", checkName="dc01.domain.nl.", checkInterval=60, mustResolve=true})

-- Create local DOH server listener in DNS over HTTP mode, otherwise the information coming from nginx won't be processed well
addDOHLocal("", nil, nil, "/dns-query", { reusePort=true })

A few things are important here:

  • I’ve set an ACL that allows dnsdist to only answer to queries from the subnet
  • I’ve added an upstream (downstream according to dnsdist) DNS server with the IP address It’s configured with a custom checkName and checkInterval. Normally, dnsdist sends a query to a.root-servers.net every second(!). With this configuration, it checks another server – my domain controller – every 60 seconds.
  • I’ve added a DOH listener on the loopback address This is configured as DNS over HTTP, because nginx takes care of the decryption of the connection.

Check the configuration of dnsdist:

dnsdist --check-config

It should give the following output:

No certificate provided for DoH endpoint, running in DNS over HTTP mode instead of DNS over HTTPS
Configuration '/etc/dnsdist/dnsdist.conf' OK!

Restart dnsdist to load the new configuration:

systemctl restart dnsdist.service

To check if dnsdist is listening to

netstat -tapn | grep 5300

It should give the following output:

tcp 0 0* LISTEN 4435/dnsdist

Configuring the browser

Now it’s time to configure your browser to use your new DNS over HTTPS server. This website explains how to configure your web browser to use DNS over HTTPS:


Final inspection

To make sure it’s working properly, we need to inspect the logs. nginx keeps a log of access and error messages. We will look at those logs to see if the information is passed on correctly to dnsdist.

Take a look at the access logs of nginx:

cat /var/log/nginx/doh.access

It should give the following output: - - [09/Aug/2020:11:55:05 +0200] "POST /dns-query HTTP/2.0" 200 107 "-" "-" - - [09/Aug/2020:11:55:05 +0200] "POST /dns-query HTTP/2.0" 200 107 "-" "-" - - [09/Aug/2020:11:55:05 +0200] "POST /dns-query HTTP/2.0" 200 122 "-" "-" - - [09/Aug/2020:11:55:05 +0200] "POST /dns-query HTTP/2.0" 200 102 "-" "-" - - [09/Aug/2020:11:55:05 +0200] "POST /dns-query HTTP/2.0" 200 125 "-" "-" - - [09/Aug/2020:11:55:06 +0200] "POST /dns-query HTTP/2.0" 200 102 "-" "-" - - [09/Aug/2020:11:55:06 +0200] "POST /dns-query HTTP/2.0" 200 122 "-" "-" - - [09/Aug/2020:11:55:06 +0200] "POST /dns-query HTTP/2.0" 200 125 "-" "-" - - [09/Aug/2020:11:55:08 +0200] "POST /dns-query HTTP/2.0" 200 112 "-" "-" - - [09/Aug/2020:11:55:08 +0200] "POST /dns-query HTTP/2.0" 200 112 "-" "-" - - [09/Aug/2020:11:55:19 +0200] "POST /dns-query HTTP/2.0" 200 140 "-" "-" - - [09/Aug/2020:11:55:19 +0200] "POST /dns-query HTTP/2.0" 200 152 "-" "-" - - [09/Aug/2020:11:55:20 +0200] "POST /dns-query HTTP/2.0" 200 175 "-" "-" - - [09/Aug/2020:11:55:20 +0200] "POST /dns-query HTTP/2.0" 200 137 "-" "-" - - [09/Aug/2020:11:56:15 +0200] "POST /dns-query HTTP/2.0" 200 64 "-" "-" - - [09/Aug/2020:11:56:15 +0200] "POST /dns-query HTTP/2.0" 200 64 "-" "-" - - [09/Aug/2020:11:56:15 +0200] "POST /dns-query HTTP/2.0" 200 64 "-" "-" - - [09/Aug/2020:11:56:15 +0200] "POST /dns-query HTTP/2.0" 200 64 "-" "-" - - [09/Aug/2020:11:56:21 +0200] "POST /dns-query HTTP/2.0" 200 59 "-" "-" - - [09/Aug/2020:11:56:30 +0200] "POST /dns-query HTTP/2.0" 200 55 "-" "-"

It’s important that you see 200 (after HTTP/2.0) in the logs. This means that nginx was able to pass the information to dnsdist. Otherwise, something has gone wrong.

When something has gone wrong, it should show up in the error logs

cat /var/log/nginx/doh.error

It should (hopefully not) give the following output:

2020/08/09 11:15:26 [error] 946#946: *511 connect() failed (111: Connection refused) while connecting to upstream, client:, server: dns.domain.nl, request: "POST /dns-query HTTP/2.0", upstream: "", host: "dns.domain.nl"

Optimizing and securing Zimbra Open Source Edition

The next commands are used to optimize and secure my Zimbra Collaboration 8.8 Open Source Edition (executed as user zimbra in the CLI):

zmdhparam set -new 3072

zmprov mcf zimbraMtaSmtpTlsMandatoryCiphers high
zmprov mcf zimbraMtaSmtpdTlsMandatoryCiphers high
zmprov mcf zimbraMtaSmtpdTlsCiphers high

zmlocalconfig -e postfix_enable_smtpd_policyd=yes
zmprov mcf zimbraMtaEnableSmtpdPolicyd TRUE
zmprov mcf +zimbraMtaRestriction "check_policy_service unix:private/policy"

zmprov mcf zimbraMtaSmtpTlsSecurityLevel may
postconf -e smtpd_tls_security_level=may
postconf -e tls_preempt_cipherlist=yes
postconf -e tls_session_ticket_cipher=aes-256-cbc

zmprov mcf zimbraMtaRecipientDelimiter +

zmprov modifyConfig zimbraFileUploadMaxSize 40960000
zmprov modifyConfig zimbraMtaMaxMessageSize 51200000
zmprov modifyConfig zimbraMailContentMaxSize 102400000

zmlocalconfig -e antispam_enable_rule_updates=true
zmlocalconfig -e antispam_enable_restarts=true
zmlocalconfig -e antispam_enable_rule_compilation=true

zmprov mcf zimbraMtaSmtpdTlsExcludeCiphers 'MEDIUM,LOW,EXPORT,aNULL,eNULL,MD5,DES,RC4'

Backup Zimbra Open Source edition to a NAS with NFS

The most recent open source version of Zimbra Collaboration 8.8 has no official backup module. But with the help of scripting it is still possible to backup a mailbox.

The following situation is assumed:

  • Up-to-date Zimbra Collaboration 8.8
  • A file is available (emailaccounts.txt) containing all email addresses for the backup
  • A NFS server is available to store the backup externally
  • A local directory (/nfs-mount) is available to connect to the NFS server
  • The script has to be run as root because of NFS (maybe there are other ways to do this, but it works.)
  • A local partition is available (/backup) from where the backup is copied to the NFS server

# Functies

function backup_loop() {
# In het bestand emailaccounts.txt moet handmatig het emailaccount worden toegevoegd, wil het meegenomen worden in de backup.

for i in $(cat /home/maarten/emailaccounts.txt);

# De content van de gehele mailbox (dus ook agenda etc.) wordt dmv een API opgevraagd en opgeslagen in de map /backup/zimbra/
        backup_folder_check			# Controleer of de map bestaat
        backup_cleanup				# Verwijder bestanden ouder dan geconfigureerde dagen
        export_mailbox				# Exporteer de mailbox
        backup_to_nas				# Zet een kopie op de nas via de NFS-koppeling

# Echo welke emailadressen in de backup zijn verwerkt
echo $i;

# Klaar met exporteren

function backup_folder_check() {
# Controleer of de map bestaat voor deze gebruiker. Is dit niet het geval, maak alsnog de map aan.
if [ ! -d /backup/zimbra/$i ];
                mkdir -p /backup/zimbra/$i;
                chown zimbra:zimbra /backup/zimbra/$i

function export_mailbox() {
        zmmailbox -z -m $i getRestURL "//?fmt=tgz" > /backup/zimbra/$i/$(date +%Y-%m-%d).tgz;

function backup_cleanup() {
        /usr/bin/find /backup/zimbra/$i/ -type f -mtime +4 -delete; # Verwijder bestanden ouder dan 4 dagen

function backup_to_nas() {
        cp -Rf /backup/zimbra/$i /nfs-mount/zimbra/$i # Kopieer bestanden naar de nas via /nfs-mount/

function mount_nfs() {
        /sbin/mount.nfs4 NAS:/volume2/Backups /nfs-mount/ -w -o rsize=8192,wsize=8192 # Koppel de nas aan /nfs-mount/

function unmount_nfs() {
        /sbin/umount.nfs4 /nfs-mount/ # Ontkoppel de /nfs-mount/

# Volgorde uit te voeren werkzaamheden

mount_nfs		# Maak de NAS wakker en maak een NFS-koppeling  --> kan alleen als root
backup_loop		# Start de loop - controleer of mappen bestaan en exporteer vervolgens de mailbox naar de betreffende map
backup_cleanup		# Zorg dat de lokale backup maximaal 4 dagen oud is
unmount_nfs		# Ontkoppel /nfs-mount/ zodat de NAS kan slapen  --> kan alleen als root

Install pi_mqtt_gpio on Raspbian

I want to receive a notification when someone rings the doorbell at my front door. For this I can buy all kinds of expensive (wireless) doorbells, but I want to use the existing wiring. Because I use Home Assistant for all kinds of automation at home, I also want to integrate this into Home Assistant. Since there is already a Raspberry Pi in the meter cupboard for reading my smart meter, this seemed a logical addition to me.

For this I found this repository: https://github.com/flyte/pi-mqtt-gpio

This Python application does exactly what I want:

  1. It reads the GPIO pins from the Raspberry Pi Board
  2. It allows me to configure which pins have to be read
  3. It allows the Pi to send the information to an MQTT broker

This allows me to use my Home Assistant installation to notify me when someone rang my doorbell, thereby always being informed when someone was at my front door, even when I’m not at home. It also makes it possible to automatically turn on a light in the hallway when it’s dark.

It was a little headache to make it work on my Raspberry Pi 3b with Raspbian, so that’s why I wrote down the instructions.

All the commands are executed as root user

Virtual Env

First you need to create a virtual environment with Python version 3, in /home/pi

/home/pi# python3 -m venv pi_mqtt_gpio

Next, you enter the virtual environment

/home/pi# . pi_mqtt_gpio/bin/activate

Your shell should now show this:

(pi_mqtt_gpio) root@rpi3:

Install the following packages with pip3 (if it’s not installed, use apt install python3-pip)

  • pi_mqtt_gpio
  • rpi.gpio
(pi_mqtt_gpio) root@rpi3: pip3 install rpi.gpio pi_mqtt_gpio

In addition, other packages are also installed (enum34, PyYAML, cerberus, paho-mqtt)


In the configuration file you define which MQTT broker the data should be sent to, but also to which GPIO pins should be listened.

Read more about the configuration of pi_mqtt_gpio on this Github page.

Note: this tutorial assumes you save the file pi-mqtt-gpio-config.yaml in the folder /home/pi


Supervisor is a client/server system that allows its users to monitor and control a number of processes on UNIX-like operating systems.

Install Supervisor

apt install supervisor

Open the Supervisor configuration folder

cd /etc/supervisor/conf.d/

Create a new file with the filename pi_mqtt_gpio.conf

nano pi_mqtt_gpio.conf

Add the following lines:

command = /home/pi/pi_mqtt_gpio/bin/python -m pi_mqtt_gpio.server /home/pi/pi-mqtt-gpio-config.yaml
autorestart = false # added to avoid a restart loop
directory = /home/pi
redirect_stderr = true
stdout_logfile = /var/log/pi-mqtt-gpio.log

Update supervisor to include this program during the startup of the operating system:

supervisorctl update

This should give the following output:

pi_mqtt_gpio: updated process group

Now it’s time to start pi_mqtt_gpio with Supervisor

supervisorctl start pi_mqtt_gpio

This should give the following output:

pi_mqtt_gpio: started

Check the logfile for the correct operation of the program:

tail -f /var/log/pi-mqtt-gpio.log

An example of an working configuration:

2020-04-28 12:06:28,550 mqtt_gpio (INFO): Startup
2020-04-28 12:06:29,039 mqtt_gpio (INFO): Connected to the MQTT broker with protocol v3.1.1.
2020-04-28 12:06:29,049 mqtt_gpio (INFO): Polling: Input 'doorbell' state changed to False

Now you can connect a doorbell to your Raspberry Pi. When you ring the doorbell, a message should be sent to your MQTT broker.

openssl pkcs12 export to ‘/opt/zimbra/ssl/zimbra/jetty.pkcs12’ failed(1)

When you encounter the following error:

** Creating file '/opt/zimbra/ssl/zimbra/jetty.pkcs12'
ERROR: openssl pkcs12 export to '/opt/zimbra/ssl/zimbra/jetty.pkcs12' failed(1):
unable to load certificates
140665143981720:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:805:

Do this (when for example having all the certs temporarily stored in /tmp/):

chown zimbra:zimbra /tmp/*.crt
chmod 666 /tmp/*.crt

Source: https://forums.zimbra.org/viewtopic.php?t=60189

AsusWRT: block Google DNS with iptables

By default, every Google device uses the following configured DNS-servers:


But I don’t want my guests, who can use my WiFi, to let Google phone home and give information about who visits my network.

I use iptables to block those DNS-requests. The firewall rejects all the DNS-requests that would be sent to Google. So the clients have no other option than to use the DNS-server that’s published by my DHCP-server.

User scripts

With the AsusWRT (and asuswrt-merlin) firmware I can add user scripts. The next two lines are loaded when the firewall (iptables) has been started.

iptables -I FORWARD --destination -j REJECT
iptables -I FORWARD --destination -j REJECT

Save this code in the folder /jffs/scripts/ with the filename firewall-start.

After successfully loading the rules in iptables, when your router has (re)booted successfully, every DNS-request to Google will be rejected. When testing this with a ping to (or, the result should be:

Pinging with 32 bytes of data:
Reply from Destination port unreachable.
Reply from Destination port unreachable.
Reply from Destination port unreachable.
Reply from Destination port unreachable.

Handige PowerShell commando’s voor mezelf

Het toevoegen van lange DKIM sleutels met dnscmd

Probleem met PowerShell: het kan geen strings aan die langer zijn dan 255 tekens. Mijn DKIM-key is langer dan dat, en ondanks allerlei pogingen is het niet gelukt om deze met PowerShell toe te voegen aan de DNS-zone.

Gelukkig werkt dnscmd nog wel in PowerShell, dus kan ik met onderstaande code alsnog dit type TXT-records aanmaken.

dnscmd /RecordAdd maartenvandekamp.nl 2019._domainkey TXT "v=DKIM1; t=s;" "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsNounMXAATZ5rc8NzV3HlB31GT6/fRrbACDCyEXMDrwD84Q79uIFUgflvPbO6BHlmfY73IQVpuV+DAgyTebEjaTD9iatRII/z+5hjv8a4pzuVlnFycKjd0A4btIw3NnCI+rnbUpSNrrFp88bQM/yznxPniAGHzF3Y9Fi3CznoSwnZyvZ0JF81nkwN7R9A7fy86nCAg0bzlE4kh" "IKZ1rIMl4vGvP/ntgh3AxaizrPAzXro9HPeIyAbOaspug1NuW90uTAYy9L/IygX+IjC9nouBo4wqM9uzc/GPNipPjcHGzTECQX+loOkr2rJJ5blGEEciB4djLMDc2r7OECB5f/3QIDAQAB"

Belangrijk is dat er een spatie tussen de aanhalingstekens wordt geplaatst. Dan wordt de tekst op een nieuwe regel geplaatst in de DNS-zone.

Het toevoegen van een reservering

Ik draai PiHole met een uitgebreide lijst, maar daardoor worden een aantal services geblokkeerd die ik op mijn Philips Smart TV graag wel wil gebruiken.

Om het mogelijk te maken dat deze een andere DNS-server toegewezen krijgt, maak ik eerst een reservering voor de TV:

Add-DhcpServerv4Reservation -ScopeId -IPAddress -ClientId "1C-5A-6B-9E-E8-67" -Description "Philips TV"

Het wijzigen van een DHCP option bij een reservering

Nadat ik de reservering heb aangemaakt, wijzig ik DHCP option 6 om de toegewezen DNS-server te wijzigen:

Set-DhcpServerv4OptionValue -ComputerName "core19" -ReservedIP -OptionId 6 -Value ""

Telfort Glasvezel met ASUS RT-AC68U router

Na twee jaar met de Experiabox v8 te hebben gewerkt in combinatie met een Telfort Glasvezel abonnement, is het tijd om deze te vervangen. Ter vervanging van de Experiabox v8 heb ik de ASUS RT-AC68U aangeschaft.

Het belangrijkste is dat internet en IPTV blijven werken. Ik maak geen gebruik van telefonie, waardoor VOIP niet in deze uitleg wordt meegenomen.

Nu ben ik niet de eerste die de waardeloze Experiabox v8 wil vervangen, dus er zijn genoeg fora te vinden waarop wordt uitgelegd hoe je de router moet inrichten om te zorgen dat het probleemloos werkt.

Deze instructie is gebaseerd op dit forumthread van Tweakers


Telfort heeft – net als KPN – het netwerk opgedeeld in VLAN’s. Hierdoor kan het meerdere diensten over één verbinding aanbieden, zonder dat deze last hebben van elkaar.

Telfort gebruikt de volgende VLAN’s:

  • 4 – IPTV
  • 7 – VOIP (wordt niet gebruikt in deze handleiding)
  • 34 – Internet

De ASUS router gaat straks deze verschillende VLAN’s scheiden en zorgen dat het netwerkverkeer op de juiste plek terecht komt.

Routed vs Bridged

Het is mogelijk om op twee manieren de verbinding voor internet en IPTV in te stellen.


In Bridged mode configureer je de router via de webinterface. Daarin wordt ingesteld welk VLAN voor het internet is en welke voor IPTV. De router zorgt ervoor dat het juiste VLAN aan een poort wordt gekoppeld.

In Bridged mode werken niet alle functies op de settopbox die Telfort meelevert. Zo werkt On Demand niet, en Apps op TV is ook niet te gebruiken.

Dit wordt niet gebruikt.


In Routed mode configureer je de router voornamelijk via de CLI d.m.v. een SSH-verbinding of Telnet.

In Routed mode krijgt de settopbox een IP-adres van de DHCP-server in het netwerk, en zorgt de router ervoor dat het verkeer van IPTV wordt gescheiden van het internetverkeer.

Hierdoor kan de settopbox verbinding maken met diensten die niet via het VLAN van IPTV wordt aangeboden. Zo werkt via Routed mode de eerder genoemde On Demand en Apps op TV zonder problemen.

Configuratie van ASUS RT-AC68U


Het eerste deel van de configuratie vind plaats in de webinterface van de router. Open daarvoor de webinterface van de router.

  • Navigeer naar LAN > IPTV
  • Selecteer bij ISP Profile: Manual Setting
  • Vul bij Internet het VID 34 in, en bij PRIO 1
  • Selecteer bij Use DHCP routes: RFC3442 & Microsoft
  • Selecteer bij Enable multicast routing (IGMP Proxy): Enable
  • Selecteer bij Enable efficient multicast forwarding (IGMP Snooping): Enable
  • Klik op Apply

MAC-adres wijzigen

De Experiabox heeft verschillende MAC-adressen. Die worden gebruikt voor de verschillende onderdelen. Het MAC-adres wat nodig is voor de internetverbinding is die van het WAN MAC Adress.

Je vindt het MAC-adres van de Experiabox door in te loggen op de webinterface, rechts onder het kopje INFORMATION.

Afbeelding van https://experiabox-bridge-modus.weebly.com/. Het gaat om het MAC Address wat in rood gekaderd is.

Om het MAC-adres van de Experiabox mee te sturen op de internetverbinding van de ASUS router:

  • Ga naar WAN
  • Plaats bij MAC Address het MAC-adres van de Experiabox. Vervang de streepjes voor :, anders zal de router het adres niet accepteren.
  • Klik op Apply

SSH activeren

De bestanden zijn het eenvoudigst op de router te plaatsen d.m.v. een SSH-verbinding. Standaard staat SSH uitgeschakeld. Zo schakel je SSH in:

  • Ga naar Administration > System
  • Selecteer bij Enable SSH: LAN only
  • Klik op Apply

Bestanden overzetten via WinSCP

Nu is het tijd om de bestanden – hier te downloaden – over te zetten. Het gaat om verschillende bestanden in verschillende mappen, in de map /jffs/.

  • .asusrouter (bestand)
  • configs (map)
    • igmpproxy.conf (bestand)
    • dnsmasq.conf.add (bestand)
  • scripts (map)
    • services-start (bestand)
    • vlan4.script (bestand)

De bestanden zijn geconfigureerd voor de ASUS RT-AC68U. Je hoeft niets aan te passen om het werkend te maken.


Deze handleiding gaat ervan uit dat het netwerk met subnet wordt gebruikt. Dit is standaard.

Indien het subnet waarin de ASUS RT-AC68U wordt geplaatst groter of kleiner is, dan moet het broadcastadres in dnsmasq.conf.add gewijzigd worden naar het juiste broadcastadres.

Anders kan de settopbox na uitschakeling geen verbinding meer tot stand brengen.

Scripts uitvoerbaar maken

Om de scripts uitvoerbaar te maken dienen de permissies gewijzigd te worden. Gebruik hiervoor het commando chmod.

Zorg dat de permissies overeenkomen met onderstaande tabel.



Nu is het tijd om te testen of de instellingen goed zijn geconfigureerd.


  • Controleer of de VLAN voor Internet goed is ingevuld in de webinterface
  • Controleer of alle bestanden in de juiste mappen staan
  • Controleer of de permissies goed zijn ingesteld

Herstart de router en houdt de logs goed in de gaten. Je vindt de logs bij System Log.


Als blijkt dat alles goed werkt, dan is het tijd om SSH weer uit te schakelen. Open de webinterface

  • Ga naar Administration > System
  • Selecteer bij Enable SSH: No
  • Klik op Apply

Veel kijkplezier!

Switch from Certbot to acme.sh

I normally use Certbot to issue and install the free Let’s Encrypt certificates. But I haven’t found a, or there is no, convenient way to issue ECC-certificates with Certbot. For that reason I switched from Certbot to acme.sh.

With acme.sh I can generate ECC certificates, without having to generate all kinds of extra files before I receive the right type of certificate.

So here’s what I did to change from Certbot issuing my certificates, to acme.sh. I use nginx as a webserver, and I have to make some changes in the config as well.

Install acme.sh

wget -O -  https://get.acme.sh | sh

Revoke the current certificate from Certbot

Next, I revoke the certificate I’m currently using from Certbot.

certbot revoke --cert-path /etc/letsencrypt/archive/mvandek.nl/cert1.pem

Issue a new certificate

I use acme.sh to issue a new certificate, which will be later used by nginx to encrypt the connection between browser and server. I use an elliptic curve (ec-384) to create an ECC-certificate.

acme.sh --issue -d mvandek.nl --keylength ec-384 -w /home/mvandek/mvandek.nl

Change the virtual host config of nginx

nano /etc/nginx/sites-enabled/ssl.mvandek.nl

There I find these rules:

ssl_certificate /etc/letsencrypt/live/mvandek.nl/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mvandek.nl/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mvandek.nl/chain.pem;

I changed them into:

ssl_certificate /etc/ssl/acme/mvandek.nl/ecc-fullchain.pem;
ssl_certificate_key /etc/ssl/acme/mvandek.nl/ecc-key.pem;
ssl_trusted_certificate /etc/ssl/acme/mvandek.nl/ecc-cert.pem;

Do not restart nginx. The ‘old’ Certbot certificates are still used by nginx, so you still can connect to the website, even while the certificates are already revoked.

Now you have to create the folder in which the new certificates will be installed, and from where nginx will load the new issued certificates.

Create directory for certificates

First, create a folder called acme inside /etc/ssl/. Then, accordingly to the domain name, create a folder where the certificates will be stored. In this case, that folder will be named mvandek.nl.

In short:

mkdir -p /etc/ssl/acme/mvandek.nl

Install the issued certificates

The following code will install the certificate for the domain mvandek.nl. It knows it’s an ECC-certificate because of the –ecc parameter. When the files are installed, nginx will be restarted to load the new certificates.

acme.sh --install-cert -d mvandek.nl --ecc \
--cert-file /etc/ssl/acme/mvandek.nl/ecc-cert.pem \
--key-file /etc/ssl/acme/mvandek.nl/ecc-key.pem \
--fullchain-file /etc/ssl/acme/mvandek.nl/ecc-fullchain.pem \
--reloadcmd "systemctl restart nginx.service"