Certbot installeren op Ubuntu 24.04 met Apache

Wat u bouwt

Een Apache-site 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 die u niet handmatig hoeft te beheren. De opdracht die het werk uitvoert, bestaat uit één regel. Alle fouten treden op voordat die regel wordt uitgevoerd: een vhost zonder ServerName, poort 80 die gesloten is in de firewall van de provider, of DNS dat nog naar de oude server wijst. Daarom richt deze gids zich voornamelijk op de randvoorwaarden en vermeldt deze de exacte foutmelding die bij elke fout optreedt.

Twee opmerkingen over de reikwijdte. Als uw webserver nginx is, is de procedure hetzelfde, maar verschillen de plugin en de configuraties — gebruik in dat geval de nginx-versie van deze gids. En als het doel dat u wilt beveiligen uitsluitend intern is — zoals een admin-paneel op een privé-adres of een staging-server die niemand anders bezoekt — dan heeft u geen certificeringsinstantie nodig; een self-signed certificate vereist minder configuratie en werkt offline.

Vereisten, en de drie redenen waarom dit mislukt voordat Certbot wordt uitgevoerd

• Apache dient uw website al via plain HTTP. De Apache-plugin van Certbot bewerkt een bestaande website; deze maakt geen nieuwe website aan. Als u begint met een lege VPS, installeer dan eerst de LAMP stack op Ubuntu 24.04 en kom daarna terug — deze handleiding is het ontbrekende TLS-hoofdstuk.
• Een publiek domein met een A-record dat naar uw VPS-adres verwijst. De HTTP-01 challenge van Let's Encrypt betekent dat hun validatieservers via het internet verbinding maken met uw machine: geen NAT-omgeving zonder port forwarding, geen .local namen, geen directe IP-adressen. dig +short example.com moet uw VPS-adres retourneren. Als u de DNS in het afgelopen uur heeft gewijzigd, wacht dan tot de TTL van het oude record is verstreken voordat u de certificaten aanvraagt.
• Als 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 — correct werkt. Publiceer een correct AAAA-record of publiceer helemaal geen AAAA-record.

Poorten 80 en 443 moeten openstaan in ufw en in de netwerkfirewall van uw provider — de meeste hostingpanels 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.

sudo ufw allow "Apache Full"
sudo ufw status

Als deze zaken op orde zijn, duurt de hele taak vijftien minuten, waarvan tien minuten lezen zijn.

Snap of apt Certbot? Op 24.04 is apt eindelijk goed

