Een website via HTTPS aanbieden betekent dat je een geldig SSL/TLS-certificaat nodig hebt. Een populaire gratis oplossing hiervoor is Let’s Encrypt, vaak in combinatie met Certbot.

In deze praktische handleiding bekijken we hoe je:

  • Certbot installeert;
  • bestaande certificaten controleert;
  • een nieuw certificaat aanvraagt;
  • een certificaat handmatig vernieuwt;
  • een wildcardcertificaat met DNS-validatie aanvraagt;
  • controleert of een DNS-wijziging is doorgekomen;
  • controleert welk certificaat je webserver daadwerkelijk gebruikt.

Let op: voorbeelden kunnen per Linux-distributie, DNS-provider en webserver enigszins verschillen. Maak bij wijzigingen aan een productieserver altijd eerst een backup van belangrijke configuratiebestanden.

1. Controleren of Certbot geïnstalleerd is

Controleer eerst of Certbot aanwezig is:

certbot --version

Je krijgt bijvoorbeeld:

certbot 2.x.x

Is Certbot niet geïnstalleerd, dan kun je op Debian/Ubuntu eerst bekijken welke Certbot-pakketten beschikbaar zijn:

apt search certbot

Een veelgebruikte installatie voor Apache is:

sudo apt install certbot python3-certbot-apache

Voor Nginx:

sudo apt install certbot python3-certbot-nginx

Controleer daarna opnieuw:

certbot --version

2. Bestaande certificaten bekijken

Certbot kan laten zien welke certificaten het beheert:

sudo certbot certificates

Je krijgt informatie te zien zoals:

Certificate Name: example.com
Domains: example.com www.example.com
Expiry Date: 2026-10-20
Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem

Let vooral op:

  • Certificate Name
  • Domains
  • Expiry Date
  • Certificate Path
  • Private Key Path

Staat bij de vervaldatum bijvoorbeeld:

INVALID: EXPIRED

dan is het certificaat verlopen.

3. Een certificaat aanvragen voor Apache

Wanneer je Apache gebruikt en de website al correct bereikbaar is via HTTP, kan Certbot veel werk automatisch uitvoeren.

Bijvoorbeeld:

sudo certbot --apache -d example.com -d www.example.com

Certbot probeert vervolgens:

  1. het domein te valideren;
  2. het certificaat aan te vragen;
  3. Apache te configureren;
  4. HTTPS te activeren.

Controleer na afloop de Apache-configuratie:

sudo apachectl configtest

Bij een correcte configuratie krijg je:

Syntax OK

Daarna kun je Apache veilig herladen:

sudo systemctl reload apache2

4. Een certificaat aanvragen voor Nginx

Voor Nginx werkt hetzelfde principe:

sudo certbot --nginx -d example.com -d www.example.com

Controleer daarna eerst de configuratie:

sudo nginx -t

Bij een correcte configuratie kun je Nginx herladen:

sudo systemctl reload nginx

5. Wildcardcertificaten

Soms wil je niet alleen:

example.com
www.example.com

beveiligen, maar ook allerlei subdomeinen:

blog.example.com
forum.example.com
cloud.example.com

Daarvoor kun je een wildcardcertificaat gebruiken:

*.example.com

Een belangrijk verschil is dat Let’s Encrypt voor wildcardcertificaten DNS-validatie (DNS-01) vereist.

Een handmatige aanvraag kan bijvoorbeeld zo:

sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com \
  -d "*.example.com"

Het hoofddomein example.com wordt niet automatisch gedekt door *.example.com. Daarom worden beide namen opgenomen.

6. DNS-validatie met een TXT-record

Certbot vraagt je tijdens de DNS-01-validatie om een TXT-record aan te maken.

Dat ziet er ongeveer zo uit:

_acme-challenge.example.com

met een waarde zoals:

abcdefghijklmnopqrstuvwxyz123456789

Log vervolgens in bij de beheeromgeving van je DNS-provider en maak of wijzig het gevraagde TXT-record.

Druk nog niet meteen op Enter in Certbot.

DNS-wijzigingen kunnen tijd nodig hebben om zichtbaar te worden.

7. Controleren of het TXT-record zichtbaar is

Dit is een stap die gemakkelijk wordt overgeslagen.

Controleer eerst vanaf de terminal:

dig TXT _acme-challenge.example.com

Je kunt specifiek het korte antwoord opvragen:

dig +short TXT _acme-challenge.example.com

Als alles goed staat, zie je de door Certbot opgegeven waarde terug:

"abcdefghijklmnopqrstuvwxyz123456789"

Zie je nog de oude waarde of helemaal niets?

Wacht dan en ga nog niet verder in Certbot.

Je kunt eventueel een publieke resolver rechtstreeks controleren:

dig +short TXT _acme-challenge.example.com @1.1.1.1

of:

dig +short TXT _acme-challenge.example.com @8.8.8.8

Wanneer de juiste waarde zichtbaar is, kun je teruggaan naar Certbot en de validatie voortzetten.

8. Een bestaand certificaat vernieuwen

Voor certificaten die automatisch vernieuwd kunnen worden, kun je normaal gesproken gebruiken:

sudo certbot renew

Certbot controleert dan de bekende certificaten en vernieuwt certificaten wanneer dat nodig is.

