Gratis SSL-certifikat med ACME: guide till konfiguration och drift

ACME är protokollet mellan er klient och en CA. Klienten beställer SSL-certifikatet och bevisar kontrollen över namnen. Installation i rätt tjänst är ett separat steg.

RFC 8555: ACME beskriver förloppet: account skapar ACME-kontot; order beställer namnen; authorization anger vad som behöver godkännas; challenge bevisar domänkontrollen; finalize skickar en CSR; certificate låter klienten hämta det utfärdade SSL-certifikatet.

ARI (ACME Renewal Information, RFC 9773) låter CA:n föreslå ett förnyelsefönster. Klienten behöver fortfarande köras regelbundet och installera resultatet. Läs om ACME-protokollet från beställning till förnyelse.

Välj CA efter er valideringsmetod och drift. Skapa det konto som behövs, läs CA:ns villkor och tillåt den i era CAA-poster.

ACME-klienten skapar kontot hos Let’s Encrypt. Tabellen lyfter fram http-01 och dns-01; Let’s Encrypt stöder även tls-alpn-01.

Google Trust Services kräver ett Google Cloud-konto och ett projekt med Public CA API aktiverat. Skapa en EAB-nyckel (External Account Binding) för att koppla ACME-kontot till projektet. Projektets ACME-konton delar Public CA-kvoter. ZeroSSL kräver också EAB-uppgifter; deras gratis ACME-tjänst är skild från övriga API-produkter.

En CAA-post begränsar vilka CA:er som får utfärda. Tillåt er valda CA med issue och kontrollera issuewild för wildcards. Använd CAA-reglerna och FairSSL:s CAA-generator för rätt DNS-post.

Rate limits för utfärdande

När certifikatens livslängd blir kortare slår rate limits hårdare, eftersom ni utfärdar oftare. Gränserna betyder mest när ni utfärdar många nya certifikat på en gång, till exempel när en ny miljö tillkommer, när ni byter CA eller när ni återställer servrar från backup. Ett certifikat som flyttar från en annan CA räknas som nytt hos den nya CA:n.

Planerar ni många nya certifikat, fördela dem på flera konton eller projekt där gränsen gäller per konto. Sätt upp en extra CA i förväg och lägg till den i era CAA-poster, så att ni kan byta utan att vänta.

Välj en metod som både CA och klient stöder. Använd DNS-validering för wildcards och interna servrar med offentliga domännamn. Begränsa klientens DNS-behörigheter till valideringen.

http-01: Klienten lägger ett svar på http://<name>/.well-known/acme-challenge/<token>. CA:n hämtar det via port 80. Metoden kan inte validera wildcards. En intern server kan bara använda metoden om ett offentligt tillgängligt HTTP-system besvarar utmaningen för namnet.

dns-01: Klienten skapar en TXT-post på _acme-challenge.<name>. För *.example.com används _acme-challenge.example.com. CA:n läser offentlig DNS; själva tjänsten kan vara intern. Let’s Encrypt förklarar HTTP- och DNS-validering.

tls-alpn-01: CA:n ansluter till port 443 och begär acme-tls/1 via ALPN. En responder visar ett särskilt, tillfälligt SSL-certifikat som bevis. Er TLS-terminering måste stödja metoden. RFC 8737: tls-alpn-01.

Begränsa DNS-API-behörigheten med en valideringszon

DNS-plugin använder API-uppgifter för att skapa och ta bort TXT-poster. Med en klient på varje server får varje server DNS-behörighetsuppgifter. En läckt nyckel kan ändra allt som behörigheterna tillåter. Ge därför inte klienten åtkomst till hela domänens zon.

Skapa en separat valideringszon (challenge zone). Gör en CNAME-vidarebefordran från _acme-challenge till ett namn i valideringszonen och ge klienten skrivbehörighet bara där. CA:n följer CNAME till TXT-posten. Klienten eller DNS-plugin måste också kunna skriva till målet; en CNAME flyttar inte automatiskt klientens API-anrop. Varje SAN-namn kan behöva en egen vidarebefordran.

