Gratis SSL-certifikater med ACME: guide til opsætning og drift

ACME er protokollen mellem jeres klient og en CA. Klienten bestiller SSL-certifikatet og beviser kontrollen over navnene. Installation i den rigtige tjeneste er et særskilt trin.

RFC 8555: ACME beskriver forløbet: account opretter ACME-kontoen; order bestiller navnene; authorization angiver, hvad der skal godkendes; challenge beviser domænekontrollen; finalize sender en CSR; certificate giver klienten det udstedte SSL-certifikat.

ARI (ACME Renewal Information, RFC 9773) lader CA’en foreslå et fornyelsesvindue. Klienten skal stadig køre regelmæssigt og installere resultatet. Læs om ACME-protokollens forløb fra bestilling til fornyelse.

Vælg CA efter jeres valideringsmetode og drift. Opret den nødvendige konto, læs CA’ens vilkår, og tillad den i jeres CAA-records.

Let’s Encrypt-kontoen oprettes af ACME-klienten. Tabellen fremhæver http-01 og dns-01; Let’s Encrypt understøtter også tls-alpn-01.

Google Trust Services kræver en Google Cloud-konto og et projekt med Public CA API aktiveret. Opret en EAB-nøgle (External Account Binding), og brug den til at knytte ACME-kontoen til projektet. Projektets ACME-konti deler Public CA-kvoter. ZeroSSL kræver også EAB-oplysninger; deres gratis ACME-tjeneste er adskilt fra de øvrige API-produkter.

En CAA-record begrænser, hvilke CA’er der må udstede. Tillad jeres valgte CA med issue, og tjek issuewild for wildcards. CAA-reglerne og FairSSL’s CAA-generator til den rigtige DNS-record hjælper med opsætningen.

Rate limits for udstedelse

Efterhånden som certifikaternes levetid bliver kortere, rammer rate limits hårdere, fordi I udsteder oftere. Grænserne betyder mest, når I udsteder mange nye certifikater på én gang, fx når et nyt miljø kommer med, når I skifter CA, eller når I gendanner servere fra backup. Et certifikat, der flytter fra en anden CA, tæller som nyt hos den nye CA.

Planlægger I mange nye certifikater, så fordel dem på flere konti eller projekter, hvor grænsen gælder pr. konto. Opsæt en ekstra CA på forhånd, og tilføj den i jeres CAA-records, så I kan skifte uden at vente.

Vælg en metode, som både CA og klient understøtter. Brug DNS-validering til wildcards og interne servere med offentlige domænenavne. Begræns klientens DNS-rettigheder til valideringen.

http-01: Klienten lægger et svar på http://<name>/.well-known/acme-challenge/<token>. CA’en henter det over port 80. Metoden kan ikke validere wildcards. En intern server kan kun bruge metoden, hvis et offentligt tilgængeligt HTTP-system besvarer udfordringen for navnet.

dns-01: Klienten lægger en TXT-record på _acme-challenge.<name>. Til *.example.com bruges _acme-challenge.example.com. CA’en læser offentlig DNS; selve tjenesten kan være intern. Let’s Encrypts forklaring af HTTP- og DNS-validering.

tls-alpn-01: CA’en forbinder til port 443 og beder om acme-tls/1 via ALPN. En responder viser et særligt, midlertidigt SSL-certifikat som bevis. Jeres TLS-terminering skal understøtte metoden. RFC 8737: tls-alpn-01.

Begræns DNS-API-adgangen med en valideringszone

DNS-plugin bruger API-oplysninger til at oprette og rydde TXT-records. Med en klient på hver server får hver server adgangsoplysninger til DNS. En lækket nøgle kan ændre alt, dens rettigheder tillader. Giv derfor ikke klienten adgang til hele domænets zone.

Opret en separat valideringszone (challenge zone). Lav en CNAME viderestilling fra _acme-challenge til et navn i valideringszonen, og giv kun klienten skriveret dér. CA’en følger CNAME til TXT-recorden. Klienten eller DNS-plugin skal også kunne skrive til målet; en CNAME flytter ikke automatisk klientens API-kald. Hvert SAN-navn kan kræve sin egen viderestilling.

_acme-challenge.example.com. 300 IN CNAME example-com.acme.example.net.
example-com.acme.example.net. 300 IN TXT "<challenge-value>"

dns-persist-01 hos Google

dns-persist-01 bruger én vedvarende TXT-record på _validation-persist, som knytter domænet til CA’en og ACME-kontoen, så klienten ikke skal skrive en ny TXT-værdi ved hver fornyelse. IETF-udkastet er i version -02 fra 20-09-2026. Google Trust Services understøtter det i dag og kræver EAB. Let’s Encrypt har det ikke endnu, men det er planlagt. GlobalSign har det planlagt i 2027. ZeroSSL og Sectigo ACME understøtter det ikke. Følg Googles dns-persist-01-format og krav til klienten.

