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 start

• Apache bedient uw site al via plain 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 daarvan.
• 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. HTTP-01 kan een kaal IP-adres valideren, maar Let's Encrypt geeft alleen IP-certificaten uit via hun opt-in shortlived profiel (met een levensduur van 160 uur), en de Certbot 2.9.0 versie uit apt kan noch ACME-profielen, noch IP-adressen aanvragen. Daarom vereist deze handleiding een domeinnaam. 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 probeert altijd eerst IPv6 als er een AAAA record is gepubliceerd. Als die verbinding een time-out geeft, wordt het opnieuw geprobeerd via IPv4, maar bij geen enkele andere fout krijgt u die tweede kans: een AAAA record naar een adres dat verbindingen weigert, of naar een actieve server die niet de uwe is, 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 een goede keuze

Certbot stapte jaren geleden over op distributie via snap met een goede reden: pakketten in distributies verouderden. Ubuntu 20.04 leverde Certbot 0.40 en daar bleef het bij; het project was het zat om bugs van vijf jaar oud te debuggen. Op 24.04 is die reden komen te vervallen. Het archief bevat Certbot 2.9.0, een release uit februari 2024 van de moderne 2.x-lijn, en unattended-upgrades installeert elke beveiligingsupdate die Ubuntu hiervoor uitbrengt. Upstream is inmiddels overgestapt op de 5.x-serie, maar niets in deze handleiding vereist die versie. Mijn aanbeveling voor dit besturingssysteem: gebruik apt. U slaat de snapd-daemon over, de Apache-plugin wordt in dezelfde transactie geïnstalleerd en de timer voor vernieuwing 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 pakket python3-certbot-apache 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 versie van Certbot zodra deze uitkomt, of u heeft een DNS-plugin nodig die alleen als snap wordt gedistribueerd (verschillende certbot-dns-*-providerplugins vallen hieronder). Als u daarvoor kiest:

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