_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 använder en beständig TXT-post på _validation-persist som knyter domänen till CA:n och ACME-kontot, så att klienten inte behöver skriva ett nytt TXT-värde vid varje förnyelse. IETF-utkastet är i version -02 från 2026-09-20. Google Trust Services stöder det i dag och kräver EAB. Let’s Encrypt har det inte än, men det är planerat. GlobalSign har det planerat till 2027. ZeroSSL och Sectigo ACME stöder det inte. Följ Googles dns-persist-01-format och krav på klienten.

Posten är bunden till ett ACME-konto. Har varje server sin egen ACME-klient och sitt eget konto behöver domänen en TXT-post per server under _validation-persist. Delar servrarna ett konto räcker en post, men då kan alla servrar utfärda för alla domänerna och återkalla alla certifikaten. Skapa aldrig ett nytt konto på en server som redan använder dns-persist-01. Byt nyckeln i stället, så att posten fortsätter att gälla. Google: ACME-konton och dns-persist-01

Hos FairSSL fungerar dns-persist med DigiCert-certifikaten och kräver ert eget DigiCert-konto; på det gemensamma kontot validerar AutoDNS i stället. Läs mer i dns-persist-01 med DigiCert: en DNS-post, och alla namn är godkända i förväg och dns-persist-01 i sslbrain: inga DNS-nycklar på servrarna. För klassisk dns-01 kan ni följa vår guide till DNS-plugin och ACME DNS-validering.

Välj förnyelsetidpunkt, nyckeltyp och SAN-namn efter systemen som ska använda SSL-certifikatet. Testa mot staging och skapa ett schemalagt jobb med installation efter lyckad förnyelse.

Ta bara med de SAN-namn som tjänsten behöver. Välj RSA eller ECDSA efter klienternas och tjänstens stöd. Låt en aktuell ACME-klient följa ARI och kontrollera dess förnyelsejobb. Ett fast kalenderdatum passar inte nödvändigtvis nästa SSL-certifikats giltighetstid.

SSL-certifikatens giltighetstid blir kortare. Tidslinjen visar samma giltighetstider som resten av webbplatsen: högst 199 dagar nu och 99 dagar senast 2027-03-15. DigiCert byter 2027-02-24. Gratis CA:er kan utfärda SSL-certifikat med kortare giltighetstid. Manuell förnyelse är ingen driftsplan.

ARI ger ett rekommenderat förnyelsefönster, även när en CA vill ha tidig förnyelse. Klienterna här dokumenterar ARI-stöd. Våra guider visar klientkonfiguration; anpassa CA-adress och EAB när ni använder en gratis CA.

win-acme eller simple-acme?

simple-acme är en fortsättning från samma utvecklare och beskrivs som en bakåtkompatibel ersättare för win-acme. Projektets egen förklaring och installationsguiden med wacs.exe beskriver övergången. Använd vår simple-acme-guide för SSL-certifikat i Windows.

Posh-ACME: vad styr förnyelsetidpunkten?

Sökningen “renewaldays posh-acme” blandar klienternas inställningar. RenewalDays är en win-acme/simple-acme-inställning, inte en parameter till Submit-Renewal. Posh-ACME använder orderns RenewAfter. ARI kan uppdatera tidpunkten när CA:n stöder det. Posh-ACME kontrollerar RenewAfter före förnyelse.

Schemalägg Submit-Renewal regelbundet under samma användare och konfiguration som vid installationen. Ett jobb startar inte av sig självt när RenewAfter har nåtts. -Force kringgår tidskontrollen och bör inte användas som normal förnyelseplan. Se dokumentationen för Submit-Renewal och Windows-konfiguration med schemalagda ACME-jobb.

Kommandon mot Let’s Encrypt staging

Installera klienten först. Byt ut example.com, e-postadress och sökvägar mot era egna. HTTP-exemplen kräver en befintlig webroot som nås på port 80; använd en testserver. Staging utfärdar SSL-certifikat utan offentlig tillit. Spara dem separat och bind dem inte till 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 fungerar skapar ni en separat produktionskonfiguration hos Let’s Encrypt. Använd CA:ns produktionsadress i klienten, eller letsencrypt i acme.sh och LE_PROD i Posh-ACME. Testa det schemalagda jobbet och installationsskriptet med de behörigheter de får i drift.

