Let’s Encrypt ACME: Automatisering af certifikater og sikker styring af fornyelser

ACME-forløb og adskilte nøgleroller

ACME standardiserer kommunikationen mellem en klient og certifikatudstederen, ikke hele driftsmiljøet. Klienten opretter først en ACME-konto og opretter derefter en ordre på et eller flere domænenavne. For hver identifikator kræver serveren en godkendelse. Først når denne er gennemført, kan klienten afslutte ordren med en Certificate Signing Request (CSR) og hente det udstedte certifikat.

1. Opret en kontonøgle eller brug en eksisterende ACME-konto, og opret ordren.
2. For hver anmodet identifikator skal den angivne udfordring fremlægges, og der skal afventes godkendelse.
3. Opret et separat nøglepar til certifikatet, udarbejd CSR’en ud fra dette, og færdiggør ordren. Den offentlige nøgle i CSR’en må ikke være den samme som den kontonøgle, der autentificerer færdiggørelsesordren.
4. Hent certifikatet og certifikatkæden, gem dem sikkert, og distribuer dem til de pågældende TLS-endepunkter.

Der ACME-kontonøgle autentificerer klienten for kontoen over for ACME-serveren og signerer protokolmeddelelserne. Den private nøgle, der anvendes i CSR’en, hører derimod til den senere TLS-identitet. RFC 8555 kræver to forskellige nøgleklasser: Den offentlige nøgle i CSR'en må ikke svare til en kendt kontonøgle og må især ikke være identisk med den kontonøgle, der autentificerer finaliseringsordren. Klient og server skal kontrollere denne adskillelse.

I DNS-01 kommer der en tredje følsom komponent til: adgangsrettighederne til DNS-API’en. Let’s Encrypt påpeger, at fuldstændige DNS-API-adgangsoplysninger på en webserver øger konsekvenserne af et angreb betydeligt. Som en driftsmæssig sikkerhedsforanstaltning bør tokenet derfor så vidt muligt kun have tilladelse til at ændre de nødvendige challenge-records; alternativt kan DNS-valideringen foregå på et separat system.

Kontonøgler, certifikatnøgler og DNS-adgang udgør forskellige tillidsområder. Det er et krav i protokollen at anvende forskellige nøglepar til kontoen og certifikatet; deres adskilte opbevaring, strengt begrænsede adgangsrettigheder og uafhængige rotationsprocesser er desuden vigtige driftsmæssige foranstaltninger. På den måde behøver et kompromitteret DNS-token ikke nødvendigvis at give adgang til hverken den private certifikatnøgle eller ACME-kontoen.

Automatisering fjerner ikke fejlagtige forudsætninger. En utilgængelig port, forkert routing, en uhensigtsmæssig DNS-delegering eller for vidtgående adgangsrettigheder forbliver driftsproblemer, selvom oprettelsen af ordrer er automatiseret. ACME fremskynder den gentagelige proces; et rettighedskoncept, den foreskrevne adskillelse af konto- og certifikatnøgler, sikker opbevaring samt kontrol af de faktisk udleverede certifikater skal operatørerne implementere pålideligt i deres miljø.

Den rette udfordring for infrastrukturen

Udfordringen afgør, hvordan et certificeringsorgan kontrollerer kontrollen over en identifikator. Den bør derfor udledes af netværksstien, DNS-administrationen og TLS-termineringen, ikke ud fra en generel præference for et klientværktøj. HTTP-01, DNS-01 og TLS-ALPN-01 beskriver forskellige former for kontrol og stiller derfor forskellige krav til infrastruktur og tilladelser.

For en enkelt, offentligt tilgængelig hjemmeside er HTTP-01 er som regel den mest direkte vej. Klienten stiller en ressource til rådighed under /.well-known/acme-challenge/ klar til at hente Let’s Encrypt via port 80. Hvis et domæne peger på flere A- eller AAAA-mål, skal denne ressource være tilgængelig på alle systemer, som valideringsanmodningen kan ramme. Ellers opstår der en valideringsfejl, der kun forekommer lejlighedsvis.

