Let’s Encrypt ACME: certificaten automatiseren en verlengingen veilig beheren

ACME-procedure en gescheiden sleutelrollen

ACME standaardiseert de communicatie tussen een client en de certificeringsinstantie, niet de gehele bedrijfsomgeving. De client maakt eerst een ACME-account aan en plaatst vervolgens een bestelling voor een of meer domeinnamen. Voor elke identifier vraagt de server om autorisatie. Pas als deze succesvol is, kan de client de bestelling afronden met een Certificate Signing Request (CSR) en het uitgegeven certificaat ophalen.

1. Maak een accountcode aan of gebruik een bestaand ACME-account en maak de order aan.
2. Geef voor elke aangevraagde identifier de opgegeven challenge en wacht op de autorisatie.
3. Maak een apart sleutelpaar voor het certificaat aan, genereer daaruit de CSR en rond de bestelling af. De openbare sleutel in de CSR mag niet overeenkomen met de accountsleutel waarmee de afsluitopdracht wordt geauthenticeerd.
4. Het certificaat en de certificaatketen ophalen, veilig opslaan en naar de daarvoor bestemde TLS-eindpunten verzenden.

De ACME-accountsleutel authenticeert de client voor het account bij de ACME-server en ondertekent de protocolberichten. De privésleutel die in de CSR wordt gebruikt, maakt daarentegen deel uit van de latere TLS-identiteit. RFC 8555 vereist twee verschillende sleutelklassen: de openbare sleutel van de CSR mag niet overeenkomen met een bekende accountsleutel en mag in het bijzonder niet identiek zijn aan de accountsleutel die de finalisatieopdracht verifieert. De client en de server moeten deze scheiding controleren.

Bij DNS-01 komt daar nog een derde gevoelige component bij: de toegangsrechten voor de DNS-API. Let’s Encrypt wijst erop dat volledige DNS-API-toegangsgegevens op een webserver de gevolgen van een aanval aanzienlijk vergroten. Als operationele veiligheidsmaatregel mag het token daarom bij voorkeur alleen de benodigde challenge-records wijzigen; als alternatief kan de DNS-validatie op een apart systeem plaatsvinden.

Accountsleutels, certificaatsleutels en DNS-toegang vormen verschillende vertrouwensdomeinen. Het gebruik van verschillende sleutelparen voor het account en het certificaat is een protocolvereiste; de gescheiden opslag ervan, strikt beperkte toegangsrechten en onafhankelijke rotatieprocessen zijn bovendien belangrijke operationele maatregelen. Zo hoeft een gecompromitteerd DNS-token niet te betekenen dat er toegang is tot de privésleutel van het certificaat of tot het ACME-account.

Automatisering neemt geen foutieve voorwaarden weg. Een onbereikbare poort, verkeerde routing, een onjuiste DNS-delegatie of te ruime toegangsrechten blijven operationele problemen, ook al is het aanmaken van orders geautomatiseerd. ACME versnelt het herhaalbare proces; een rechtenconcept, de voorgeschreven scheiding tussen account- en certificaatsleutels, veilige opslag en de controle van de daadwerkelijk geleverde certificaten moeten beheerders op betrouwbare wijze in hun omgeving implementeren.

De juiste uitdaging voor de infrastructuur

De challenge bepaalt hoe een certificeringsinstantie de controle over een identificatiecode verifieert. Deze moet daarom worden afgeleid uit het netwerkpad, het DNS-beheer en de TLS-terminatie, en niet uit een algemene voorkeur voor een bepaalde clienttool. HTTP-01, DNS-01 en TLS-ALPN-01 beschrijven verschillende soorten controles en stellen dienovereenkomstig andere eisen aan infrastructuur en machtigingen.

Voor een enkele, openbaar toegankelijke website geldt dat HTTP-01 meestal de meest directe manier. De client stelt een bron beschikbaar onder /.well-known/acme-challenge/ die Let’s Encrypt via poort 80 opvraagt. Als een domein naar meerdere A- of AAAA-doelen verwijst, moet deze bron bereikbaar zijn op alle systemen die de validatieverzoek kan bereiken. Anders treedt er af en toe een validatiefout op.

