Let’s Encrypt ACME: Automatisera certifikat och hantera förnyelser på ett säkert sätt

ACME-processen och separata nyckelroller

ACME standardiserar kommunikationen mellan en klient och certifikatutfärdaren, inte hela driftsmiljön. Klienten använder först ett ACME-konto och skapar därefter en beställning för ett eller flera domännamn. För varje identifierare kräver servern en auktorisering. Först när denna har godkänts kan klienten slutföra beställningen med en Certificate Signing Request, förkortat CSR, och hämta det utfärdade certifikatet.

1. Skapa en kontonyckel eller använd ett befintligt ACME-konto och skapa ordern.
2. För varje begärd identifierare ska den angivna utmaningen tillhandahållas och man ska invänta godkännandet.
3. Skapa ett separat nyckelpar för certifikatet, skapa en CSR utifrån detta och slutföra beställningen. Den offentliga nyckeln i CSR:en får inte vara densamma som kontonyckeln som autentiserar slutförandebeställningen.
4. Hämta certifikatet och certifikatkedjan, lagra dem på ett säkert sätt och distribuera dem till de avsedda TLS-ändpunkterna.

Der ACME-kontonyckel autentiserar klienten för kontot gentemot ACME-servern och signerar protokollmeddelandena. Den privata nyckeln som används i CSR:en ingår däremot i den senare TLS-identiteten. RFC 8555 kräver två olika nyckelklasser: Den offentliga nyckeln i CSR får inte motsvara en känd kontonyckel och får framför allt inte vara identisk med den kontonyckel som autentiserar slutföringsuppdraget. Klienten och servern måste kontrollera denna åtskillnad.

I DNS-01 tillkommer en tredje känslig komponent: behörigheten till DNS-API:et. Let’s Encrypt påpekar att fullständiga inloggningsuppgifter för DNS-API på en webbserver avsevärt ökar konsekvenserna av en attack. Som en operativ säkerhetsåtgärd bör token därför helst endast få ändra de nödvändiga utmaningsposterna; alternativt kan DNS-valideringen ske på ett separat system.

Kontonycklar, certifikatnycklar och DNS-åtkomst utgör olika förtroendeområden. Att använda olika nyckelpar för kontot och certifikatet är ett protokollkrav; separat lagring, strikt begränsade åtkomsträttigheter och oberoende rotationsprocesser är dessutom viktiga driftsåtgärder. På så sätt behöver en komprometterad DNS-token inte innebära åtkomst varken till den privata certifikatnyckeln eller till ACME-kontot.

Automatisering eliminerar inte felaktiga förutsättningar. En oåtkomlig port, felaktig routning, en olämplig DNS-delegering eller alltför omfattande åtkomsträttigheter förblir driftsproblem, även om skapandet av order är automatiserat. ACME påskyndar den repeterbara processen; operatörerna måste på ett tillförlitligt sätt implementera ett behörighetskoncept, den föreskrivna separationen mellan konto- och certifikatnycklar, säker lagring samt kontroll av de certifikat som faktiskt levereras i sin miljö.

Den rätta utmaningen för infrastrukturen

Utmaningen avgör hur en certifikatutfärdare kontrollerar kontrollen över en identifierare. Den bör därför härledas från nätverksväg, DNS-hantering och TLS-terminering, inte från en generell preferens för ett klientverktyg. HTTP-01, DNS-01 och TLS-ALPN-01 avser olika typer av kontroll och ställer följaktligen olika krav på infrastruktur och behörigheter.

För en enskild, offentligt tillgänglig webbplats gäller att HTTP-01 oftast den rakaste vägen. Klienten ställer en resurs till förfogande under /.well-known/acme-challenge/ som hämtar Let’s Encrypt via port 80. Om en domän pekar på flera A- eller AAAA-mål måste denna resurs vara tillgänglig på alla system som valideringsförfrågan kan nå. I annat fall uppstår ett valideringsfel som endast inträffar sporadiskt.

Wildcard-certifikat för *.example.org kräver däremot absolut DNS-01. Klienten publicerar därför en TXT-post under _acme-challenge.example.org. Detta passar bra för många dynamiska underdomäner, distribuerade webbservrar eller en lastbalanserare, eftersom ingen enskild HTTP-instans behöver leverera valideringsfilen. En förutsättning är dock en tillförlitlig, automatiserbar DNS-ändring.

