Certbot SSL: automatische certificaten met Let's Encrypt

Certbot SSL instellen is de kortste weg naar gratis, automatische HTTPS op een VPS. Certbot is de officiële client van Let's Encrypt: het haalt het certificaat op, past je webserverconfiguratie aan en — het belangrijkste — vernieuwt het certificaat vanzelf voordat het verloopt. In deze gids loop ik door hoe de tool werkt, welke plugin je wanneer kiest, DNS-validatie voor wildcardcertificaten, deploy hooks, en hoe je vernieuwing echt waterdicht maakt.

Hoe Certbot werkt: challenges en plugins

Om aan Let's Encrypt te bewijzen dat het domein echt onder jouw beheer staat, lost Certbot een challenge op. Er zijn twee veelvoorkomende soorten: HTTP-01-validatie serveert een tijdelijk bestand via poort 80, terwijl DNS-01-validatie een tijdelijk TXT-record aan je domein toevoegt. Losse domeinen gebruiken meestal HTTP-01, terwijl wildcardcertificaten (*.voorbeeld.com) DNS-01 vereisen.

Certbot doet dit via plugins. Er zijn twee soorten: een authenticator (die de validatie uitvoert — bijv. nginx, apache, webroot, standalone) en een installer (die het certificaat in je configuratie plaatst — bijv. nginx, apache). De plugins nginx en apache vervullen beide rollen, wat ze de eenvoudigste route maakt.

Certbot installeren

De aanbevolen installatie is het snap-pakket; het levert altijd de nieuwste versie en stelt automatisch de vernieuwingstimer in. Op Ubuntu/Debian:

sudo apt update
sudo apt install snapd -y
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Wil je snap liever vermijden, installeer dan vanuit de repository's van je distributie: sudo apt install certbot python3-certbot-nginx (of python3-certbot-apache voor Apache). De versie is misschien wat ouder maar werkt prima. Controleer met certbot --version.

De eenvoudigste route: de nginx/apache-plugin

Op een server waarop Nginx al draait, haalt één commando zowel het certificaat op als voegt het het HTTPS-blok aan je config toe:

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

Bij de eerste keer vraagt Certbot om een e-mailadres (voor vernieuwingswaarschuwingen) en om de servicevoorwaarden te accepteren. Daarna vraagt het of HTTP naar HTTPS moet worden omgeleid — kies "Redirect". De logica is identiek voor Apache, alleen de plugin verandert:

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

Op Apache schakelt Certbot mod_ssl en mod_rewrite in, maakt het een SSL virtual host-bestand aan en voegt de omleidingsregel toe. Test en herlaad de config op Nginx na afloop met sudo nginx -t && sudo systemctl reload nginx.

certonly en webroot: een certificaat zonder je config aan te raken

Soms wil je niet dat Certbot je webserverbestanden aanpast — de configuratie is complex, of je zit achter een reverse proxy. In dat geval haalt het subcommando certonly alleen het certificaat op en laat het de installatie aan jou over. De veiligste authenticator is webroot, want die schrijft de validatiebestanden in je bestaande document root zonder de draaiende server te stoppen:

sudo certbot certonly --webroot \
  -w /var/www/voorbeeld \
  -d voorbeeld.com -d www.voorbeeld.com

Hier wijst -w naar de document root van je site; Certbot plaatst de validatiebestanden eronder in /.well-known/acme-challenge/. Draait er nog geen webserver (poort 80 is vrij), gebruik dan de standalone-plugin, die zijn eigen tijdelijke server opstart voor de duur van de challenge:

sudo certbot certonly --standalone -d voorbeeld.com

De verkregen bestanden staan onder /etc/letsencrypt/live/voorbeeld.com/: fullchain.pem (certificaat + tussenliggende keten) en privkey.pem (privésleutel). In je Nginx-config wijs je de directives ssl_certificate en ssl_certificate_key naar deze twee paden.

Wildcardcertificaten: DNS-01-validatie

Om elk subdomein onder *.voorbeeld.com met één certificaat te dekken heb je een wildcardcertificaat nodig, en Let's Encrypt geeft die alleen uit via DNS-01. De eenvoudigste vorm is handmatige validatie:

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