Wildcard-certifikater til *.example.org kræver derimod absolut DNS-01. Klienten offentliggør til dette formål en TXT-post under _acme-challenge.example.org. Dette egner sig til mange dynamiske underdomæner, distribuerede webservere eller en load balancer, da ingen enkelt HTTP-instans behøver at levere valideringsfilen. En forudsætning er dog en pålidelig DNS-ændring, der kan automatiseres.

En reverse proxy uden en brugbar port 80 kan TLS-ALPN-01 anvendes, forudsat at den kontrollerer TLS-termineringen på port 443, og at den anvendte klient understøtter denne udfordring. Valideringen foregår via en speciel TLS-forbindelse, ikke via en almindelig webfil. Metoden er derfor særligt velegnet til specialiseret proxy- eller hostinginfrastruktur, men ikke som en generel erstatning for HTTP-01. Wildcards understøttes heller ikke her.

Ingen metode er generelt bedre end andre: HTTP-01 reducerer DNS-adgangen på en enkel hjemmeside, DNS-01 muliggør wildcards og adskiller valideringen fra webstien, mens TLS-ALPN-01 udnytter eksisterende TLS-kontrol målrettet. Det afgørende er, at den valgte udfordring fungerer under reelle failover-, IPv4- og IPv6-stier, og at dens tilladelser passer til den pågældende driftsmodel.

ARI, profiler og kortere løbetider

Med Oplysninger om fornyelse af ACME (ARI) skifter fornyelseslogikken fra en lokalt fastsat dato til et tidsvindue, der anbefales af ACME-serveren. Klienten henter disse oplysninger for et eksisterende certifikat og vælger et tilfældigt tidspunkt inden for dette tidsvindue. Dermed kan fornyelser fordeles over tid og målrettet fremskyndes i forbindelse med særlige begivenheder.

ARI er en standardiseret udvidelse, men ikke en automatisk funktion i alle installerede klienter eller hostingpaneler. Let’s Encrypt kan tilbyde nye, bagudkompatible ACME-funktioner på det eksisterende endepunkt; om en konkret installation benytter sig af dem, afhænger af dens version og implementering. For større installationer bør man derfor kontrollere, om klienten forespørger ARI, overholder tidsvinduet og ikke synkroniserer fornyelser igen.

Let’s Encrypt tildeler desuden ordrer certifikatprofiler. Hvis der ikke udtrykkeligt vælges en profil, er den klassiske profil standard, og den har i øjeblikket en gyldighedsperiode på 90 dage. Profilen tlsserver har en løbetid på 45 dage, kortere frister for åbne godkendelser og ordrer samt højst 25 DNS-navne. shortlived anvender ligeledes korte objektfrister, er gyldig i ca. 160 timer og understøtter både DNS- og IP-identifikatorer.

Valget af profil forudsætter ligeledes klientunderstøttelse; det bør ikke udelukkende udledes af serverdokumentationen. Profiler adskiller sig ikke blot med hensyn til løbetid og identifikatorer, men også i andre egenskaber. Applikationer og inventariseringsværktøjer må derfor hverken stiltiende antage en ensartet fremgangsmåde eller tilstedeværelsen af et Common Name i hvert certifikat.

Regnemæssigt svarer der mellem 90 dage og ca. 160 timer til en faktor på ca. 13,5 i løbetiden. Dette medfører ingen målbar belastning, men en klar konsekvens for planlægningen: Enhver forstyrrelse i forbindelse med bestilling, distribution eller genindlæsning vil ved kortvarige certifikater kritisk meget tidligere. De giver kun mening for systemer, hvor hele forsyningskæden overvåges, og hvor fornyelsen ikke afhænger af manuelle indgreb. For ARI-koordinerede fornyelser gælder der hos Let’s Encrypt særlige regler for rate limits under dokumenterede forudsætninger.