Wildcard-certificaten voor *.example.org daarentegen vereisen ze absoluut DNS-01. De client publiceert hiervoor een TXT-record onder _acme-challenge.example.org. Dit is geschikt voor veel dynamische subdomeinen, gedistribueerde webservers of een load balancer, omdat er geen enkele afzonderlijke HTTP-instantie is die het validatiebestand hoeft te leveren. Voorwaarde is echter een betrouwbare, automatiseerbare DNS-wijziging.

Een reverse proxy zonder bruikbare poort 80 kan TLS-ALPN-01 gebruiken, mits deze de TLS-terminatie op poort 443 controleert en de gebruikte client deze challenge ondersteunt. De validatie vindt plaats via een speciale TLS-verbinding, niet via een normaal webbestand. De methode is daardoor bijzonder geschikt voor gespecialiseerde proxy- of hostinginfrastructuur, maar niet als algemene vervanging voor HTTP-01. Wildcards worden ook hier niet ondersteund.

Geen enkele methode is in het algemeen superieur: HTTP-01 vermindert bij een eenvoudige website de DNS-toegang, DNS-01 maakt het gebruik van wildcards mogelijk en ontkoppelt de validatie van het webpad, TLS-ALPN-01 maakt gericht gebruik van bestaande TLS-controles. Het is van cruciaal belang dat de gekozen challenge functioneert onder reële failover-, IPv4- en IPv6-paden en dat de bijbehorende bevoegdheden aansluiten bij het betreffende bedrijfsmodel.

ARI, profielen en kortere looptijden

Met Informatie over de verlenging van ACME (ARI) verschuift de vernieuwingslogica van een lokaal vastgestelde peildatum naar een door de ACME-server aanbevolen tijdsvenster. De client vraagt deze informatie op voor een bestaand certificaat en kiest binnen dat tijdsvenster een willekeurig tijdstip. Hierdoor kunnen verlengingen in de tijd worden gespreid en bij bijzondere gebeurtenissen gericht worden vervroegd.

ARI is een gestandaardiseerde uitbreiding, maar geen standaardfunctie van elke geïnstalleerde client of hostingpanel. Let’s Encrypt kan nieuwe, achterwaarts compatibele ACME-functies aanbieden op het bestaande eindpunt; of een specifieke installatie hiervan gebruikmaakt, hangt af van de versie en de implementatie ervan. Voor grotere omgevingen moet daarom worden gecontroleerd of de client ARI opvraagt, het tijdsvenster respecteert en verlengingen niet opnieuw synchroniseert.

Let’s Encrypt wijst bestellingen bovendien aan certificaatprofielen toe. Zonder uitdrukkelijke profielkeuze is het klassieke profiel de standaard en heeft dit momenteel een looptijd van 90 dagen. Het profiel tlsserver heeft een looptijd van 45 dagen, kortere termijnen voor openstaande autorisaties en orders, en maximaal 25 DNS-namen. shortlived maakt eveneens gebruik van korte objecttermijnen, is ongeveer 160 uur geldig en ondersteunt zowel DNS- als IP-identificatiegegevens.

Ook voor de profielselectie is ondersteuning door de client vereist; deze mag niet uitsluitend worden afgeleid uit de serverdocumentatie. Profielen verschillen niet alleen in looptijd en identificatiegegevens, maar ook in andere kenmerken. Toepassingen en inventarisatietools mogen daarom noch een uniforme procedure, noch de aanwezigheid van een Common Name in elk certificaat stilzwijgend veronderstellen.

Rekenkundig gezien is de verhouding tussen 90 dagen en ongeveer 160 uur ongeveer een factor 13,5 in de doorlooptijd. Hieruit volgt geen gemeten belasting, maar wel een duidelijk gevolg voor de planning: elke storing bij de bestelling, distributie of herlaadbeurt wordt bij certificaten met een korte looptijd veel eerder kritisch. Ze zijn alleen zinvol voor systemen waarvan de volledige toeleveringsketen wordt gecontroleerd en waarvan de vernieuwing niet afhankelijk is van handmatige ingrepen. Voor door ARI gecoördineerde vernieuwingen gelden bij Let’s Encrypt, onder gedocumenteerde voorwaarden, speciale regels met betrekking tot rate limits.

