Certbot installeren voor Apache op Ubuntu 24.04

Wat u gaat bouwen

Een Apache-website op Ubuntu 24.04 die reageert via HTTPS met een gratis, door browsers vertrouwd Let's Encrypt-certificaat. Dit certificaat wordt uitgegeven door Certbot en automatisch vernieuwd door een systemd-timer waar u niet meer naar om hoeft te kijken. Het commando dat het werk verricht, bestaat uit één regel. Alles wat misgaat, gaat mis vóór die regel: een vhost zonder ServerName, poort 80 die is afgesloten bij de firewall van de provider, of DNS die nog naar de oude server wijst. Deze handleiding besteedt daarom de meeste aandacht aan de randvoorwaarden en benoemt de exacte foutmelding die bij elke fout optreedt.

Twee opmerkingen over de reikwijdte. Als uw webserver nginx is, is het proces vergelijkbaar, maar verschillen de plugin en de configuraties; gebruik in dat geval de nginx-versie van deze handleiding. Als de service die u beveiligt alleen intern toegankelijk is, zoals een beheerpaneel op een privéadres of een staging-omgeving die niemand anders bezoekt, heeft u helemaal geen certificaatautoriteit nodig; een zelfondertekend certificaat vereist minder configuratie en werkt offline.

Vereisten en de drie manieren waarop dit mislukt voordat Certbot überhaupt draait

• Apache bedient uw site al via onversleuteld HTTP. De Apache-plugin van Certbot wijzigt een bestaande site; deze maakt er geen aan. Als u begint met een kale VPS, bouw dan eerst de LAMP-stack op Ubuntu 24.04 en keer daarna terug; deze handleiding is het ontbrekende TLS-hoofdstuk daarvoor.
• Een publiek domein met een A-record naar uw VPS-adres. De HTTP-01 challenge van Let's Encrypt betekent dat hun validatieservers vanaf het internet verbinding maken met uw server: geen NAT-thuisnetwerk zonder port-forwarding, geen .local-namen, geen kale IP-adressen. dig +short example.com moet uw VPS-adres retourneren. Als u het DNS in het afgelopen uur heeft gewijzigd, wacht dan tot de TTL van het oude record is verlopen voordat u een certificaat aanvraagt.
• Als er een AAAA-record bestaat, moet dit correct zijn. Let's Encrypt geeft de voorkeur aan IPv6 wanneer een AAAA-record is gepubliceerd. Een verouderd AAAA-record zorgt voor een mislukte validatie, zelfs als curl vanaf uw laptop (waarschijnlijk via IPv4) prima werkt. Publiceer een correct AAAA-record of helemaal geen.

Poort 80 en 443 moeten openstaan in ufw en in de netwerkfirewall van uw provider; de meeste hostingpanelen hebben een tweede firewall die het besturingssysteem niet ziet. HTTP-01 valideert specifiek via poort 80; u kunt dit niet uitvoeren met alleen poort 443 open.

sudo ufw allow "Apache Full"
sudo ufw status

Als aan deze voorwaarden is voldaan, duurt de hele procedure vijftien minuten, waarvan u er tien besteedt aan lezen.

Snap of apt voor Certbot? Op 24.04 is apt eindelijk in orde

Certbot stapte jaren geleden over op snap-distributie om een goede reden: pakketten in distributies verouderden. Ubuntu 20.04 leverde Certbot 0.40 en daar kwam geen verandering meer in, en het project was het zat om bugs van vijf jaar oud te debuggen. Op 24.04 is die reden komen te vervallen; het archief levert Certbot 2.9.0, een release van de huidige generatie, en unattended-upgrades houdt deze voorzien van patches. Mijn aanbeveling voor dit OS: gebruik apt. U slaat de snapd-daemon over, de Apache-plugin wordt in dezelfde transactie geïnstalleerd en de vernieuwingstimer integreert op de gebruikelijke Debian-manier met systemd.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

Correct resultaat: certbot 2.9.0. Het python3-certbot-apache-pakket is de plugin die uw Apache-configuraties leest en bewerkt; zonder dit pakket faalt certbot --apache met The requested apache plugin does not appear to be installed.