Recorden er bundet til én ACME-konto. Har hver server sin egen ACME-klient og konto, skal domænet have én TXT-record pr. server under _validation-persist. Deler serverne én konto, er én record nok, men så kan alle servere udstede for alle domænerne og tilbagekalde alle certifikaterne. Opret aldrig en ny konto på en server, der allerede bruger dns-persist-01. Skift nøglen i stedet, så recorden fortsat gælder. Google: ACME-konti og dns-persist-01

Hos FairSSL virker dns-persist med DigiCert-certifikaterne og kræver jeres egen DigiCert-konto; på den fælles konto validerer AutoDNS i stedet. Læs mere i dns-persist-01 med DigiCert: én DNS-record, og alle navne er godkendt på forhånd og dns-persist-01 i sslbrain: uden DNS-nøgler på serverne. Ved klassisk dns-01 kan I følge vores vejledning til DNS-plugin og ACME DNS-validering.

Vælg fornyelsestidspunkt, nøgletype og SAN-navne efter de systemer, der skal bruge SSL-certifikatet. Test mod staging, og opret et planlagt job med installation efter vellykket fornyelse.

Brug kun de SAN-navne, tjenesten har brug for. Vælg RSA eller ECDSA efter klienternes og tjenestens understøttelse. Lad en aktuel ACME-klient følge ARI, og kontrollér dens fornyelsesjob. En fast kalenderdato passer ikke nødvendigvis til næste SSL-certifikats gyldighed.

SSL-certifikaternes levetid falder. Tidslinjen viser de samme levetider som resten af sitet: højst 199 dage nu og 99 dage senest 15-03-2027. DigiCert skifter 24-02-2027. Gratis CA’er kan udstede kortere SSL-certifikater. Manuel fornyelse er ikke en driftsplan.

ARI giver et anbefalet fornyelsesvindue, også når en CA ønsker tidlig fornyelse. Klienterne her dokumenterer ARI. Vores vejledninger viser klientopsætning; tilpas CA-adresse og EAB, når I bruger en gratis CA.

win-acme eller simple-acme?

simple-acme er en videreførelse fra samme udvikler og beskrives som en bagudkompatibel erstatning for win-acme. Projektets egen forklaring og installationsvejledningen med wacs.exe beskriver overgangen. Brug vores simple-acme-vejledning til SSL-certifikater på Windows.

Posh-ACME: hvad styrer fornyelsestidspunktet?

Søgningen “renewaldays posh-acme” blander klienternes indstillinger. RenewalDays er en win-acme/simple-acme-indstilling, ikke en parameter til Submit-Renewal. Posh-ACME bruger RenewAfter på ordren. ARI kan opdatere tidspunktet, når CA’en understøtter det. Posh-ACME kontrollerer RenewAfter før fornyelse.

Planlæg Submit-Renewal regelmæssigt under samme bruger og konfiguration som ved opsætningen. Et job starter ikke sig selv, fordi RenewAfter er nået. -Force omgår tidskontrollen og bør ikke bruges som normal fornyelsesplan. Se Submit-Renewal-dokumentationen og Windows-opsætning med planlagte ACME-job.

Kommandoer mod Let’s Encrypt staging

Installér klienten først. Erstat example.com, mailadresse og stier med jeres egne. HTTP-eksemplerne kræver en eksisterende webroot, der kan nås på port 80; brug en testserver. Staging udsteder SSL-certifikater uden offentlig tillid. Gem dem separat, og bind dem ikke til produktion.

New-Item -ItemType Directory -Force C:\acme-staging
.\wacs.exe --source manual --host example.com --validation filesystem --webroot C:\inetpub\wwwroot --store pemfiles --pemfilespath C:\acme-staging --installation none --baseuri https://acme-staging-v02.api.letsencrypt.org/ --accepttos --emailaddress admin@example.com

sudo certbot certonly --webroot -w /var/www/html -d example.com \
  --server https://acme-staging-v02.api.letsencrypt.org/directory \
  --config-dir /etc/letsencrypt-staging --work-dir /var/lib/letsencrypt-staging \
  --logs-dir /var/log/letsencrypt-staging --agree-tos --email admin@example.com

lego --server https://acme-staging-v02.api.letsencrypt.org/directory \
  --path ./lego-staging --email admin@example.com --accept-tos \
  --domains example.com --http --http.webroot /var/www/html run

acme.sh --register-account --server letsencrypt_test --config-home ./acme-staging --accountemail admin@example.com
acme.sh --issue --server letsencrypt_test --config-home ./acme-staging \
  -d example.com --webroot /var/www/html

Set-PAServer LE_STAGE
$pArgs = @{ CFToken = (Read-Host 'Cloudflare API token' -AsSecureString) }
New-PACertificate example.com -AcceptTOS -Contact admin@example.com -Plugin Cloudflare -PluginArgs $pArgs
Get-PAOrder | Select-Object MainDomain, RenewAfter
Submit-Renewal