Challenge-matrix en veilige DNS-delegatie

De keuze van de uitdaging is gebaseerd op de beschikbare infrastructuur, niet op een algemene ranglijst. HTTP-01 vereist een openbaar bereikbaar antwoord via poort 80, DNS-01 een controleerbare TXT-vermelding en TLS-ALPN-01 controle over de TLS-terminatie op poort 443. Wildcard-namen kunnen uitsluitend met DNS-01 worden gevalideerd.

Een website met slechts één webserver is daarom vaak goed gediend met HTTP-01. Als DNS-A- of AAAA-records echter naar meerdere systemen verwijzen, moet elke daadwerkelijk bereikte bestemming de verwachte bron leveren. Anders hangt het resultaat af van het eindpunt dat de validatie bereikt. Een load balancer of een centraal gesynchroniseerde challenge-opslagplaats lost dit probleem alleen op als deze alle routes dekt.

Voor DNS-01 geldt als Minimale bevoegdheid Ernaar streven dat de ACME-client alleen de benodigde challenge-vermeldingen kan wijzigen. Welke beperking daadwerkelijk mogelijk is, hangt af van de API en het autorisatiemodel van de DNS-provider; niet elke dienst staat rechten toe voor een afzonderlijke TXT-naam. Als er alleen uitgebreide toegang overblijft, moet de validatie worden verplaatst naar een apart systeem of moet een aparte challenge-zone worden gedelegeerd. Toegangsgegevens moeten, gescheiden van certificaat- en ACME-accountsleutels, in een beveiligde opslag worden bewaard.

Bij uitgebreide zones kan een aparte challenge-zone de rechten verder beperken. Het delegeren van _acme-challenge Via CNAME of NS worden de validatiegegevens naar een apart beheergebied verplaatst. De klant krijgt dan alleen daar wijzigingsrechten. Voordat het systeem in productie wordt genomen, moeten de TXT-inhoud en de DNS-resolutie worden gecontroleerd: een correct API-antwoord is niet voldoende als resolvers de delegatie of het record nog niet zien.

Vernieuwing en distributie betrouwbaar automatiseren

Duurzaam Certificaatbeheer houdt niet op bij het ophalen van een certificaat. In een gedistribueerde omgeving zet een centrale ACME-worker de validatie in gang en slaat het certificaat en de privésleutel op een beveiligde manier op. Pas daarna worden de artefacten naar de TLS-eindpunten gedistribueerd, waar ze worden gecontroleerd en gecontroleerd geactiveerd. De in de CSR gebruikte certificaatsleutel moet verschillen van de authenticatiesleutel van het ACME-account; hoe beide sleutels vervolgens afzonderlijk worden opgeslagen, geautoriseerd en geroteerd, moet in het operationele concept worden vastgelegd.

De volgende tabel beschrijft een aanbevolen operationeel concept voor de toeleveringsketen. RFC 8555 vereist dat de openbare sleutel van de CSR niet overeenkomt met een bekende accountsleutel en in het bijzonder niet met de accountsleutel die wordt gebruikt voor de authenticatie van de afrondingsopdracht. De concrete organisatorische scheiding van opslag, toegangsrechten en rotatie is gebaseerd op deze protocolvereiste. De Deploy Hook van Certbot is bedoeld voor acties na een succesvolle uitgifte. Beveiliging van de overdracht, doelcontrole en externe TLS-controle moeten aansluiten bij de betreffende infrastructuur.

Bij wijzigingen aan panel- of DNS-integraties mag de productieve keten niet als een afzonderlijk systeem worden beschouwd. Met name bij beheer via Plesk-updates voor hostingproviders De beschikbare functies zijn afhankelijk van het paneel, de uitbreiding en de gekoppelde diensten. De specifieke mogelijkheden van de ACME-client, bijvoorbeeld voor extra protocoluitbreidingen, zijn eveneens versieafhankelijk en moeten in de gebruikte combinatie worden getest.

Bij Certbot kan een deploy-hook de laatste stap activeren, omdat deze pas wordt uitgevoerd nadat de vernieuwing is geslaagd. Het volgende voorbeeld gaat ervan uit dat het lokale pad een gecontroleerd, uitvoerbaar script is zonder inloggegevens. Het script moet idempotent werken, fouten registreren en uitsluitend diensten opnieuw laden die het vernieuwde certificaat gebruiken.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

