How the ACME protocol works

Before the client can send requests, it fetches the server's directory object. The directory contains URLs for all ACME endpoints: newNonce, newAccount, newOrder, revokeCert, keyChange, and metadata such as termsOfService and externalAccountRequired.

The client then fetches a replay nonce via a HEAD request to the newNonce URL. The nonce is included in the JWS header of all subsequent POST requests to prevent replay attacks. The server returns a new nonce in the Replay-Nonce header of every response, so the client always has a fresh nonce ready.

# Fetch 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
  }
}

# Fetch initial nonce
HEAD https://fairssl.dk/acme/v1/new-nonce
→ Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA

The client sends a newOrder request with a list of domain names (identifiers). The server returns an order with status pending and a list of authorization URLs, one per domain name.

// newOrder request payload
{
  "identifiers": [
    { "type": "dns", "value": "your-domain.com" },
    { "type": "dns", "value": "www.your-domain.com" }
  ]
}

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

Order states

An order goes through the following states (defined in RFC 8555 §7.1.6):

pending: waiting for validations. ready: all domains validated, ready for finalize. processing: the CA is signing the certificate. valid: certificate ready for download. The order can also go to invalid (validation failed) or expired (timeout).

When all authorizations are valid, the order transitions to ready. The client now sends a finalize request with a CSR (Certificate Signing Request) in DER format, base64url-encoded.

The CSR contains the public key for the certificate (not the account key) and the requested domain names as Subject Alternative Names. The ACME server verifies that the domain names in the CSR match those in the order, forwards to the CA for signing, and the order transitions to 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) is an extension to ACME that lets the CA signal the optimal renewal window for each certificate. Without ARI, clients renew based on a fixed interval (e.g. "30 days before expiry"). With ARI, the client asks daily: "when should I renew this certificate?" and the CA responds with a precise window.

Why ARI is critical from 2026

With shorter certificate lifetimes (200 days from March 2026, 100 days from 2027, 47 days from 2029), the margin for error is minimal. A fixed 30-day renewal interval gives only 17 days of buffer with 47-day certificates. If renewal fails multiple times, the certificate expires.

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

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

Automation is only valuable if you can verify that it works. The FairSSL portal provides an overview of all ACME-managed certificates.