Udfordringsmatrix og sikker DNS-delegering

Valget af udfordring afhænger af den tilgængelige infrastruktur og ikke af en generel rangorden. HTTP-01 kræver et offentligt tilgængeligt svar via port 80, DNS-01 en kontrollérbar TXT-post, og TLS-ALPN-01 kontrol over TLS-termineringen på port 443. Wildcard-navne kan udelukkende valideres med DNS-01.

En hjemmeside med en enkelt webserver klarer sig derfor ofte godt med HTTP-01. Hvis DNS-A- eller AAAA-poster imidlertid peger på flere systemer, skal hvert eneste mål, der faktisk nås, levere den forventede ressource. Ellers afhænger resultatet af, hvilket slutpunkt valideringen når frem til. En load balancer eller et centralt synkroniseret challenge-lager løser kun dette problem, hvis det dækker alle veje.

For DNS-01 er Minimumsrettigheder Man bør tilstræbe, at ACME-klienten kun kan ændre de nødvendige challenge-poster. Hvilke begrænsninger der rent faktisk er mulige, afhænger af DNS-udbyderens API og autorisationsmodel; ikke alle tjenester tillader rettigheder for et enkelt TXT-navn. Hvis der kun er omfattende adgang, bør valideringen flyttes til et separat system, eller der bør delegeres en særskilt challenge-zone. Adgangsdata skal opbevares separat fra certifikat- og ACME-kontonøgler i et beskyttet lager.

Ved omfattende zoner kan en separat udfordringszone yderligere indskrænke rettighederne. Delegering af _acme-challenge Via CNAME eller NS flyttes valideringsdataene til et separat administrationsområde. Klienten får derefter kun ændringsrettigheder dér. Inden produktiv brug skal TXT-indholdet og DNS-opløsningen kontrolleres: Et korrekt API-svar er ikke tilstrækkeligt, hvis resolverne endnu ikke kan se delegeringen eller posten.

Pålidelig automatisering af fornyelse og fordeling

Belastbar Certifikatadministration slutter ikke med hentningen af et certifikat. I et distribueret miljø udløser en central ACME-worker valideringen og gemmer certifikatet samt den private nøgle på en sikker måde. Først derefter distribueres disse elementer til TLS-endepunkterne, hvor de kontrolleres og aktiveres på en kontrolleret måde. Den certifikatnøgle, der anvendes i CSR’en, skal adskille sig fra den autentificerende ACME-kontonøgle; hvordan begge nøgler efterfølgende skal opbevares adskilt, autoriseres og roteres, skal fastlægges i driftskonceptet.

Følgende tabel beskriver et anbefalet driftskoncept for forsyningskæden. RFC 8555 kræver, at den offentlige nøgle i CSR’en ikke svarer til nogen kendt kontonøgle og især ikke stemmer overens med den kontonøgle, der anvendes til autentificering af finaliseringsordren. Den konkrete organisatoriske adskillelse af opbevaring, adgangsrettigheder og rotation bygger på dette protokolkrav. Certbots Deploy Hook er beregnet til handlinger efter en vellykket udstedelse. Overførselssikring, målkontrol og ekstern TLS-kontrol skal passe til den pågældende infrastruktur.

Ved ændringer af panel- eller DNS-integrationer bør den produktive kæde ikke betragtes som et enkeltstående system. Især ved administration via Plesk-opdateringer til hostingudbydere De tilgængelige funktioner afhænger af panelstand, udvidelser og tilknyttede tjenester. Den konkrete ACME-klientfunktionalitet, f.eks. med hensyn til yderligere protokoludvidelser, afhænger ligeledes af versionen og skal testes i den anvendte kombination.

I Certbot kan en deploy-hook udløse det sidste trin, da den kun kører efter en vellykket fornyelse. Følgende eksempel forudsætter, at den lokale sti er et valideret, kørbart script uden adgangskoder. Scriptet bør idempotent arbejde, registrere fejl og udelukkende genindlæse de tjenester, der bruger det fornyede certifikat.

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