De exit-status van certbot renew is geen bewijs voor een nieuw certificaat: zelfs als er niets hoefde te worden vernieuwd, kan het commando eindigen met status 0. Het toezicht moet daarom zelfstandig vaststellen welk certificaat het openbare eindpunt daadwerkelijk levert, wanneer het verloopt en of het herladen is gelukt.

CAA, profielen en certificaten voor IP-adressen

Een CAA-record is een Tentoonstellingsbalustrade: Hierin wordt vastgelegd welke certificeringsinstanties certificaten voor een domein mogen uitgeven. Daarnaast kan het beleid de toegestane validatiemethode bepalen en via de parameter accounturi de beoogde ACME-account instellen. De huidige accountsleutel verifieert de toegang tot deze account, maar kan via het ACME-Key-Change-proces worden gewijzigd. De accountkoppeling vervangt daarom noch de beveiliging van de huidige accountsleutel, noch een uitgebreid autorisatieconcept.

De volgende recordregel staat Let’s Encrypt voor het domein alleen toe bij DNS-01-validatie. Deze is alleen geschikt als DNS-01 automatisch is ingesteld en de challenge-zone betrouwbaar wordt beheerd. Wie later HTTP-01 voor een afzonderlijke website of TLS-ALPN-01 voor een reverse proxy wil gebruiken, blokkeert deze uitgifte bewust met de getoonde beperking.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

De afzonderlijke regel beschrijft niet noodzakelijkerwijs de volledige CAA-beleid van de zone. Meerdere records van hetzelfde type hebben een cumulatief effect: als een ervan de uitgifte toestaat, blijft deze toestemming van kracht ondanks strengere vereisten in andere records. Bij wildcard-certificaten moet bovendien worden gecontroleerd of issuewild-er records aanwezig zijn. Zonder dergelijke records geldt issue ook voor jokertekens; bestaande issuewild-Vermeldingen regelen de toekenning van jokertekens daarentegen afzonderlijk. Bepalend is daarom altijd de volledige, geldige reeks records bij de gecontroleerde naam.

Certificaten voor openbare IP-adressen zijn iets anders dan domeincertificaten. Let’s Encrypt ondersteunt IP-identificatie in het profiel shortlived; als validatiemethoden komen HTTP-01 en TLS-ALPN-01 in aanmerking. DNS-01 kan geen IP-adressen valideren. De korte geldigheidsduur van ongeveer 160 uur vereist daarom een continue, geautomatiseerde vernieuwing, distributie en controle op de levering.

Het shortlived-profiel is dus bijvoorbeeld alleen geschikt voor interfaces die rechtstreeks via IP bereikbaar zijn, als elke stap zonder handmatige tussenkomst verloopt. Het is geen vereenvoudigde variant voor systemen die slechts af en toe worden onderhouden. Bovendien moeten de gebruikte ACME-client en de doelomgeving zowel de profielkeuze als de gekozen challenge ondersteunen; de beschikbaarheid bij de ACME-dienst betekent niet dat elke clientversie dit ondersteunt.

Monitoring en foutopsporing eerst in de staging-omgeving

Het opsporen van fouten bij ACME begint bij de daadwerkelijk gebruikte validatiemethode, niet bij het opnieuw aanvragen van een certificaat. Voor wijzigingen aan de client, routing, firewall of DNS is het aparte staging-eindpunt van Let’s Encrypt geschikt. De staging-omgeving heeft eigen, aanzienlijk hogere limieten, maar is niet onbeperkt; de testcertificaten die daar worden uitgegeven, zijn niet openbaar vertrouwbaar. Nieuwe protocolfuncties kunnen weliswaar beschikbaar zijn op het ACME-eindpunt, maar de ondersteuning door de geïnstalleerde client moet toch apart worden gecontroleerd.