En omvänd proxy utan en användbar port 80 kan TLS-ALPN-01 användas, förutsatt att den kontrollerar TLS-avslutningen på port 443 och att den använda klienten stöder denna utmaning. Valideringen sker via en särskild TLS-anslutning, inte via en vanlig webbfil. Metoden är därför särskilt lämplig för specialiserad proxy- eller hostinginfrastruktur, men inte som en allmän ersättning för HTTP-01. Jokertecken stöds inte heller här.

Ingen metod är generellt sett överlägsen: HTTP-01 minskar DNS-åtkomsten för en enkel webbplats, DNS-01 möjliggör jokertecken och kopplar bort valideringen från webbvägen, medan TLS-ALPN-01 utnyttjar befintlig TLS-kontroll på ett målinriktat sätt. Det avgörande är att den valda utmaningen fungerar under verkliga failover-, IPv4- och IPv6-vägar och att dess behörigheter passar respektive driftsmodell.

ARI, profiler och kortare löptider

Med Information om förnyelse av ACME (ARI) förskjuts förnyelsestrukturen från ett lokalt fastställt datum till ett tidsfönster som rekommenderas av ACME-servern. Klienten begär denna information för ett befintligt certifikat och väljer en slumpmässig tidpunkt inom tidsfönstret. På så sätt kan förnyelserna fördelas över tiden och, vid särskilda händelser, tidigareläggas på ett målinriktat sätt.

ARI är en standardiserad tilläggsfunktion, men ingår inte automatiskt i alla installerade klienter eller kontrollpaneler. Let’s Encrypt kan erbjuda nya bakåtkompatibla ACME-funktioner på den befintliga slutpunkten; om en specifik installation utnyttjar dessa beror på dess version och implementering. För större installationer bör man därför kontrollera om klienten begär ARI, respekterar tidsfönstret och inte synkroniserar förnyelserna på nytt.

Let’s Encrypt tilldelar dessutom beställningar certifikatprofiler. Om man inte uttryckligen väljer någon profil är den klassiska profilen standard och har för närvarande en giltighetstid på 90 dagar. Profilen tlsserver har en giltighetstid på 45 dagar, kortare giltighetstider för öppna auktoriseringar och order samt högst 25 DNS-namn. shortlived Använder också korta objektperioder, är giltigt i cirka 160 timmar och stöder både DNS- och IP-identifierare.

Valet av profil förutsätter också stöd från klienten; det bör inte enbart baseras på serverdokumentationen. Profilerna skiljer sig åt inte bara vad gäller giltighetstid och identifierare utan även i andra egenskaper. Applikationer och inventeringsverktyg får därför varken förutsätta en enhetlig process eller att varje certifikat innehåller ett gemensamt namn.

Räknas man på det är förhållandet mellan 90 dagar och cirka 160 timmar ungefär 13,5. Detta ger inte någon mätbar belastning, men en tydlig planeringssekvens: Varje störning vid beställning, distribution eller omlastning leder till kortlivade certifikat kritiska redan mycket tidigare. De är endast lämpliga för system där hela leveranskedjan övervakas och där förnyelsen inte är beroende av manuella ingrepp. För ARI-koordinerade förnyelser gäller särskilda regler för begränsningar hos Let’s Encrypt under dokumenterade förutsättningar.

Utmaningsmatris och säker DNS-delegering

Valet av utmaning baseras på den tillgängliga infrastrukturen, inte på en allmän rangordning. HTTP-01 kräver ett offentligt tillgängligt svar via port 80, DNS-01 en kontrollerbara TXT-post och TLS-ALPN-01 kontroll över TLS-termineringen på port 443. Wildcard-namn kan endast valideras med DNS-01.

En webbplats med en enda webbserver klarar sig därför ofta bra med HTTP-01. Om DNS-A- eller AAAA-poster däremot pekar på flera system måste varje mål som faktiskt nås leverera den förväntade resursen. I annat fall beror resultatet på vilken slutpunkt valideringen når. En lastbalanserare eller en centralt synkroniserad utmaningsdatabas löser detta problem endast om den täcker alla vägar.

För DNS-01 gäller följande: Minimibehörighet sträva efter att ACME-klienten endast ska kunna ändra de utmaningsposter som behövs. Vilken begränsning som faktiskt är möjlig beror på DNS-leverantörens API och behörighetsmodell; inte alla tjänster tillåter behörigheter för ett enskilt TXT-namn. Om endast omfattande åtkomst återstår bör valideringen flyttas till ett separat system eller så bör en särskild utmaningszon delegeras. Åtkomstuppgifter ska förvaras separat från certifikat- och ACME-kontonycklar i ett skyddat arkiv.