Afslutningsstatus for certbot renew er ikke et bevis på et nyt certifikat: Selv om der ikke var noget, der skulle fornyes, kan kommandoen ende med status 0. Overvågningen skal derfor uafhængigt fastslå, hvilket certifikat det offentlige endepunkt rent faktisk udsteder, hvornår det udløber, og om genindlæsningen lykkedes.

CAA, profiler og certifikater for IP-adresser

En CAA-post er en Udstillingsgelænder: Den fastlægger, hvilke certificeringsmyndigheder der må udstede certifikater til et domæne. Derudover kan retningslinjen angive den tilladte valideringsmetode og via parameteren accounturi Angiv den påtænkte ACME-konto. Den aktuelle kontonøgle godkender adgangen til denne konto, men kan ændres via ACME-nøgleudskiftningsprocessen. Kontotilknytningen erstatter derfor hverken beskyttelsen af den aktuelle kontonøgle eller et omfattende adgangsretningskoncept.

Følgende record-linje tillader kun Let’s Encrypt for domænet ved DNS-01-validering. Den er kun egnet, hvis DNS-01 er konfigureret automatisk, og challenge-zonen administreres pålideligt. Hvis man senere ønsker at bruge HTTP-01 til et enkelt websted eller TLS-ALPN-01 til en reverse proxy, blokerer man bevidst denne udstedelse med den viste begrænsning.

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

Den enkelte linje beskriver ikke nødvendigvis den fulde CAA-politik i zonen. Flere poster af samme type virker additivt: Hvis en af dem tillader udstedelse, kan denne tilladelse fortsat gælde på trods af strengere krav i andre poster. For wildcard-certifikater skal man desuden kontrollere, om issuewild-der findes poster. Uden sådanne poster gælder issue også for jokertegn; eksisterende issuewild-Indtastninger styrer derimod udstedelsen af jokertegn separat. Det er derfor altid den fulde, gyldige sætning af poster for det kontrollerede navn, der er afgørende.

Certifikater til offentlige IP-adresser er en anden sag end domænecertifikater. Let’s Encrypt understøtter IP-identifikatorer i profilen shortlived; HTTP-01 og TLS-ALPN-01 kan anvendes til validering. DNS-01 kan ikke validere en IP-adresse. Den korte gyldighedsperiode på ca. 160 timer forudsætter derfor en kontinuerlig, automatiseret fornyelse, distribution og leveringskontrol.

Shortlived-profilen er derfor kun egnet til grænseflader, der kan nås direkte via IP, hvis hvert trin fungerer uden manuelle indgreb. Det er ikke en forenklet variant til systemer, der kun vedligeholdes lejlighedsvis. Desuden skal den anvendte ACME-klient og målmiljøet understøtte både profilvalget og den valgte udfordring; tilgængeligheden på ACME-tjenesten er ikke ensbetydende med, at alle klientversioner understøtter den.

Overvågning og fejlfinding først i staging-miljøet

Fejlfinding i ACME starter med den valideringsmetode, der rent faktisk anvendes, og ikke med en ny certifikatbestilling. Til ændringer af klient, routing, firewall eller DNS er Let’s Encrypts separate staging-endepunkt velegnet. Staging-miljøet har sine egne, betydeligt højere grænser, men er ikke ubegrænset; de testcertifikater, der udstedes der, er ikke offentligt pålidelige. Nye protokolfunktioner kan ganske vist være tilgængelige på ACME-endepunktet, men understøttelsen af den installerede klient skal alligevel kontrolleres separat.

Ved HTTP-01 skal man først kontrollere, om det pågældende domæne er offentligt tilgængeligt via port 80, og om den anmodede fil findes under /.well-known/acme-challenge/ leverer til målsystemet. Flere A- eller AAAA-poster gør testen mere krævende: Hvert eneste endepunkt, der rent faktisk kan nås, skal stille den relevante udfordringsfil til rådighed. Typiske årsager er afvigende routing af virtuelle værter, en proxy placeret foran, en firewall-regel eller ikke-synkroniserede containere.