Bij HTTP-01 moet eerst worden gecontroleerd of het betreffende domein openbaar bereikbaar is via poort 80 en of het opgevraagde bestand zich bevindt op /.well-known/acme-challenge/ aan het doelsysteem levert. Meerdere A- of AAAA-records maken de test uitdagender: elk daadwerkelijk bereikbaar eindpunt moet het juiste challenge-bestand beschikbaar stellen. Typische oorzaken zijn afwijkende virtual-host-routing, een proxy stroomopwaarts, een firewallregel of niet-gesynchroniseerde containers.

TLS-ALPN-01 vereist daarentegen controle over de TLS-terminatie op poort 443. Bij een fout moet worden gecontroleerd welke load balancer of proxy de verbinding aanvaardt, of deze het voor de challenge benodigde certificaat levert en of een reguliere TLS-dienst het proces overschrijft. Het feit dat er met succes een lokaal certificaatbestand is aangemaakt, bewijst nog niet dat het publiekelijk benaderde eindpunt dit ook daadwerkelijk gebruikt.

Bij DNS-01 staan de naam en de inhoud van het TXT-record onder _acme-challenge afzonderlijk controleren. Het record moet in de gedelegeerde of relevante zone zijn gepubliceerd; bovendien moet de delegatieketen kloppen wanneer een afzonderlijke challenge-zone wordt gebruikt. Herhaalde mislukte pogingen als gevolg van typefouten, nog niet zichtbare wijzigingen of een foutieve delegatie moeten in eerste instantie in de staging worden geanalyseerd.

Effectief Controle houdt niet alleen de vervaldatum in de opslag van de ACME-worker in de gaten. Het controleert onafhankelijk de geleverde hostnaam, de resterende geldigheidsduur van het daar weergegeven certificaat en of het herladen na een update is gelukt. Er moet ook een waarschuwing worden gegeven als een verlenging mislukt of als een eindpunt ondanks een succesvolle uitgifte nog steeds het oude certificaat levert. Voor geplande wijzigingen aan hostingservers vult het artikel aan cPanel- en WHM-updates veilig plannen de nodige bedrijfsplanning.

Transactielimieten en verlengingen in de portefeuille

In een certificaatportefeuille zijn transactielimieten een ontwerpvoorwaarde van de SSL-automatisering. Dagelijks geforceerde vernieuwingen of gelijktijdig gestarte taken genereren onnodige opdrachten en kunnen limieten activeren. Dit geldt met name wanneer een infrastructuurfout veel domeinen tegelijk treft: herhalingen lossen noch ontbrekende challenge-bestanden, noch onjuiste DNS-instellingen op, maar verhogen wel het aantal mislukte validaties. Fouten moeten daarom vóór de volgende productieve run worden opgespoord en verholpen.

Informatie over de verlenging van ACME, kort gezegd ARI, vervangt vaste lokale drempelwaarden door een door de ACME-server aanbevolen vernieuwingsvenster voor een bestaand certificaat. De ARI-compatibele client vraagt de vernieuwingsinformatie op en kiest een willekeurig tijdstip binnen dit venster. Een planner kan de client regelmatig starten, maar analyseert ARI zelf niet. De client moet het aanbevolen venster en Retry-After hiermee rekening houden en bij fouten de juiste backoff- en herhalingsintervallen in acht nemen. Frequentere scheduler-runs mogen daarom niet leiden tot ongebreidelde herhalingen van mislukte taken.

Voor Let’s Encrypt kunnen door ARI gecoördineerde verlengingen onder de gedocumenteerde voorwaarden worden vrijgesteld van rate limits. De nieuwe opdracht moet onder andere ten minste één identificatiecode van het te vervangen certificaat bevatten, en dit certificaat mag nog niet via ARI zijn vervangen. Dit is geen algemene toestemming voor willekeurige nieuwe opdrachten: wijzigingen in de reikwijdte van het certificaat moeten technisch en operationeel afzonderlijk worden behandeld.

Met name een ingekorte of gewijzigde SAN-lijst betekent niet automatisch een verlenging van het bestaande certificaat. Een aanvraag met slechts een deel van de bestaande namen kan een afzonderlijk certificaat genereren, terwijl het oude certificaat geldig blijft. De inventaris moet daarom het certificaat-ID, de volledige lijst met identificatiegegevens, de toegewezen eindpunten en de vernieuwingsprocedure bevatten. Voorafgaand aan een geplande SAN-wijziging moet worden bepaald welke diensten worden aangepast en wanneer niet langer benodigde certificaten worden verwijderd.