Installera SSL-certifikat, certifikatkedja och privat nyckel där tjänsten förväntar sig dem. Läs in konfigurationen igen eller starta om tjänsten efter behov och kontrollera det SSL-certifikat den faktiskt visar.

Ett lyckat ACME-jobb bevisar inte att installationen lyckades. Använd klientens installationsfunktion eller ett skript efter förnyelse. Anpassa filformat, behörigheter och bindningar efter guiden för er server eller appliance.

• NetScaler: konfigurera SSL-certifikat med ACME. Följ guiden för utrustningens konfiguration.
• FortiGate: ACME och installation av SSL-certifikat. Kontrollera kraven för er firmware och tjänst.
• F5 BIG-IP: installation och bindning av SSL-certifikat. En ACME-klient kan sköta utfärdandet; planera även import och bindning på F5.

Håll en förteckning över SSL-certifikat, namn, servrar och ansvariga. Övervaka både förnyelsejobbet och det SSL-certifikat tjänsten faktiskt visar. Skicka fel till någon som kan agera.

Let’s Encrypt slutade skicka e-post om utgångsdatum 4 juni 2025. Ett jobb kan förnya korrekt medan en tjänst fortfarande använder en gammal fil eller bindning. Kontrollera därför giltighet och namn på varje 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

Ett gratis FairSSL-konto ger CT-loggövervakning av era domäner utan agent eller installation. Aktivera utgångsvarningar för de upptäckta SSL-certifikaten. CT-loggar visar utfärdanden, inte vad varje server använder; ett nytt SSL-certifikat för samma namn kan ersätta det gamla i övervakningen. Behåll därför även kontrollen av varje tjänst.

Bestäm vem som reagerar på fel och hur ni rättar DNS, behörigheter, klienter och installationer. Spara loggar där de ansvariga kan läsa dem, även när servern inte svarar.

Om ett namn i ett SAN-SSL-certifikat inte längre kan valideras kan förnyelsen misslyckas för hela SSL-certifikatet. Ta bort namn ni inte längre använder och kontrollera alla namn efter domänändringar. Ha en plan för att utfärda och installera igen från en fungerande dator.

“domain validation failed (dns01)”

• Läs exakt namn och förväntat TXT-värde i klientens logg. Fråga alla auktoritativa namnservrar; er lokala resolver kan ge ett cachelagrat svar.
• Kontrollera DNS-propagering och TTL. Vänta tills ändringen syns hos de auktoritativa servrarna och gamla cachelagrade svar har löpt ut innan ni försöker igen.
• Följ CNAME till rätt zon. Kontrollera att DNS-plugin skriver i målzonen, inte i en privat DNS-zon eller på fel namn.
• Rensa gamla TXT-värden. Behåll värden som andra aktiva valideringar använder; samtidiga ordrar kan kräva olika värden på samma namn.
• Kontrollera CAA och issuewild för vald CA. Vid rate limits ska ni följa felets angivna tid för nästa försök och felsöka i staging. Upprepade försök rättar inte en felaktig DNS-post.

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 misslyckas

Kontrollera port 80 i brandvägg och NAT och att A/AAAA pekar på rätt server. Kontrollera att webroot hör till rätt värdnamn. Prova challenge-URL:en utifrån med aktuell token medan valideringen väntar. Omdirigeringar får inte leda CA:n till inloggning, fel sökväg eller en otillgänglig värd. Let’s Encrypt beskriver tillåtna omdirigeringar.

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 ned klient och version, CA och ACME-konto, valideringsmetod, DNS-zon, förnyelsejobb, sökvägar och installationskommandon. Notera också var den privata nyckeln finns och vem som har åtkomst.

Ta en skyddad säkerhetskopia av ACME-kontonyckeln och nödvändig konfiguration. Kontonyckeln är inte SSL-certifikatets privata nyckel. Notera ansvarig, larm och återställningsprocedur. De ansvariga ska kunna hitta dokumentationen och återställa konfigurationen.