Sådan virker ACME-protokollen

Før klienten kan sende requests, henter den serverens directory-objekt. Directory indeholder URL'er til alle ACME-endpoints: newNonce, newAccount, newOrder, revokeCert, keyChange og metadata som termsOfService og externalAccountRequired.

Klienten henter derefter en replay-nonce via et HEAD-request til newNonce-URL'en. Noncen inkluderes i JWS-headeren på alle efterfølgende POST-requests for at forhindre replay-angreb. Serveren returnerer en ny nonce i Replay-Nonce-headeren på hvert svar, så klienten altid har en frisk nonce klar.

# Hent directory
GET https://fairssl.dk/acme

{
  "newNonce":    "https://fairssl.dk/acme/v1/new-nonce",
  "newAccount":  "https://fairssl.dk/acme/v1/new-account",
  "newOrder":    "https://fairssl.dk/acme/v1/new-order",
  "keyChange":   "https://fairssl.dk/acme/v1/key-change",
  "revokeCert":  "https://fairssl.dk/acme/v1/revoke-cert",
  "renewalInfo": "https://fairssl.dk/acme/v1/renewal-info",
  "meta": {
    "termsOfService": "https://www.fairssl.dk/en/terms-of-sale/",
    "externalAccountRequired": true
  }
}

# Hent første nonce
HEAD https://fairssl.dk/acme/v1/new-nonce
→ Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA

Klienten sender et newOrder-request med en liste af domænenavne (identifiers). Serveren returnerer en ordre med status pending og en liste af authorization-URL'er, en per domænenavn.

// newOrder request payload
{
  "identifiers": [
    { "type": "dns", "value": "example.dk" },
    { "type": "dns", "value": "www.example.dk" }
  ]
}

// Server response
{
  "status": "pending",
  "expires": "2026-03-19T12:00:00Z",
  "authorizations": [
    "https://acme.fairssl.dk/acme/authz/abc123",
    "https://acme.fairssl.dk/acme/authz/def456"
  ],
  "finalize": "https://acme.fairssl.dk/acme/order/xyz/finalize"
}

Ordretilstande

En ordre gennemgår disse tilstande (defineret i RFC 8555 §7.1.6):

pending: venter på valideringer. ready: alle domæner valideret, klar til finalize. processing: CA signerer certifikatet. valid: certifikat klar til download. Ordren kan også gå til invalid (validering fejlet) eller expired (timeout).

Når alle authorizations er valid, skifter ordren til ready. Klienten sender nu et finalize-request med en CSR (Certificate Signing Request) i DER-format, base64url-encoded.

CSR'en indeholder den offentlige nøgle til certifikatet (ikke account-nøglen) og de ønskede domænenavne som Subject Alternative Names. ACME-serveren verificerer at domænenavnene i CSR'en matcher dem i ordren, videresender til CA'en for signering, og ordren skifter til processing.

// Finalize request
POST /acme/order/xyz/finalize

{
  "csr": "MIIBkTCB...base64url-encoded-DER..."
}

// Server response (order transitions to processing, then valid)
{
  "status": "valid",
  "certificate": "https://acme.fairssl.dk/acme/cert/abc123"
}

ARI (RFC 9773) er en udvidelse til ACME der lader CA'en signalere det optimale fornyelsesvindue for hvert certifikat. Uden ARI fornyer klienter baseret på et fast interval (f.eks. "30 dage før udløb"). Med ARI spørger klienten dagligt: "hvornår skal jeg forny dette certifikat?" og CA'en svarer med et præcist vindue.

Hvorfor ARI er kritisk fra 2026

Med kortere certifikatlevetider (200 dage fra marts 2026, 100 dage fra 2027, 47 dage fra 2029) er marginen for fejl minimal. Et fast 30-dages fornyelsesinterval giver kun 17 dages buffer med 47-dages certifikater. Hvis fornyelse fejler flere gange, udløber certifikatet.

# ARI endpoint response
GET /acme/renewal-info/certID

{
  "suggestedWindow": {
    "start": "2026-04-15T00:00:00Z",
    "end":   "2026-04-20T00:00:00Z"
  }
}

Automatisering er kun værdifuld, hvis du kan verificere at den virker. FairSSL-portalen giver overblik over alle ACME-administrerede certifikater.