Vid omfattande zoner kan en separat utmaningszon ytterligare begränsa behörigheterna. Delegering av _acme-challenge Genom CNAME eller NS flyttas valideringsdata till en egen administrationsdomän. Klienten får då endast ändringsrättigheter där. Innan systemet tas i drift måste TXT-innehållet och DNS-upplösningen kontrolleras: Ett korrekt API-svar räcker inte om resolverna ännu inte kan se delegeringen eller posten.

Automatisera uppdatering och distribution på ett tillförlitligt sätt

Tåligt Certifikathantering slutar inte med att ett certifikat hämtas. I en distribuerad miljö initierar en central ACME-arbetsprocess valideringen och lagrar certifikatet samt den privata nyckeln på ett säkert sätt. Först därefter distribueras artefakterna till TLS-ändpunkterna, där de granskas och aktiveras under kontroll. Certifikatnyckeln som används i CSR:en måste skilja sig från den autentiserande ACME-kontonyckeln; hur de båda nycklarna därefter ska lagras separat, behörighetshanteras och roteras ska fastställas i driftskonceptet.

Följande tabell beskriver ett rekommenderat driftskoncept för leveranskedjan. RFC 8555 kräver att den offentliga nyckeln i CSR inte motsvarar någon känd kontonyckel och framför allt inte stämmer överens med den kontonyckel som används för att autentisera slutföringsuppdraget. Den konkreta organisatoriska åtskillnaden mellan lagring, åtkomsträttigheter och rotation bygger på detta protokollkrav. Certbots Deploy Hook är avsedd för åtgärder efter en lyckad utfärdning. Överföringssäkerhet, målkontroll och extern TLS-kontroll måste passa respektive infrastruktur.

Vid ändringar av panel- eller DNS-integrationer bör den produktiva kedjan inte betraktas som ett enskilt system. Särskilt vid administration via Plesk-uppdateringar för webbhotellleverantörer De tillgängliga funktionerna beror på Panelstand, tillägg och anslutna tjänster. Den specifika ACME-klientens kapacitet, till exempel för ytterligare protokolltillägg, beror också på versionen och måste testas i den kombination som används.

I Certbot kan en deploy-hook utlösa det sista steget, eftersom den endast körs efter en lyckad förnyelse. Följande exempel förutsätter att den lokala sökvägen är ett verifierat, körbart skript utan inloggningsuppgifter. Skriptet bör idempotent arbeta, logga fel och endast ladda om de tjänster som använder det förnyade certifikatet.

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

Avslutningsstatusen för certbot renew är inte ett bevis på ett nytt certifikat: Även om inget behövde förnyas kan kommandot avslutas med status 0. Övervakningen måste därför självständigt fastställa vilket certifikat den offentliga ändpunkten faktiskt levererar, när det löper ut och om omladdningen lyckades.

CAA, profiler och certifikat för IP-adresser

En CAA-post är en Utställningsräcke: Den fastställer vilka certifikatutfärdare som får utfärda certifikat för en domän. Dessutom kan riktlinjen ange vilken valideringsmetod som är tillåten och, via parametern accounturi Ange det avsedda ACME-kontot. Den aktuella kontonyckeln autentiserar åtkomsten till detta konto, men kan bytas ut via ACME-nyckelbytesprocessen. Kontobindningen ersätter därför varken skyddet av den aktuella kontonyckeln eller ett omfattande behörighetskoncept.

Följande Record-rad tillåter Let’s Encrypt för domänen endast vid DNS-01-validering. Den är endast lämplig om DNS-01 är automatiskt konfigurerat och utmaningszonen hanteras på ett tillförlitligt sätt. Den som senare vill använda HTTP-01 för en enskild webbplats eller TLS-ALPN-01 för en omvänd proxy blockerar medvetet denna utfärdning med den angivna begränsningen.

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

Den enskilda raden beskriver inte nödvändigtvis hela CAA-policy i zonen. Flera poster av samma typ har en kumulativ effekt: om en av dem tillåter utfärdandet, kan detta tillstånd gälla trots att andra poster har strängare villkor. För jokerteckencertifikat måste man dessutom kontrollera om issuewild-poster finns. Utan sådana poster gäller issue även för jokertecken; befintliga issuewild-Posterna styr däremot utfärdandet av jokertecken separat. Avgörande är därför alltid den fullständiga, giltiga uppsättningen poster för det granskade namnet.

Certifikat för offentliga IP-adresser skiljer sig från domäncertifikat. Let’s Encrypt stöder IP-identifierare i profilen shortlived; HTTP-01 och TLS-ALPN-01 kan användas för validering. DNS-01 kan inte validera någon IP-adress. Den korta giltighetstiden på cirka 160 timmar kräver därför en kontinuerlig automatiserad förnyelse, distribution och leveranskontroll.