De snap is in twee gevallen nog steeds de juiste keuze: u wilt de nieuwste Certbot op de dag van uitgave, of u heeft een DNS-plugin nodig die alleen als snap wordt gedistribueerd (verschillende certbot-dns-*-providerplugins zijn dat). Als u voor die weg kiest:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Welke u ook kiest, draai ze nooit beide. Twee installaties betekenen twee vernieuwingsschedulers die strijden om /etc/letsencrypt, en de certbot die uw shell vindt in PATH is mogelijk niet degene die uw certificaten beheert. De regel apt remove hierboven is geen optionele versiering.

De vhost-configuratie voor Certbot moet al bestaan, ServerName is hierbij cruciaal

certbot --apache werkt door de virtual host op poort 80 te zoeken waarvan de ServerName of ServerAlias overeenkomt met elk -d domein dat u opgeeft. Het bewijst vervolgens het beheer over het domein via deze host en schrijft daarna een SSL-equivalent van die vhost. Zonder overeenkomende ServerName is er geen match, en de standaard 000-default.conf van Ubuntu wordt geleverd met ServerName uitgeschakeld (commentaar). Die ene regel met commentaar is de meest voorkomende reden waarom het grote commando in deze handleiding faalt.

Geef de site daarom eerst een correcte, op namen gebaseerde vhost voordat u Certbot gebruikt. Maak /etc/apache2/sites-available/example.com.conf aan:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

Schakel deze in en bevestig dat Apache de configuratie inleest en de naam correct naar de vhost routeert:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest moet Syntax OK weergeven. Als het ook AH00558: apache2: Could not reliably determine the server's fully qualified domain name weergeeft, is dat een waarschuwing over de globale ServerName, niet over uw vhost; dit is hier onschadelijk en wordt onderdrukt door echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

De uitvoer van -S is de controle die ertoe doet. U wilt een regel zien zoals port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) met alias www.example.com daaronder; Apache rapporteert de sites-enabled symlink die het daadwerkelijk heeft gelezen, niet het bestand dat u in sites-available heeft bewerkt. Als example.com niet wordt vermeld bij poort 80, zal Certbot deze ook niet vinden.

Het certificaat uitgeven: certbot --apache

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

