Så fungerar ACME-protokollet

Innan klienten kan skicka requests hämtar den serverns directory-objekt. Directory innehåller URL:er till alla ACME-endpoints: newNonce, newAccount, newOrder, revokeCert, keyChange och metadata som termsOfService och externalAccountRequired.

Klienten hämtar därefter en replay-nonce via ett HEAD-request till newNonce-URL:en. Noncen inkluderas i JWS-headern på alla efterföljande POST-requests för att förhindra replay-attacker. Servern returnerar en ny nonce i Replay-Nonce-headern på varje svar, så klienten alltid har en färsk nonce redo.

# Hämta 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
  }
}

# Hämta första nonce
HEAD https://fairssl.dk/acme/v1/new-nonce
→ Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA

Klienten skickar ett newOrder-request med en lista av domännamn (identifiers). Servern returnerar en order med status pending och en lista av authorization-URL:er, en per domännamn.

// newOrder request payload
{
  "identifiers": [
    { "type": "dns", "value": "ditt-doman.se" },
    { "type": "dns", "value": "www.ditt-doman.se" }
  ]
}

// Serversvar
{
  "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"
}

Ordertillstånd

En order går igenom följande tillstånd (definierade i RFC 8555 §7.1.6):

pending: väntar på valideringar. ready: alla domäner validerade, redo för finalize. processing: CA:n signerar certifikatet. valid: certifikatet är redo för nedladdning. Ordern kan också gå till invalid (validering misslyckades) eller expired (timeout).

När alla authorizations är valid skiftar ordern till ready. Klienten skickar nu ett finalize-request med en CSR (Certificate Signing Request) i DER-format, base64url-kodad.

CSR:en innehåller den offentliga nyckeln för certifikatet (inte account-nyckeln) och de önskade domännamnen som Subject Alternative Names. ACME-servern verifierar att domännamnen i CSR:en matchar dem i ordern, vidarebefordrar till CA:n för signering, och ordern skiftar till processing.

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

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

// Serversvar (ordern går till processing, sedan valid)
{
  "status": "valid",
  "certificate": "https://acme.fairssl.dk/acme/cert/abc123"
}

ARI (RFC 9773) är ett tillägg till ACME som låter CA:n signalera det optimala förnyelsefönstret för varje certifikat. Utan ARI förnyar klienter baserat på ett fast intervall (t.ex. "30 dagar före utgång"). Med ARI frågar klienten dagligen: "när ska jag förnya detta certifikat?" och CA:n svarar med ett exakt fönster.

Varför ARI är kritiskt från 2026

Med kortare certifikatlivslängder (200 dagar från mars 2026, 100 dagar från 2027, 47 dagar från 2029) är marginalen för fel minimal. Ett fast 30-dagars förnyelsefönster ger bara 17 dagars buffert med 47-dagars certifikat. Om förnyelse misslyckas flera gånger går certifikatet ut.

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

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

Automatisering är bara värdefull om du kan verifiera att den fungerar. FairSSL-portalen ger översikt över alla ACME-hanterade certifikat.