Bij meerdere workers voorkomt een eenduidige verantwoordelijkheid dubbele opdrachten voor dezelfde voorraad. Het is zinvol om een centrale planner of een gecoördineerde vergrendeling te gebruiken, evenals traceerbare logboeken en gespreide herhalingen na een fout. De willekeurige selectie binnen een ARI-venster is geen vervanging voor deze regeling, maar vermindert vooral de gelijktijdigheid van reguliere vernieuwingen.

Het juiste bedrijfsmodel kiezen op basis van het risico

Voor een enkele, openbaar toegankelijke website is HTTP-01 meestal het eenvoudigste bedrijfsmodel. De webserver moet poort 80 betrouwbaar bedienen en het challenge-bestand op het verwachte pad leveren. Dit model is niet geschikt voor wildcards en wordt kwetsbaar wanneer meerdere onafhankelijke doelen op hetzelfde domein reageren. Het is daarom vooral zinvol wanneer webrouting, certificaatopslag en TLS-levering samenkomen op één duidelijk gecontroleerde locatie.

DNS-01 is het geschikte model voor wildcards, dynamische subdomeinen en gedistribueerde TLS-eindpunten. De voorwaarde is niet alleen toegang tot het DNS, maar ook de mogelijkheid om de benodigde TXT-records op een veilige manier te wijzigen. Een zo beperkt mogelijk token of een gedelegeerde challenge-zone beperkt de gevolgen van een gecompromitteerd systeem. Welke granulariteit haalbaar is, hangt af van de DNS-API. Delegaties moeten worden gedocumenteerd als een productieve afhankelijkheid, worden gemonitord en voorzien van een herstelprocedure.

TLS-ALPN-01 is geschikt voor beheerders die de TLS-terminatie op poort 443 gericht willen sturen, bijvoorbeeld op een reverse proxy of load balancer. De methode is geen algemene vervanging voor HTTP-01 en ondersteunt ook geen wildcards. De praktische bruikbaarheid hangt bovendien af van de betreffende client- en proxy-implementatie. Voorafgaand aan het gebruik moet daarom worden gecontroleerd of de software de challenge kan genereren, verzenden en na afloop weer netjes kan verwijderen.

De shortlived-profiel is alleen geschikt voor systemen met volledige end-to-end-automatisering. Let’s Encrypt geeft hiervoor een looptijd van ongeveer 160 uur aan, evenals DNS- en IP-identificatiegegevens; in vergelijking met het standaardprofiel van 90 dagen leidt dit rekenkundig gezien tot een aanzienlijk hogere vernieuwingsfrequentie. Elk proces, van bestelling tot distributie, herladen en externe controle, moet daarom betrouwbaar functioneren. De keuze voor een profiel vereist bovendien dat de gebruikte ACME-client de profielkeuze daadwerkelijk ondersteunt.

Ongeacht het model is professioneel Certificaatbeheer een volledige inventaris, veilig beheerde sleutels en DNS-toegangsrechten met minimale bevoegdheden. De accountsleutel authenticeert de client voor het ACME-account; de privésleutel die in de CSR wordt gebruikt, maakt deel uit van de TLS-identiteit. RFC 8555 verbiedt het gebruik van de openbare accountsleutel in een certificaat: de sleutel in de CSR mag met name niet overeenkomen met de accountsleutel die de finalisatieopdracht authentificeert. De gescheiden opslag, toekenning van toegangsrechten en rotatie van deze sleutelklassen, evenals herroepbare toegangsrechten en een geteste terugvaloptie naar het vorige certificaat, maken deel uit van het rechten- en noodplan.

Een succesvolle ACME-run mag niet het enige succescriterium zijn. De leveringscontrole moet buiten de worker vaststellen welk certificaat een echt TLS-eindpunt presenteert. Voor distributie- en herlaadstappen zijn acties geschikt die alleen worden geactiveerd na een succesvolle vernieuwing; bij Certbot is hiervoor een deploy-hook voorzien. Het bijbehorende script moet idempotent zijn, fouten loggen en alleen diensten herladen die daadwerkelijk gebruikmaken van het vernieuwde materiaal.