Certbot is jaren geleden overgestapt op snap-distributie om een goede reden: distro-packages raakten verouderd. Ubuntu 20.04 leverde Certbot 0.40 en bleef niet updaten, waardoor het project moe werd van het debuggen van vijf jaar oude bugs. Op 24.04 vervalt deze reden — het archief levert Certbot 2.9.0, een release van de huidige generatie, en unattended-upgrades houdt het up-to-date. Mijn advies voor dit OS: gebruik apt. U omzeilt de snapd daemon, de Apache-plugin wordt in dezelfde transactie geïnstalleerd, en de renewal timer integreert met systemd op de standaard Debian-manier.

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 nog steeds de juiste keuze in twee gevallen: u wilt de nieuwste Certbot direct bij de release, of u heeft een DNS-plugin nodig die alleen als snap wordt gedistribueerd (meerdere van de certbot-dns-* provider-plugins 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, gebruik nooit beide. Twee installaties betekenen twee renewal schedulers die strijden om /etc/letsencrypt, en de certbot die uw shell vindt in PATH is mogelijk niet de versie die uw certificaten beheert. De apt remove regel hierboven is geen optionele versiering.

De vhost Certbot-wijzigingen moeten al bestaan — ServerName is essentieel

certbot --apache werkt door de virtual host op port-80 te zoeken waarvan de ServerName of ServerAlias overeenkomt met elke -d domain die u opgeeft. Hiermee wordt de controle over het domein bewezen en wordt er een SSL-kopie van die vhost geschreven. Zonder een overeenkomende ServerName is er geen match — en de standaard 000-default.conf van Ubuntu heeft ServerName uitgeschakeld (commented out). Die enkele uitgeschakelde regel is de meest voorkomende reden waarom de grote opdracht in deze handleiding mislukt.

Geef de website daarom een correcte naamgebaseerde 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 controleer of Apache de configuratie correct verwerkt en de naam hiernaartoe routeert:

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

configtest moet Syntax OK weergeven. Als ook AH00558: apache2: Could not reliably determine the server's fully qualified domain name wordt weergegeven, is dit een waarschuwing over de globale ServerName en 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 -S output is de controle die ertoe doet. U wilt een regel als port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) met alias www.example.com daaronder zien — Apache rapporteert de sites-enabled symlink die daadwerkelijk is gelezen, niet het bestand dat u heeft bewerkt in sites-available. Als example.com niet wordt vermeld bij port 80, kan Certbot het ook niet vinden.

Het certificaat genereren: certbot --apache

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

De eerste uitvoering stelt drie vragen: een e-mailadres (gebruikt voor uw ACME-account en dringende CA-meldingen; Let's Encrypt stuurt geen waarschuwingen voor verlopen certificaten meer, dus u moet zelf de verlengingen monitoren), akkoord gaan met de voorwaarden van Let's Encrypt, en of u uw e-mailadres wilt delen met de EFF. Er is geen vraag meer over redirects: sinds Certbot 2.0 redirect de Apache-installer HTTP standaard naar HTTPS, wat de gewenste werking is. Gebruik --no-redirect als u echt plain HTTP nodig heeft om content te blijven serveren.

Een succesvolle uitvoering ziet er als volgt uit. Lees deze tekst zorgvuldig door:

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

Certbot heeft vier acties uitgevoerd achter deze melding: de Apache ssl module ingeschakeld als deze nog niet actief was, example.com-le-ssl.conf geschreven — een kopie van uw vhost op *:443 met SSLEngine on en de certificaatpaden — de module geactiveerd, en een RewriteRule blok toegevoegd aan de originele port-80 vhost dat alles via een 301 redirect naar HTTPS stuurt. Uw originele vhost-bestand wordt aangepast en niet vervangen. De SSL-versie wordt naast het origineel geplaatst, zodat u elke toegevoegde regel kunt controleren.

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

Alles staat onder /etc/letsencrypt/live/example.com/: fullchain.pem (het certificaat inclusief de intermediate chain — waar servers naar moeten verwijzen), privkey.pem (de private key, alleen leesbaar voor root), plus cert.pem en chain.pem voor software die de onderdelen afzonderlijk nodig heeft. Dit zijn symlinks naar /etc/letsencrypt/archive/. Deze indirecte verwijzing is de werking van de vernieuwing: bij een vernieuwing worden nieuwe bestanden naar archive/ geschreven en worden de symlinks bijgewerkt. Wijs andere software naar de live/ paden; dan worden vernieuwingen automatisch verwerkt. Kopieert u de bestanden naar een andere locatie, dan veroorzaakt u een downtime over 90 dagen.

Het andere belangrijke bestand is /etc/letsencrypt/renewal/example.com.conf. Dit bestand bevat gegevens over de uitgifte van het certificaat — authenticator = apache, installer = apache, de domeinen. Hierdoor kan de vernieuwing automatisch verlopen, inclusief het herladen van Apache.

Vernieuwing is al gepland — controleer dit, bouw het niet opnieuw op

Let's Encrypt-certificaten hebben standaard een geldigheidsduur van 90 dagen. Het geïnstalleerde apt-pakket heeft de benodigde software al geconfigureerd: een systemd timer die Certbot twee keer per dag op willekeurige tijdstippen uitvoert. Deze timer vernieuwt elk certificaat dat binnen 30 dagen verloopt. Voeg geen extra cron job toe; een tweede scheduler veroorzaakt alleen extra logbestanden en verhoogt het risico op rate-limiting.

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

Het eerste commando toont de actieve timer, met een NEXT-tijdstip binnen de komende 24 uur. De planning is tweemaal daags met een willekeurige vertraging, waardoor het exacte tijdstip onvoorspelbaar is (bij een snap-installatie is de timer snap.certbot.renew.timer). De dry run voert een volledige test-vernieuwing uit tegen de staging-omgeving van Let's Encrypt — dit bevat een echte challenge, maar er wordt geen certificaat uitgegeven en er wordt geen gebruik gemaakt van de rate-limit. Een correct resultaat eindigt met:

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

Als de dry run mislukt, zal de echte vernieuwing over ongeveer 60 dagen op dezelfde manier mislukken. Los dit nu op, terwijl het huidige certificaat nog volledig geldig is. De meest voorkomende oorzaak is een firewall-regel die na de uitgifte is toegevoegd en poort 80 weer heeft gesloten.

Controleer 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 moet HTTP/1.1 301 Moved Permanently retourneren met een Location: https://example.com/ header — dit is de redirect die Certbot heeft geïnstalleerd. De tweede moet HTTP/1.1 200 OK retourneren zonder TLS-foutmelding van curl. De derde toont de uitgever — een O = Let's Encrypt regel met een korte CN zoals R12 of E7 — en notAfter ongeveer 90 dagen resterend. In een browser ziet u het hangslot; klikken op het hangslot toont dezelfde uitgever. Als curl werkt maar de browser een waarschuwing geeft, is er waarschijnlijk sprake van een gecachte pagina of een onjuiste hostname, en niet van een certificaatprobleem.

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

Beide methoden werken; de vernieuwing verloopt op dezelfde wijze. Gebruik voor niet-gerelateerde sites op hetzelfde systeem één keer het issue-commando per site. Elke site krijgt een eigen directory onder live/ en een eigen configuratie voor vernieuwing. Een probleem met één domein blokkeert de vernieuwing van de andere domeinen niet. Dit is de standaardinstelling.

Gebruik voor één site met meerdere namen één SAN-certificaat; een enkel certificaat kan tot 100 namen bevatten. Dit heeft u hierboven al gedaan met example.com en www.example.com. Om later een naam aan een bestaand certificaat toe te voegen, moet u het certificaat opnieuw uitgeven met de volledige nieuwe lijst:

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

Certbot detecteert de gewijzigde set domeinen, vraagt om bevestiging van de uitbreiding en vervangt het certificaat op de huidige locatie. Het live/ pad blijft gelijk, dus u hoeft verder niets aan te passen. Let op: de lijst is een volledige vervanging, geen aanvulling. Als u www weglaat in het commando, wordt dit domein stilzwijgend 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 de controle over één hostname, niet over een volledige namespace. Wildcards vereisen de DNS-01 challenge: Certbot stelt een TXT-record in bij _acme-challenge.example.com. In de praktijk betekent dit het gebruik van een certbot-dns-* plugin met API-gegevens voor uw DNS-provider, of het handmatig bewerken van TXT-records bij elke verlenging met --manual (zeer tijdrovend — plan hier niet op). De volledige handleiding, van de werking van het TXT-record tot een plugin die automatisch verlengt, vindt u in wildcard certificates with Certbot over DNS-01. Eerlijk advies: als u vier bekende subdomeinen heeft, is een SAN-certificaat met alle vier de domeinen eenvoudiger dan een wildcard. Hiervoor zijn geen DNS API-keys op de server nodig.

Foutmodi, met de strings die u zult zien

Certbot weigert te starten omdat de Apache-configuratie 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. De plugin stopt als Apache zelf fouten bevat — de \ns zijn letterlijk omdat Certbot de repr van de exception print. Voer sudo apache2ctl configtest zelf uit: dit geeft het bestand en de regel aan — meestal een typefout door handmatige bewerking, een SSLCertificateFile die naar een niet-bestaand pad verwijst, of een module die wordt aangeroepen maar niet is ingeschakeld. Herstel de fout tot Syntax OK wordt weergegeven en start Certbot opnieuw.

Geen 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 ontbrekende-ServerName fout die eerder werd genoemd, gedetecteerd tijdens het verwerken. Certbot heeft elke ingeschakelde port-80 vhost gecontroleerd op een ServerName/ServerAlias die overeenkomt met uw -d en niets gevonden. sudo apache2ctl -S toont wat Apache daadwerkelijk routeert; voeg de ServerName regel toe aan de juiste vhost, reload en probeer het opnieuw. Een vergelijkbaar probleem is validatie die de verkeerde vhost bereikt — de challenge-response komt Invalid response ... 404 terug omdat een andere site het verzoek opvangt. Dezelfde diagnose, hetzelfde hulpmiddel: apache2ctl -S.

Validatie loopt vast (timeout).

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

Let's Encrypt kon geen TCP-verbinding maken met port 80 op het adres dat uw DNS aangeeft. In volgorde van waarschijnlijkheid: de netwerkfirewall van uw provider (apart van ufw, geconfigureerd in het hostingpaneel), een ufw-regelset die alleen 443 of alleen SSH toestaat, DNS dat nog naar een vorige server wijst, of het stale-AAAA probleem — hun servers proberen IPv6, terwijl uw server alleen op IPv4 reageert. Test vanaf buiten de VPS: curl -I http://example.com vanaf uw laptop reproduceert wat hun validator ziet.

U bent tegen een rate limit aangelopen door herhaalde pogingen.

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

Let's Encrypt staat 5 mislukte validaties toe per hostname per account per uur — sinds de herziening van de rate-limits in 2025 is dit een 'refilling bucket', waarbij u ongeveer elke 12 minuten één poging terugkrijgt — en herhaaldelijk proberen bij een defecte firewall verbruikt dit snel. Wachten werkt, maar de echte oplossing is gedragsmatig: debug na elke fout met de staging-omgeving totdat deze slaagt.

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

Let op certonly: --dry-run wordt alleen geaccepteerd door de certonly en renew subcommands, en de enkele certbot --apache --dry-run vorm weigert zelfs te draaien en geeft --dry-run currently only works with the 'certonly' or 'renew' subcommands aan. De dry run valideert tegen staging, wat eigen ruime limieten heeft en geen echte certificaten uitgeeft, dus u kunt daar de hele middag fouten maken. Voer het echte commando pas opnieuw uit als staging slaagt. De andere limieten — 50 certificaten per geregistreerd domein per week, 5 duplicaten van dezelfde naamset per week — treft u alleen als een script in een loop opnieuw certificaten aanvraagt.

Zodra HTTPS actief is, moet u onthouden dat het certificaat de transportlaag beveiligt, niet de server: port 22 ontvangt nog steeds de hele dag wachtwoordpogingen. Het combineren van dit proces 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 bevat Certbot 2.9.0. Deze versie is actueel genoeg voor deze handleiding, ontvangt beveiligingsupdates via unattended-upgrades en vereist geen snapd. Kies alleen voor snap als u direct de nieuwste release nodig heeft of een DNS-plugin die uitsluitend als snap wordt aangeboden — en als u overstapt, doe dan eerst apt remove certbot python3-certbot-apache zodat er nooit twee renewal-schedulers tegelijkertijd actief zijn.

Waarom geeft Certbot de melding "Unable to find a virtual host listening on port 80"?

Dit gebeurt omdat er geen ingeschakelde vhost op poort 80 een ServerName of ServerAlias heeft die overeenkomt met het domein dat u met -d heeft opgegeven. De standaard vhost van Ubuntu heeft ServerName uitgeschakeld (commented out). 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 de netwerkfirewall in het paneel van uw provider en controleer ook ufw. Bevestig dat dig +short example.com dit VPS retourneert en verwijder of corrigeer verouderde AAAA-records — validatie geeft de voorkeur aan IPv6 als dit beschikbaar is. Controleer de oplossing vanaf buiten de server met curl -I http://example.com en test dit met sudo certbot certonly --apache --dry-run -d example.com voordat u de echte certificaten aanvraagt.

Vernieuwt Certbot certificaten automatisch op Ubuntu 24.04?

Ja. Het apt-pakket installeert certbot.timer, een systemd-timer die twee keer per dag draait en elk certificaat dat binnen 30 dagen verloopt vernieuwt, waarna Apache wordt herlaad. De snap-versie gebruikt snap.certbot.renew.timer voor dezelfde taak. Controleer dit met systemctl list-timers certbot.timer en test met sudo certbot renew --dry-run — voeg geen eigen cronjob toe.

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

Wildcards vereisen de DNS-01 challenge: Certbot moet een TXT-record plaatsen op _acme-challenge.example.com. Dit vereist een certbot-dns-*-plugin met API-gegevens voor uw DNS-provider (de --manual-optie vereist handmatige TXT-records bij elke vernieuwing). Als u slechts enkele bekende subdomeinen heeft, is een SAN-certificaat waarbij u deze expliciet vermeldt eenvoudiger en voorkomt dit dat DNS API-keys op de server staan.