TLS-ALPN-01 kræver derimod kontrol over TLS-termineringen på port 443. I tilfælde af en fejl bør det kontrolleres, hvilken load balancer eller proxy der accepterer forbindelsen, om den leverer det certifikat, der kræves til udfordringen, og om en regulær TLS-tjeneste overskriver processen. En vellykket genereret lokal certifikatfil er ikke bevis for, at det offentligt tilgængelige slutpunkt bruger den.

I DNS-01 findes navnet og indholdet af TXT-posten under _acme-challenge skal kontrolleres separat. Recordet skal være offentliggjort i den delegerede eller relevante zone; desuden skal delegeringskæden være korrekt, hvis der anvendes en separat challenge-zone. Gentagne fejlforsøg på grund af tastefejl, ændringer, der endnu ikke er synlige, eller fejl i delegeringen bør først analyseres i staging-miljøet.

Effektivt Overvågning Overvåger ikke kun udløbsdatoen i ACME-workeren. Den kontrollerer uafhængigt det udleverede værtsnavn, den resterende gyldighedsperiode for det der viste certifikat og om genindlæsningen lykkedes efter en opdatering. Der bør også udløses en alarm, hvis en fornyelse mislykkes, eller hvis en endepunkt stadig leverer det gamle certifikat på trods af en vellykket udstedelse. For planlagte ændringer på hosting-servere supplerer artiklen Sikker planlægning af cPanel- og WHM-opdateringer den nødvendige driftsplanlægning.

Ratebegrænsninger og fornyelser i porteføljen

I en certifikatportefølje er rate limits en designbetingelse for SSL-automatisering. Daglige tvungne opdateringer eller opgaver, der startes samtidigt, genererer unødvendige ordrer og kan udløse begrænsninger. Dette gælder især, når en infrastrukturfejl påvirker mange domæner på samme tid: Gentagelser løser hverken manglende challenge-filer eller forkerte DNS-indstillinger, men øger antallet af mislykkede valideringer. Fejl skal derfor indkredses inden den næste produktive kørsel.

Oplysninger om fornyelse af ACME, kort sagt ARI, erstatter faste lokale tærskelværdier med et fornyelsesvindue for et eksisterende certifikat, som ACME-serveren anbefaler. Den ARI-kompatible klient henter fornyelsesoplysningerne og vælger et tilfældigt tidspunkt inden for dette vindue. En scheduler kan starte klienten regelmæssigt, men udvurderer ikke selv ARI. Klienten skal bruge det anbefalede vindue og Retry-After tage højde for dette samt overholde passende backoff- og gentagelsesintervaller i tilfælde af fejl. Hyppigere kørsler af scheduleren må derfor ikke føre til uhindrede gentagelser af mislykkede opgaver.

For Let’s Encrypt kan ARI-koordinerede fornyelser være undtaget fra rate limits under de dokumenterede betingelser. Den nye anmodning skal blandt andet indeholde mindst én identifikator for det certifikat, der skal erstattes, og dette må ikke allerede være blevet erstattet via ARI. Dette er ikke en generel godkendelse af vilkårlige nye anmodninger: Ændringer af certifikatets omfang skal behandles separat både fagligt og operationelt.

Især betyder en forkortet eller ændret SAN-liste ikke automatisk en fornyelse af det hidtidige certifikat. En bestilling, der kun indeholder en del af de hidtidige navne, kan generere et separat certifikat, mens det gamle fortsat er gyldigt. Inventaret bør derfor indeholde certifikat-ID, den fuldstændige identifikatorliste, tilknyttede slutpunkter og fornyelsesmetode. Inden en planlagt ændring af SAN-listen skal det besluttes, hvilke tjenester der skal omstilles, og hvornår certifikater, der ikke længere er nødvendige, skal fjernes.