De eerste uitvoering vraagt om drie zaken: een e-mailadres (gebruikt voor uw ACME-account en dringende CA-berichten; Let's Encrypt verstuurt geen waarschuwingen meer voor verlopen certificaten, dus u bent zelf verantwoordelijk voor het monitoren van vernieuwingen), akkoord gaan met de voorwaarden van Let's Encrypt, en de vraag of u uw e-mailadres wilt delen met de EFF. Er is geen vraag meer over redirects: sinds Certbot 2.0 leidt de Apache-installer HTTP standaard om naar HTTPS, wat de gewenste configuratie is. Gebruik --no-redirect als u daadwerkelijk HTTP nodig heeft om content te blijven serveren.

Een succesvolle afronding ziet er als volgt uit; lees dit zorgvuldig door in plaats van het te scannen:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

Achter dit bericht heeft Certbot vier acties uitgevoerd: de ssl-module van Apache ingeschakeld indien deze nog niet actief was, example.com-le-ssl.conf geschreven (een kopie van uw vhost op *:443 met SSLEngine on en de certificaatpaden), deze ingeschakeld, en een RewriteRule-blok toegevoegd aan de oorspronkelijke poort-80 vhost die al het verkeer met een 301-statuscode doorstuurt naar HTTPS. Uw oorspronkelijke vhost-bestand is bewerkt, niet vervangen, en de SSL-variant bevindt zich ernaast, waar u elke toegevoegde regel kunt inzien.

Waar het certificaat zich daadwerkelijk bevindt en waarom u het nooit moet kopiëren

Alles wordt opgeslagen onder /etc/letsencrypt/live/example.com/: fullchain.pem (het certificaat inclusief de intermediate chain, waarnaar servers moeten verwijzen), privkey.pem (de private key, die alleen leesbaar is voor root), plus cert.pem en chain.pem voor software die de onderdelen afzonderlijk vereist. Dit zijn symbolische koppelingen naar /etc/letsencrypt/archive/. Deze indirectie vormt het vernieuwingsmechanisme: bij vernieuwing worden nieuwe bestanden naar archive/ geschreven en worden de symbolische koppelingen bijgewerkt. Laat andere software naar de live/-paden verwijzen en deze zal automatisch de vernieuwde certificaten gebruiken. Kopieert u de bestanden naar een andere locatie, dan creëert u na 90 dagen een storing.

Het andere relevante bestand is authenticator = apache, dat vastlegt hoe dit certificaat is uitgegeven, inclusief /etc/letsencrypt/renewal/example.com.conf, installer = apache en de domeinnamen. Hierdoor kan de vernieuwing onbeheerd worden herhaald, inclusief het herladen van Apache na afloop.

Vernieuwing is al gepland, verifieer dit, bouw het niet opnieuw

Let's Encrypt-certificaten zijn standaard 90 dagen geldig en het apt-pakket heeft de benodigde infrastructuur al geïnstalleerd: een systemd-timer die Certbot tweemaal per dag op willekeurige tijdstippen uitvoert en elk certificaat vernieuwt dat binnen 30 dagen verloopt. Voeg hier geen extra cron-job aan toe; een tweede scheduler voegt niets toe behalve log-ruis en blootstelling aan rate-limits.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

Het eerste commando toont de actieve timer, met een NEXT-tijd ergens in de komende 24 uur. Het schema is tweemaal daags met een willekeurige vertraging, dus het exacte tijdstip is bewust onvoorspelbaar (bij de snap-installatie is de timer snap.certbot.renew.timer). De dry run voert een volledige vernieuwingsrepetitie uit tegen de staging-omgeving van Let's Encrypt; dit is een echte challenge, maar er wordt geen certificaat uitgegeven en het kost geen rate-limit. Een correct resultaat eindigt met:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Als de dry run faalt, zal de echte vernieuwing over ~60 dagen op dezelfde manier falen. Los dit nu op, terwijl het huidige certificaat nog zijn volledige levensduur voor zich heeft. De gebruikelijke boosdoener is een firewall-regel die na de uitgifte is toegevoegd en poort 80 weer heeft gesloten.

Verificatie met curl en de status van het hangslot

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

De eerste opdracht moet HTTP/1.1 301 Moved Permanently retourneren met een Location: https://example.com/-header; dit is de redirect die door Certbot is geïnstalleerd. De tweede opdracht moet HTTP/1.1 200 OK retourneren zonder TLS-foutmeldingen van curl. De derde opdracht toont de uitgever, een O = Let's Encrypt-regel met een korte CN zoals R12 of E7, en een notAfter die ongeveer 90 dagen in de toekomst ligt. In een browser ziet u het hangslot; als u hierop klikt, wordt dezelfde uitgever getoond. Als curl correct werkt maar de browser een waarschuwing geeft, bekijkt u vrijwel zeker een gecachte pagina of gebruikt u de verkeerde hostnaam; er is dan geen sprake van een certificaatprobleem.

Meerdere sites: één SAN-certificaat of één certificaat per site

Beide methoden werken en vernieuwen op dezelfde wijze. Voor ongerelateerde sites op dezelfde server voert u het uitgiftecommando per site uit; elke site krijgt zijn eigen map onder live/ en een eigen configuratie voor vernieuwing. Een probleem met één domein blokkeert hierdoor nooit de vernieuwing van de andere domeinen. Dit is mijn standaardwerkwijze.

Voor één site met meerdere namen plaatst u deze op één SAN-certificaat; een enkel certificaat kan tot 100 namen bevatten. U heeft dit hierboven al gedaan met example.com en www.example.com. Om later een naam aan een bestaand certificaat toe te voegen, vraagt u het certificaat opnieuw aan door de naam van het certificaat en de volledige nieuwe lijst op te geven:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot detecteert de gewijzigde domeinset, vraagt u om de uitbreiding te bevestigen en vervangt het certificaat op de huidige locatie, met hetzelfde live/-pad, waardoor er niets anders aangepast hoeft te worden. Let op: de lijst is een vervanging, geen toevoeging. Als u www weglaat uit dat commando, wordt dit domein stilletjes uit het nieuwe certificaat verwijderd.

Wildcards vereisen DNS-01, en meestal heeft u geen wildcard nodig

HTTP-01 kan geen *.example.com uitgeven; het plaatsen van een bestand op een webserver bewijst controle over één hostnaam, niet over een volledige namespace. Wildcards vereisen de DNS-01 challenge: Certbot plaatst een TXT-record op _acme-challenge.example.com. In de praktijk betekent dit een certbot-dns-*-plugin met API-inloggegevens voor uw DNS-provider, of het handmatig bewerken van TXT-records bij elke vernieuwing met --manual (dit is onwerkbaar, plan hier niet op). De volledige handleiding, van de werking van TXT-records tot een plugin die vernieuwingen onbeheerd uitvoert, vindt u in wildcardcertificaten met Certbot via DNS-01. Eerlijk advies: als u vier bekende subdomeinen heeft, is een SAN-certificaat met alle vier de domeinen eenvoudiger dan een wildcard en hoeven er geen DNS API-keys op de server te staan.

Foutmodi en de bijbehorende meldingen

Certbot weigert te starten omdat de configuratie van Apache defect is.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

De plugin voert configtest uit voordat er wijzigingen worden aangebracht en breekt het proces af als Apache zelf niet correct functioneert. De \ns zijn letterlijk, omdat Certbot de repr van de exceptie afdrukt. Voer zelf sudo apache2ctl configtest uit: dit commando toont het bestand en de regel, meestal een typefout door handmatige bewerking, een SSLCertificateFile die naar een niet-bestaand pad verwijst, of een module die wel wordt aangeroepen maar niet is ingeschakeld. Herstel de fout totdat het commando Syntax OK weergeeft en voer Certbot daarna opnieuw uit.

Geen enkele vhost komt overeen met het domein.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

Dit is de eerder genoemde ontbrekende ServerName-fout, die tijdens de uitgifte wordt gedetecteerd. Certbot heeft elke ingeschakelde poort 80 vhost doorzocht naar een ServerName/ServerAlias die overeenkomt met uw -d, maar vond niets. sudo apache2ctl -S toont wat Apache daadwerkelijk routeert; voeg de ServerName-regel toe aan de juiste vhost, herlaad de configuratie en probeer het opnieuw. Een veelvoorkomend gerelateerd probleem is dat de validatie de verkeerde vhost bereikt; het challenge-antwoord komt terug als Invalid response ... 404 omdat een andere site het verzoek heeft opgevangen. Dezelfde diagnose en hetzelfde hulpmiddel zijn van toepassing: apache2ctl -S.

Validatie verloopt door een time-out.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let's Encrypt kon geen TCP-verbinding openen op poort 80 naar het adres dat uw DNS adverteert. In volgorde van waarschijnlijkheid: de netwerkfirewall van uw provider (los van ufw, geconfigureerd in het hostingpaneel), een ufw-regelset die alleen poort 443 of SSH toestaat, DNS die nog naar een oude server wijst, of het verouderde-AAAA-probleem waarbij hun servers IPv6 probeerden terwijl die van u alleen op IPv4 antwoordt. Test vanaf een locatie buiten de VPS: curl -I http://example.com vanaf uw laptop reproduceert wat hun validator ziet.

U bent door herhaaldelijk proberen tegen een rate limit aangelopen.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt staat 5 mislukte validaties per hostnaam per account per uur toe. Sinds hun rate-limit-herziening in 2025 werkt dit als een emmer die langzaam bijvult, waarbij u ongeveer elke 12 minuten één nieuwe poging terugverdient. Het herhaaldelijk proberen bij een defecte firewall verbruikt dit quotum snel. Wachten is een oplossing, maar de juiste aanpak is gedragsmatig: debug na elke fout met de staging-omgeving totdat het proces slaagt.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

Let op de certonly: --dry-run wordt alleen geaccepteerd door de certonly- en renew-subcommando's, en de kale certbot --apache --dry-run-vorm weigert volledig te draaien met de melding --dry-run currently only works with the 'certonly' or 'renew' subcommands. De dry run valideert tegen de staging-omgeving, die eigen ruime limieten heeft en geen echte certificaten uitgeeft, waardoor u daar de hele middag kunt testen. Voer het echte commando pas opnieuw uit zodra de staging-test slaagt. De overige limieten, 50 certificaten per geregistreerd domein per week en 5 duplicaten van dezelfde naamset per week, zult u alleen bereiken als een script in een lus certificaten blijft aanvragen.

Zodra HTTPS actief is, onthoud dan dat het certificaat het transport beveiligt, niet de server zelf: poort 22 blijft de hele dag kwetsbaar voor wachtwoordpogingen. Het combineren hiervan met Fail2ban op Ubuntu 24.04 is de logische volgende stap voor de komende dertig minuten.

FAQ

Moet ik Certbot installeren via snap of apt voor Apache op Ubuntu 24.04?

Gebruik apt. Ubuntu 24.04 levert Certbot 2.9.0, wat actueel genoeg is voor alles in deze handleiding, beveiligingspatches ontvangt via unattended-upgrades en geen snapd vereist. Kies alleen voor de snap als u direct de nieuwste release nodig heeft of een DNS-plugin die uitsluitend als snap wordt gedistribueerd. Als u overstapt, verwijder dan eerst apt remove certbot python3-certbot-apache zodat er nooit twee vernieuwingsschema's naast elkaar bestaan.

Waarom meldt Certbot "Unable to find a virtual host listening on port 80"?

Omdat geen enkele ingeschakelde vhost op poort 80 een ServerName of ServerAlias bevat die overeenkomt met het domein dat u heeft opgegeven met -d. De standaard vhost van Ubuntu wordt geleverd met ServerName in commentaar. Voer sudo apache2ctl -S uit, zoek (of maak) de vhost die de naam moet beheren, voeg ServerName example.com toe, herlaad Apache en voer Certbot opnieuw uit.

Hoe los ik "Timeout during connect (likely firewall problem)" op?

Let's Encrypt kon poort 80 niet bereiken op het adres dat uw DNS publiceert. Controleer zowel de netwerkfirewall in het paneel van uw provider als ufw. Bevestig dat dig +short example.com deze VPS retourneert en verwijder of corrigeer eventuele verouderde AAAA-records; validatie geeft de voorkeur aan IPv6 wanneer dit aanwezig is. Bevestig de oplossing van buiten de server met curl -I http://example.com en oefen daarna met sudo certbot certonly --apache --dry-run -d example.com voordat u de definitieve uitgifte aanvraagt.

Vernieuwt Certbot certificaten automatisch op Ubuntu 24.04?

Ja. Het apt-pakket installeert certbot.timer, een systemd-timer die tweemaal daags draait en elk certificaat dat binnen 30 dagen verloopt vernieuwt, waarna Apache wordt herladen; de snap gebruikt snap.certbot.renew.timer voor dezelfde taak. Controleer dit met systemctl list-timers certbot.timer en oefen met sudo certbot renew --dry-run; voeg hiernaast geen eigen cron-job toe.

Hoe krijg ik een wildcard-certificaat met Certbot en Apache?

Wildcards vereisen de DNS-01 challenge: Certbot moet een TXT-record plaatsen bij _acme-challenge.example.com. Dit betekent dat u een certbot-dns-*-plugin met API-inloggegevens voor uw DNS-provider nodig heeft (het --manual-alternatief vereist bij elke vernieuwing handmatig bewerkte TXT-records). Als u slechts een handvol bekende subdomeinen heeft, is een SAN-certificaat waarin deze expliciet worden vermeld eenvoudiger en houdt het DNS API-sleutels van de server af.