Når staging virker, opret en separat produktionsopsætning hos Let’s Encrypt. Brug CA’ens produktionsadresse i klienten, eller letsencrypt i acme.sh og LE_PROD i Posh-ACME. Test det planlagte job og installationsscriptet med de samme rettigheder, som de får i drift.

Installér SSL-certifikat, kæde og privat nøgle, hvor tjenesten forventer dem. Genindlæs konfigurationen eller genstart tjenesten som krævet, og kontrollér det SSL-certifikat, den faktisk viser.

Et vellykket ACME-job er ikke bevis for en vellykket installation. Brug klientens installationsfunktion eller et script efter fornyelse. Tilpas filformat, rettigheder og bindinger efter vejledningen til jeres server eller appliance.

• NetScaler: opsætning af SSL-certifikater med ACME. Følg guiden til udstyrets opsætning.
• FortiGate: ACME og installation af SSL-certifikater. Kontrollér kravene for jeres firmware og tjeneste.
• F5 BIG-IP: installation og binding af SSL-certifikater. En ACME-klient kan stå for udstedelsen; planlæg også import og binding på F5.

Hold en oversigt over SSL-certifikater, navne, servere og ansvarlige. Overvåg både fornyelsesjobbet og det SSL-certifikat, tjenesten faktisk viser. Send fejl til en ansvarlig, der kan reagere.

Let’s Encrypt stoppede udløbsmails 4. juni 2025. Et job kan forny korrekt, mens en tjeneste fortsat bruger en gammel fil eller binding. Kontrollér derfor udløb og navne på hver destination.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

En gratis FairSSL-konto giver CT-log-overvågning af jeres domæner uden agent eller installation. Slå udløbsadvarsler til for de fundne SSL-certifikater. CT-logs viser udstedelser, ikke hvad hver server bruger; et nyt SSL-certifikat til samme navne kan erstatte det gamle i overvågningen. Behold derfor også kontrol af hver tjeneste.

Aftal, hvem der reagerer på fejl, og hvordan I retter DNS, rettigheder, klienter og installationer. Gem logs et sted, de ansvarlige kan læse dem, også når serveren ikke svarer.

Kan ét navn i et SAN-SSL-certifikat ikke længere valideres, kan fornyelsen fejle for hele SSL-certifikatet. Fjern navne, I ikke længere bruger, og tjek alle navne efter domæneændringer. Hav en plan for at udstede og installere igen fra en fungerende maskine.

“domain validation failed (dns01)”

• Læs det præcise navn og den forventede TXT-værdi i klientens log. Spørg alle autoritative navneservere; et svar fra jeres lokale resolver kan være cachet.
• Tjek DNS-propagation og TTL. Vent på, at ændringen er synlig hos de autoritative servere og gamle svar er udløbet i caches, før I prøver igen.
• Følg CNAME til den rigtige zone. Tjek, at DNS-plugin skriver i målzonen og ikke i en privat DNS-zone eller på et forkert navn.
• Ryd forældede TXT-værdier. Fjern ikke værdier, som andre aktive valideringer bruger; samtidige ordrer kan kræve forskellige værdier på samme navn.
• Tjek CAA og issuewild for den valgte CA. Ved rate limits skal I følge fejlens retry-tid og bruge staging til fejlsøgning. Gentagne forsøg løser ikke en forkert DNS-record.

dig +short NS example.com
dig @ns1.example.com _acme-challenge.example.com CNAME +noall +answer
dig +short NS acme.example.net
dig @ns1.example.net example-com.acme.example.net TXT +noall +answer
nslookup -type=TXT example-com.acme.example.net ns1.example.net
dig @ns1.example.com example.com CAA +noall +answer

Når http-01 fejler

Tjek port 80 i firewall og NAT, og at A/AAAA peger på den rigtige server. Kontrollér, at webroot svarer til det berørte værtsnavn. Prøv challenge-URL’en udefra med den aktuelle token, mens valideringen afventer. Redirects må ikke sende CA’en til login, en forkert sti eller en utilgængelig vært. Let’s Encrypt beskriver de tilladte redirects.

curl -v --max-time 15 http://example.com/.well-known/acme-challenge/TOKEN
curl -vL --max-redirs 10 --max-time 30 http://example.com/.well-known/acme-challenge/TOKEN

Skriv klient og version, CA og ACME-konto, valideringsmetode, DNS-zone, fornyelsesjob, filstier og installationskommandoer ned. Notér også, hvor den private nøgle ligger, og hvem der har adgang.

Tag en beskyttet backup af ACME-kontonøglen og den nødvendige konfiguration. Kontonøglen er ikke SSL-certifikatets private nøgle. Notér ejer, alarmer og proceduren for gendannelse. De ansvarlige skal kunne finde dokumentationen og gendanne opsætningen.