Når der er flere arbejdere, forhindrer en entydig ansvarsfordeling, at der opstår dobbelte ordrer på den samme lagerbeholdning. Det er fornuftigt at anvende en central planlægger eller en koordineret spærring, sporbare logfiler og trinvis gentagelse efter en fejl. Den tilfældige udvælgelse inden for et ARI-vindue er ikke en erstatning for denne styring, men reducerer først og fremmest samtidigheden af regelmæssige fornyelser.

Vælg den rette driftsmodel ud fra risikoen

For et enkelt, offentligt tilgængeligt websted er HTTP-01 som regel den enkleste driftsmodel. Webserveren skal pålideligt betjene port 80 og levere challenge-filen fra den forventede sti. Denne model er ikke kompatibel med wildcards og bliver ustabil, hvis flere uafhængige mål svarer på det samme domæne. Den er derfor især hensigtsmæssig, når webrouting, certifikatopbevaring og TLS-levering samles på et klart kontrolleret sted.

DNS-01 er den rette model til wildcards, dynamiske underdomæner og distribuerede TLS-endepunkter. Forudsætningen er ikke blot adgang til DNS, men en sikker og automatiserbar ændring af den nødvendige TXT-post. Et så snævert afgrænset token som muligt eller en delegeret challenge-zone mindsker konsekvenserne af et kompromitteret system. Hvilken granularitet der kan opnås, afhænger af DNS-API’en. Delegeringer skal dokumenteres som en produktiv afhængighed, overvåges og forsynes med en genoprettelsesplan.

TLS-ALPN-01 er velegnet til operatører, der målrettet styrer TLS-terminering på port 443, f.eks. på en reverse proxy eller en load balancer. Metoden er hverken en generel erstatning for HTTP-01 eller kompatibel med wildcards. Dens praktiske anvendelighed afhænger desuden af den pågældende klient- og proxy-implementering. Før anvendelse skal det derfor kontrolleres, om softwaren kan generere udfordringen, levere den og fjerne den korrekt efter afslutning.

Das shortlived-profil er kun egnet til systemer med fuldstændig end-to-end-automatisering. Let’s Encrypt angiver her en løbetid på ca. 160 timer samt DNS- og IP-identifikatorer; sammenlignet med standardprofilen på 90 dage øger dette den nødvendige fornyelsesfrekvens matematisk set betydeligt. Hvert trin i forløbet – fra bestilling til distribution, genindlæsning og ekstern kontrol – skal derfor fungere pålideligt. Valget af en profil forudsætter desuden, at den anvendte ACME-klient rent faktisk understøtter den valgte profil.

Uanset hvilken model der er tale om, kræver professionelt Certifikatadministration en fuldstændig oversigt, sikkert administrerede nøgler og DNS-adgang med minimale rettigheder. Kontonøglen autentificerer klienten for ACME-kontoen; den private nøgle, der anvendes i CSR’en, hører til TLS-identiteten. RFC 8555 forbyder brug af den offentlige kontonøgle i et certifikat: Nøglen i CSR-filen må især ikke stemme overens med den kontonøgle, der autentificerer finaliseringsordren. Adskilt opbevaring, tildeling af adgangsrettigheder og rotation af disse nøgleklasser samt tilbagekaldelige adgangsrettigheder og en testet tilbageførsel til det forrige certifikat er en del af rettigheds- og beredskabskonceptet.

En vellykket ACME-kørsel må ikke være det eneste succeskriterium. Leveringskontrollen skal uden for workeren fastslå, hvilket certifikat et ægte TLS-endepunkt præsenterer. Til distributions- og genindlæsningstrin er det hensigtsmæssigt at anvende handlinger, der kun udløses efter en vellykket fornyelse; i Certbot er der en deploy-hook til dette formål. Dens script bør være idempotent, logge fejl og kun genindlæse de tjenester, der rent faktisk bruger det fornyede materiale.