Wil je controleren of automatische vernieuwing zou werken zonder daadwerkelijk een productiecertificaat te vernieuwen?

Gebruik:

sudo certbot renew --dry-run

Dit is een bijzonder nuttige controle.

9. Handmatige DNS-certificaten zijn anders

Heb je een certificaat gemaakt met:

--manual --preferred-challenges dns

dan is automatische vernieuwing zonder aanvullende automatisering doorgaans niet mogelijk.

Bij een volgende vernieuwing moet je opnieuw:

  1. Certbot starten;
  2. de nieuwe TXT-waarde bekijken;
  3. het TXT-record bij je DNS-provider aanpassen;
  4. wachten tot de nieuwe waarde zichtbaar is;
  5. de wijziging controleren met dig;
  6. Certbot verder laten gaan.

Wil je wildcardcertificaten volledig automatisch vernieuwen, dan kun je bij ondersteunde DNS-providers gebruikmaken van een Certbot DNS-plugin of andere ACME-client met DNS-API-ondersteuning.

10. Na vernieuwing controleren

Controleer na afloop opnieuw:

sudo certbot certificates

Controleer de nieuwe:

Expiry Date

Je kunt ook rechtstreeks het certificaatbestand bekijken:

sudo openssl x509 \
  -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -noout -dates

Je ziet dan bijvoorbeeld:

notBefore=...
notAfter=...

notAfter geeft aan wanneer het certificaat verloopt.

11. Controleer welk certificaat de website daadwerkelijk serveert

Dit is belangrijk.

Het feit dat Certbot een nieuw certificaat heeft aangemaakt, betekent niet automatisch dat je webserver het nieuwe certificaat al gebruikt.

Je kunt het certificaat dat een website via poort 443 aanbiedt controleren met:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

Hiermee controleer je het certificaat dat bezoekers daadwerkelijk ontvangen.

12. Webserver herladen

Wanneer het certificaat vernieuwd is maar de webserver nog het oude certificaat gebruikt, kan een reload nodig zijn.

Voor Apache:

sudo apachectl configtest

Als je:

Syntax OK

krijgt:

sudo systemctl reload apache2

Voor Nginx:

sudo nginx -t

en vervolgens:

sudo systemctl reload nginx

Een reload heeft hierbij meestal de voorkeur boven een restart, omdat bestaande verbindingen doorgaans niet abrupt worden afgebroken.

13. Automatische vernieuwing controleren

Veel Certbot-installaties gebruiken een systemd-timer.

Controleer of die aanwezig is:

systemctl list-timers | grep certbot

Je kunt ook kijken naar:

systemctl status certbot.timer

Wanneer de timer actief is, controleert Certbot periodiek of certificaten vernieuwd moeten worden.

Nogmaals: een certificaat dat met een handmatige DNS-challenge is aangemaakt, kan niet zomaar automatisch worden vernieuwd wanneer voor iedere vernieuwing handmatig een TXT-record moet worden gewijzigd.

14. Handige commando’s op een rij

Certbot-versie:

certbot --version

Certificaten bekijken:

sudo certbot certificates

Vernieuwing uitvoeren:

sudo certbot renew

Vernieuwing testen:

sudo certbot renew --dry-run

DNS TXT-record controleren:

dig +short TXT _acme-challenge.example.com

Apache-configuratie testen:

sudo apachectl configtest

Nginx-configuratie testen:

sudo nginx -t

Certificaatbestand controleren:

sudo openssl x509 \
  -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -noout -dates

Live certificaat van een website controleren:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

⚠️ Veelgemaakte fouten

Te snel doorgaan na het aanpassen van het TXT-record

Controleer met dig of de nieuwe waarde daadwerkelijk zichtbaar is voordat je Certbot verder laat gaan.

Denken dat *.example.com ook example.com bevat

Dat is niet zo. Neem het hoofddomein afzonderlijk op in het certificaat.

Aannemen dat een nieuw certificaat automatisch actief is

Controleer na afloop welk certificaat daadwerkelijk via poort 443 wordt aangeboden.

certbot renew vertrouwen zonder het ooit te testen

Voer af en toe uit:

sudo certbot renew --dry-run

Dan ontdek je problemen voordat een certificaat daadwerkelijk verloopt.

Verwachten dat een handmatige DNS-challenge automatisch vernieuwt

Voor automatische wildcardvernieuwing heb je normaal gesproken DNS-API-ondersteuning nodig.

🐧 Tot slot

Let’s Encrypt maakt het mogelijk om gratis vertrouwde TLS-certificaten te gebruiken, maar een certificaat aanvragen is slechts de helft van het verhaal.

Vooral bij serverbeheer zijn drie controles belangrijk:

  1. Kan Certbot het certificaat vernieuwen?
  2. Is het nieuwe certificaat daadwerkelijk aangemaakt?
  3. Serveert de webserver ook echt het nieuwe certificaat?

Controleer die drie punten en je voorkomt een groot deel van de verrassingen rond verlopen HTTPS-certificaten.

Heb jij weleens meegemaakt dat een Let’s Encrypt-certificaat onverwacht verliep? Of gebruik je een andere methode om certificaten automatisch te vernieuwen? Deel je ervaringen en tips in de reacties.