Automatisér certifikat-udstedelse og fornyelse med ACME

Certifikater bliver kortere og kortere — 90 dages levetid er nu normen, og endnu kortere er på vej. Manuel fornyelse hver tredje måned, på tværs af dusinvis af endpoints, er en garanti for at noget udløber på det værste tidspunkt. ACME-protokollen løser det ved at gøre udstedelse og fornyelse til en API-operation. Her er hvordan det virker, og hvilken klient du skal vælge.

Kort svar

ACME (Automatic Certificate Management Environment, RFC 8555) er den protokol Let's Encrypt og andre CA'er bruger til at udstede certifikater uden manuel indblanding. En ACME-klient beviser at du kontrollerer et domæne — via en HTTP-01- eller DNS-01-challenge — og får derefter et certifikat udstedt automatisk. Samme klient fornyer det igen før udløb. Med 90-dages levetider er automatisering ikke længere en luksus, men en forudsætning for drift.

Hvorfor automatisering nu er obligatorisk

Offentlige certifikat-levetider er faldet fra flere år til 90 dage, og CA/Browser Forum har vedtaget en plan mod 47 dage. Et certifikat der skal fornyes hver 90. (eller 47.) dag, på tværs af alle jeres endpoints, kan ikke håndteres i et regneark. Automatisering med ACME betyder at fornyelse sker af sig selv, lang tid før certifikatet udløber — og at et menneskeligt sjusk ikke kan vælte produktionen.

De to challenge-typer

Challenge	Sådan bevises kontrol	Wildcard?
HTTP-01	CA henter en token på `http://domæne/.well-known/acme-challenge/<token>`	Nej
DNS-01	Du opretter en `_acme-challenge` TXT-record med en valideringsværdi	Ja

HTTP-01 er enklest når serveren er offentligt tilgængelig på port 80. DNS-01 er det eneste der kan udstede wildcard-certifikater, og virker også for interne servere uden offentlig HTTP.

certbot — Linux-standarden

certbot er den mest udbredte klient. Til nginx med automatisk konfiguration:

# Udsted og konfigurér nginx i én operation (HTTP-01)
sudo certbot --nginx -d example.com -d www.example.com

# Kun udsted certifikatet, rør ikke konfigurationen (webroot)
sudo certbot certonly --webroot -w /var/www/html \
  -d example.com -d www.example.com

# Wildcard kræver DNS-01
sudo certbot certonly --manual --preferred-challenges dns \
  -d "*.example.com" -d example.com

certbot installerer en systemd-timer der dagligt kører certbot renew. Fornyelse sker automatisk når under 30 dage er tilbage. Test at fornyelsen virker uden faktisk at forny:

sudo certbot renew --dry-run

win-acme — Windows og IIS

På Windows er win-acme (wacs) standardvalget. Den binder certifikatet direkte i IIS og opretter en Scheduled Task til fornyelse:

# Interaktiv guide
wacs.exe

# Uovervåget: alle IIS-bindings, automatisk fornyelse
wacs.exe --target iis --siteid 1 \
  --installation iis --store certificatestore

win-acme håndterer selv certifikat-lageret i Windows og genstarter/reloader IIS, så det fornyede certifikat tages i brug.

lego — ét binært, mange DNS-udbydere

lego er en enkelt Go-binær uden afhængigheder, stærk på DNS-01 med over 100 indbyggede DNS-udbydere. Velegnet til CI/CD og scripts:

# DNS-01 via Cloudflare, inkl. wildcard
CF_DNS_API_TOKEN="..." lego \
  --email ops@example.com \
  --dns cloudflare \
  --domains "*.example.com" --domains example.com \
  run

# Fornyelse (kun hvis under 30 dage tilbage)
lego ... renew --days 30

cert-manager — automatisering i Kubernetes

I Kubernetes overlader man hele livscyklussen til cert-manager. Du definerer en ClusterIssuer og en Certificate, og controlleren udsteder, gemmer i en Secret og fornyer automatisk:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      - http01:
          ingress:
            class: nginx
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-tls
  namespace: web