Certbot geeft je een TXT-record (_acme-challenge.voorbeeld.com); dat voeg je toe in je DNS-paneel, je wacht tot het is verspreid en je gaat verder. Omdat de handmatige aanpak je bij elke vernieuwing dwingt in te grijpen, is het in productie veel praktischer om de officiële plugin van je DNS-provider te gebruiken. Voor Cloudflare bijvoorbeeld, met een API-token:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d "*.voorbeeld.com" -d "voorbeeld.com"

Zo wordt het TXT-record automatisch aangemaakt en verwijderd, en wordt het vernieuwen van het wildcardcertificaat volledig handenvrij.

Automatische vernieuwing en deploy hooks

Let's Encrypt-certificaten zijn 90 dagen geldig, dus Certbots waardevolste taak is vernieuwing. De snap- of pakketinstallatie stelt een systemd timer (of cron-taak) in die twee keer per dag draait en vernieuwt zodra het certificaat in zijn laatste 30 dagen komt. Controleer of die actief is:

systemctl list-timers | grep certbot

Om te testen dat vernieuwing werkt zonder echt te vernieuwen, is een proefdraai essentieel:

sudo certbot renew --dry-run

Voltooit dat commando zonder fouten, dan is vernieuwing veilig. Eén belangrijk punt: na vernieuwing moet de webserver het nieuwe certificaat in het geheugen laden. De plugins nginx/apache doen dit zelf, maar als je handmatig met certonly hebt geïnstalleerd, definieer dan een deploy hook:

sudo certbot certonly --webroot -w /var/www/voorbeeld \
  -d voorbeeld.com \
  --deploy-hook "systemctl reload nginx"

De deploy hook draait alleen wanneer het certificaat daadwerkelijk is vernieuwd, dus herlaadt hij de service niet onnodig. De vernieuwingsinstellingen van een bestaand certificaat staan in /etc/letsencrypt/renewal/voorbeeld.com.conf; je kunt de deploy hook daar ook met de hand toevoegen.

Veelvoorkomende fouten

Validatie mislukt (timeout): meestal wijst DNS nog niet naar je server, of zijn poorten 80/443 dicht. Controleer het IP met dig +short voorbeeld.com en de poorten in je firewall.
Rate limit: Let's Encrypt hanteert wekelijkse limieten. Gebruik tijdens het afstellen --dry-run of de --staging-omgeving; geen van beide verbruikt de echte limiet.
"too many redirects": als zowel Certbot als een CDN (bijv. Cloudflare "Flexible SSL") omleiden, krijg je een lus. Zet de SSL-modus van het CDN op "Full (strict)".
Vernieuwing faalt stilletjes: draai regelmatig certbot renew --dry-run; als het webroot-pad is veranderd of een hook stuk is, zie je dat hier.

Veelgestelde vragen

Wat is het verschil tussen Certbot en Let's Encrypt?

Let's Encrypt is de gratis certificaatautoriteit (CA) die het certificaat uitgeeft. Certbot is de clientsoftware die via het ACME-protocol met die CA praat: het voert de validatie uit, downloadt het certificaat en vernieuwt het. Andere clients zoals acme.sh doen hetzelfde werk buiten Certbot om.

Hoeveel domeinen passen er op één certificaat?

Door meerdere -d-vlaggen in hetzelfde commando mee te geven, kun je meerdere domeinen (SAN's) aan één certificaat toevoegen; Let's Encrypt ondersteunt tot 100 namen per certificaat. Heb je veel subdomeinen, dan is een wildcardcertificaat meestal een nettere oplossing.

Wat als ik een certificaat moet intrekken?

Lekt de privésleutel, trek het dan in met sudo certbot revoke --cert-name voorbeeld.com en ruim daarna de vernieuwingsconfig op met certbot delete. Bij normaal gebruik is intrekken niet nodig; verlopen certificaten verliezen vanzelf hun geldigheid.

Wil je Certbot SSL van nul af aan op je server laten instellen? Ik kan het hele proces voor je regelen — pluginkeuze, wildcardcertificaten, deploy hooks en ononderbroken vernieuwing. Neem contact op.