Profilen ”shortlived” lämpar sig därför endast för gränssnitt som är direkt tillgängliga via IP om varje steg fungerar utan manuella ingrepp. Det är inte en förenklad variant för system som underhålls sporadiskt. Dessutom måste den använda ACME-klienten och målmiljön stödja både profilvalet och den valda utmaningen; tillgängligheten hos ACME-tjänsten innebär inte att alla klientversioner stöder detta.

Övervakning och felsökning först i stagingmiljön

Felsökning i ACME börjar med den valideringsmetod som faktiskt används, inte med en ny certifikatbeställning. För ändringar av klient, routning, brandvägg eller DNS är Let’s Encrypts separata staging-ändpunkt lämplig. Staging-miljön har egna, betydligt högre gränser, men är inte obegränsad; de testcertifikat som utfärdas där är inte allmänt betrodda. Även om nya protokollfunktioner kan vara tillgängliga på ACME-ändpunkten måste stödet för den installerade klienten ändå kontrolleras separat.

Vid HTTP-01 ska man först kontrollera om den berörda domänen är offentligt tillgänglig via port 80 och om den begärda filen finns under /.well-known/acme-challenge/ till målsystemet. Flera A- eller AAAA-poster gör testet mer krävande: varje faktiskt nåbar slutpunkt måste tillhandahålla rätt utmaningsfil. Typiska orsaker är avvikande routing för virtuella värdar, en proxy uppströms, en brandväggsregel eller icke-synkroniserade containrar.

TLS-ALPN-01 kräver däremot kontroll över TLS-termineringen på port 443. Vid ett fel bör man kontrollera vilken lastbalanserare eller proxy som tar emot anslutningen, om den levererar det certifikat som krävs för utmaningen och om en vanlig TLS-tjänst åsidosätter processen. Att en lokal certifikatfil har skapats framgångsrikt bevisar inte att den offentligt tillgängliga slutpunkten använder den.

För DNS-01 anges namnet och innehållet i TXT-posten under _acme-challenge kontrolleras separat. Posten måste publiceras i den delegerade eller avgörande zonen; dessutom måste delegeringskedjan stämma om en separat utmaningszon används. Upprepade misslyckade försök på grund av skrivfel, ändringar som ännu inte syns eller felaktig delegering bör först analyseras i staging-miljön.

Effektivt Övervakning övervakar inte bara utgångsdatumet i ACME-arbetarens arkiv. Den kontrollerar självständigt det utfärdade värdnamnet, den återstående giltighetstiden för det certifikat som finns där samt om omladdningen lyckades efter en uppdatering. En varning bör även utlösas om en förnyelse misslyckas eller om en slutpunkt fortfarande levererar det gamla certifikatet trots att ett nytt har utfärdats. För planerade ändringar av värdservrar kompletterar artikeln Planera uppdateringar av cPanel och WHM på ett säkert sätt den nödvändiga driftsplaneringen.

Räntegränser och förnyelser i befintliga avtal

I en certifikatportfölj är transaktionsgränser ett utformningskrav för SSL-automatisering. Dagliga tvingade uppdateringar eller jobb som startas samtidigt genererar onödiga order och kan utlösa begränsningar. Detta gäller särskilt när ett infrastrukturfel drabbar många domäner samtidigt: Upprepningar åtgärdar varken saknade utmaningsfiler eller felaktig DNS, men ökar antalet misslyckade valideringar. Fel måste därför avgränsas innan nästa produktiva körning.

Information om förnyelse av ACME, i korthet ARI, ersätter fasta lokala tröskelvärden med ett förnyelsefönster för ett befintligt certifikat som rekommenderas av ACME-servern. Den ARI-kompatibla klienten hämtar förnyelseinformationen och väljer en slumpmässig tidpunkt inom detta fönster. En schemaläggare kan starta klienten regelbundet, men utvärderar inte ARI själv. Klienten måste ta hänsyn till det rekommenderade fönstret och Retry-After beakta detta samt vid fel iaktta lämpliga backoff- och repetitionsintervall. Frekventare schemaläggningskörningar får därför inte leda till oavbrutna repetitioner av misslyckade uppdrag.