Welke optie 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 drie zaken: een e-mailadres (Let's Encrypt slaat dit niet langer op bij uw ACME-account en verstuurt geen waarschuwingen meer voor verloop, 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 1.0 leidt de Apache-installer HTTP standaard om naar HTTPS (de vraag zelf is in 1.4 verwijderd), wat de gewenste configuratie is. Gebruik --no-redirect als u daadwerkelijk plain HTTP nodig heeft om content te blijven serveren.

Een succesvolle afronding ziet er als volgt uit; lees deze melding zorgvuldig in plaats van deze vluchtig te bekijken:

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 2027-01-09.

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 deze melding 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 staat 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 deze, bouw deze niet handmatig

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. Let's Encrypt heeft aangekondigd dat nieuwe certificaten vanaf 10 februari 2027 standaard een geldigheidsduur van 64 dagen krijgen. Het venster van 30 dagen blijft hiermee werken; de vernieuwing vindt dan simpelweg rond dag 34 plaats in plaats van rond dag 60, dus er hoeft op deze server niets te worden aangepast.

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, waardoor het exacte tijdstip bewust onvoorspelbaar is (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 mislukt, zal de echte vernieuwing over ongeveer 60 dagen op dezelfde manier falen. Los dit nu op, terwijl het huidige certificaat nog zijn volledige levensduur heeft. De gebruikelijke boosdoener is een firewallregel die na de uitgifte is toegevoegd en poort 80 weer heeft gesloten.

Verifiëren met curl en wat het hangslot moet weergeven

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 Certbot heeft geïnstalleerd. De tweede opdracht moet HTTP/1.1 200 OK retourneren zonder TLS-foutmelding van curl. De derde opdracht toont de uitgever, een O = Let's Encrypt-regel met een korte CN zoals YE1 of YE2 (ECDSA-sleutels) of YR1 of YR2 (RSA-sleutels), en notAfter met een verloopdatum van ongeveer 90 dagen. Een certificaat dat is uitgegeven voordat Let's Encrypt zijn oudere intermediates buiten gebruik stelde, kan tot de volgende verlenging nog een CN tonen zoals R12 of E7; dit is geen fout. In een browser ziet u het hangslot en als u daarop klikt, wordt dezelfde uitgever getoond. Als curl werkt maar de browser een waarschuwing geeft, bekijkt u vrijwel zeker een gecachte pagina of de verkeerde hostnaam, en is er 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, met de meldingen die u zult zien

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 af als Apache zelf niet correct functioneert. De \ns zijn letterlijk, omdat Certbot de repr van de uitzondering afdrukt. Voer zelf sudo apache2ctl configtest uit: dit commando benoemt het bestand en de regel, meestal een typefout door handmatige bewerking, een SSLCertificateFile die naar een niet meer bestaand pad wijst, of een module waarnaar wordt verwezen maar die niet is ingeschakeld. Herstel dit totdat de uitvoer Syntax OK is 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 fout door een ontbrekende ServerName, die wordt gedetecteerd op het moment van aanvraag. Certbot doorzocht elke ingeschakelde poort-80 vhost naar een ServerName/ServerAlias die overeenkomt met uw -d en vond niets. sudo apache2ctl -S toont wat Apache daadwerkelijk routeert; voeg de ServerName-regel toe aan de juiste vhost, herlaad en probeer het opnieuw. Een nauw verwant probleem is dat de validatie de verkeerde vhost bereikt; het challenge-antwoord komt terug als Invalid response ... 404 omdat een andere site het verzoek opving. Dezelfde diagnose, hetzelfde hulpmiddel: 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 naar poort 80 op 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 alleen SSH toestaat, of DNS die nog naar een vorige server wijst. Een verouderd AAAA-record alleen veroorzaakt dit meestal niet, omdat Let's Encrypt bij een time-out van de IPv6-poging opnieuw probeert via IPv4; AAAA-problemen uiten zich meestal als een Connection refused of een Invalid response van de verkeerde server. Test vanaf een locatie buiten de VPS: curl -I http://example.com vanaf uw laptop reproduceert wat hun validator ziet.

U heeft door herhaaldelijk proberen een snelheidslimiet bereikt.

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let's Encrypt staat 5 mislukte validaties per hostnaam per account per uur toe. Dit werkt als een emmer die langzaam bijvult en ongeveer elke 12 minuten één nieuwe poging toestaat. Het herhaaldelijk proberen tegen een defecte firewall verbruikt dit quotum snel. Wachten is een oplossing, maar de juiste aanpak is gedragsverandering: debug na elke fout met de staging-omgeving totdat het daar 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 subcommando's certonly en renew, en de kale certbot --apache --dry-run-vorm weigert volledig te draaien en geeft de melding --dry-run currently only works with the 'certonly' or 'renew' subcommands. De dry run valideert tegen de staging-omgeving, die ruimere limieten heeft en geen echte certificaten uitgeeft, waardoor u daar de hele middag kunt falen. Voer het echte commando pas opnieuw uit zodra de staging-omgeving 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: poort 22 is nog steeds 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. Het ontvangt beveiligingsupdates die Ubuntu via unattended-upgrades publiceert en vereist geen snapd. Kies alleen voor de snap als u direct de nieuwste release nodig hebt of een DNS-plugin die uitsluitend als snap wordt gedistribueerd. Als u overstapt, voer dan eerst apt remove certbot python3-certbot-apache uit zodat er nooit twee vernieuwings-schedulers naast elkaar draaien.

Waarom zegt 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 met -d hebt opgegeven. 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 de netwerkfirewall in het paneel van uw provider en ook ufw. Bevestig dat dig +short example.com deze VPS retourneert en corrigeer of verwijder verouderde AAAA-records, aangezien validatie eerst IPv6 probeert en pas na een time-out terugvalt op IPv4. 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 echte 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 vernieuwt dat binnen 30 dagen verloopt, 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 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 op _acme-challenge.example.com. Dit betekent dat u een certbot-dns-*-plugin nodig hebt met API-inloggegevens voor uw DNS-provider (het --manual-alternatief vereist bij elke vernieuwing handmatig bewerkte TXT-records). Als u slechts een handvol bekende subdomeinen hebt, is een SAN-certificaat waarin deze expliciet worden vermeld eenvoudiger en houdt het DNS-API-sleutels van de server af.