spec:
  secretName: example-tls
  dnsNames:
    - example.com
    - www.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Vi har en dedikeret gennemgang af cert-manager og dens ressourcetyper.

Test mod staging — og pas på rate limits

Let's Encrypt har rate limits (bl.a. et loft over antal certifikater per domæne per uge). Kører en automatisering der fejler i en løkke, kan du hurtigt ramme loftet og blive blokeret i timer. Test derfor altid mod staging-miljøet først — det udsteder ikke-betroede certifikater uden at tælle mod dine rate limits. Med certbot bruger du --staging; med cert-manager peger du ClusterIssuer på acme-staging-v02. Skift først til produktion når flowet virker. En ACME-klient prøver desuden automatisk fornyelse igen ved midlertidige fejl — men kun så længe den stadig kører og kan nå challenge-endpointet.

Det automatisering ikke løser

Selv perfekt automatisering kan fejle stille: et webroot der ikke længere er tilgængeligt, en DNS-udbyder der har skiftet API-token, en service der ikke blev reloadet efter fornyelse, eller et certifikat der bliver udstedt men serveret uden fuld kæde. I alle disse tilfælde tror automatiseringen at den lykkedes, mens brugerne ser en fejl. Se også guiden til de typiske valg af TLS-opsætning på nginx og Apache, samt hvor decryption sker ved offloading, passthrough og bridging, og platformsspecifikt på Azure og F5 BIG-IP.

CertControl: sikkerhedsnettet under jeres automatisering

ACME automatiserer udstedelsen — men nogen skal stadig opdage når automatiseringen fejler tavst. CertControl scanner jeres endpoints udefra, bekræfter at det fornyede certifikat faktisk serveres, at den fulde kæde er med, at protokoller og cipher suites er stærke — og advarer i god tid hvis et certifikat nærmer sig udløb uden at være blevet fornyet. Det fanger præcis de tilfælde hvor automatiseringen troede den lykkedes.

Ofte stillede spørgsmål

Hvad er ACME?

ACME (RFC 8555) er en standardiseret protokol til at udstede og forny TLS-certifikater automatisk. En ACME-klient beviser domæne-kontrol via en HTTP-01- eller DNS-01-challenge, og CA'en udsteder derefter certifikatet uden manuel indblanding.

Hvad er forskellen på HTTP-01 og DNS-01?

HTTP-01 beviser kontrol ved at CA'en henter en token over HTTP på dit domæne — enkelt, men kan ikke lave wildcard. DNS-01 beviser kontrol via en TXT-record og er det eneste der kan udstede wildcard-certifikater og virke for interne servere.

Hvilken ACME-klient bør jeg vælge?

certbot til Linux/nginx/Apache, win-acme til Windows/IIS, lego til CI/CD og DNS-01 med mange udbydere, og cert-manager til Kubernetes. De taler alle samme ACME-protokol mod samme CA'er.

Kan jeg lave wildcard-certifikater med ACME?

Ja, men kun via DNS-01-challenge. HTTP-01 kan ikke udstede wildcards, fordi den kun kan validere ét konkret hostnavn ad gangen.

Fornyer ACME-klienter automatisk?

Ja. certbot og win-acme installerer henholdsvis en timer og en Scheduled Task, lego køres typisk fra cron/CI, og cert-manager fornyer som en del af sin reconcile-loop. Fornyelse sker normalt når omkring en tredjedel af levetiden er tilbage.

Hvad sker der hvis fornyelsen fejler?

Klienten prøver igen ved næste kørsel, men hvis årsagen er vedvarende (ændret DNS-token, lukket port 80, flyttet webroot) udløber certifikatet til sidst. Derfor bør automatisering altid suppleres med uafhængig overvågning af det der faktisk serveres.

Se platformen Book demo

Automatisér certifikater med ACME