För Let’s Encrypt kan ARI-koordinerade förnyelser undantas från de dokumenterade villkoren för hastighetsbegränsningar. Den nya beställningen måste bland annat innehålla minst en identifierare för det certifikat som ska ersättas, och detta får inte redan ha ersatts via ARI. Detta är inte ett generellt godkännande för godtyckliga nya beställningar: ändringar av certifikatets omfattning måste hanteras separat både tekniskt och operativt.

I synnerhet innebär en förkortad eller ändrad SAN-lista inte automatiskt en förnyelse av det tidigare certifikatet. En beställning som endast omfattar en del av de tidigare namnen kan generera ett separat certifikat, medan det gamla certifikatet förblir giltigt. Inventeringen bör därför omfatta certifikat-ID, fullständig identifieringslista, tilldelade slutpunkter och förnyelseprocess. Innan en planerad SAN-ändring genomförs måste man besluta vilka tjänster som ska omställas och när certifikat som inte längre behövs ska tas bort.

När flera arbetare är inblandade förhindrar ett tydligt ansvarsförhållande dubbla order för samma lager. Det är lämpligt med en central schemaläggare eller en samordnad spärr, spårbara loggar och stegvisa upprepningar efter ett fel. Slumpmässigt urval inom ett ARI-fönster ersätter inte denna styrning, utan minskar framför allt samtidigheten hos regelbundna förnyelser.

Välj rätt driftsmodell utifrån risknivån

För en enskild, offentligt tillgänglig webbplats är HTTP-01 oftast den enklaste driftsmodellen. Webbservern måste på ett tillförlitligt sätt betjäna port 80 och leverera utmaningsfilen till den förväntade sökvägen. Denna modell fungerar inte med jokertecken och blir sårbar när flera oberoende mål svarar på samma domän. Den är därför särskilt lämplig när webbroutning, certifikatlagring och TLS-leverans samlas på en tydligt kontrollerad plats.

DNS-01 är den lämpliga modellen för jokertecken, dynamiska underdomäner och distribuerade TLS-ändpunkter. Förutsättningen är inte enbart åtkomst till DNS, utan en säker och automatiserbar ändring av den nödvändiga TXT-posten. Ett så snävt avgränsat token som möjligt eller en delegerad utmaningszon minskar konsekvenserna av ett komprometterat system. Vilken granularitet som kan uppnås beror på DNS-API:et. Delegeringar måste dokumenteras som en produktiv beroende, övervakas och förses med en återställningsväg.

TLS-ALPN-01 är lämpligt för operatörer som vill styra TLS-termineringen på port 443 på ett målinriktat sätt, till exempel vid en omvänd proxy eller en lastbalanserare. Metoden är varken en generell ersättning för HTTP-01 eller kompatibel med jokertecken. Dess praktiska användbarhet beror dessutom på den aktuella klient- och proxyimplementeringen. Innan den tas i bruk måste man därför kontrollera om programvaran kan generera utmaningen, leverera den och ta bort den ordentligt när processen är avslutad.

Das shortlived-profil är endast lämpligt för system med fullständig automatisering från början till slut. Let’s Encrypt anger en giltighetstid på cirka 160 timmar samt DNS- och IP-identifierare; jämfört med standardprofilen på 90 dagar innebär detta en betydligt högre förnyelsefrekvens rent matematiskt. Varje steg i processen, från beställning till distribution, omladdning och extern granskning, måste därför fungera pålitligt. Valet av profil förutsätter dessutom att den ACME-klient som används faktiskt stöder det valda profilen.

Oavsett modell krävs professionell Certifikathantering En fullständig inventering, säkert hanterade nycklar och DNS-åtkomst med minimala behörigheter. Kontonyckeln autentiserar klienten för ACME-kontot; den privata nyckeln som används i CSR:en ingår i TLS-identiteten. RFC 8555 förbjuder användning av den offentliga kontonyckeln i ett certifikat: Nyckeln i CSR-begäran får framför allt inte sammanfalla med den kontonyckel som autentiserar slutföringsuppdraget. Separat lagring, behörighetstilldelning och rotation av dessa nyckelklasser samt återkallbara åtkomstbehörigheter och en testad återgång till det tidigare certifikatet ingår i behörighets- och nödplanen.

En lyckad ACME-körning får inte vara det enda framgångskriteriet. Leveranskontrollen måste, utanför arbetaren, fastställa vilket certifikat som presenteras av en äkta TLS-ändpunkt. För distributions- och omladdningssteg lämpar sig åtgärder som endast utlöses efter en lyckad förnyelse; i Certbot finns en deploy-hook avsedd för detta. Skriptet bör vara idempotent, logga fel och endast ladda om tjänster som faktiskt använder det förnyade materialet.