skip to content
QUANTUM NEXUM

← vault

ACME

Automatic Certificate Management Environment — the protocol that automates domain validation and certificate issuance. Defined in RFC 8555 (March 2019); used by Let's Encrypt and most modern CA infrastructure.

Protocol overview

Property Value
Standard RFC 8555 (March 2019)
Purpose Automate domain validation and certificate issuance
Transport HTTPS with JSON payloads
Authentication JWS (JSON Web Signature) with account keypair
Account key algorithms RS256, ES256, ES384, ES512, EdDSA — classical algorithms used to authenticate ACME requests; the certificates issued by the CA can use ML-DSA or other PQC algorithms independently

Ed25519 (RFC 8032) is a classical elliptic-curve signature algorithm, not a post-quantum algorithm. It is listed here because ACME clients may use it as an account key; it carries no FIPS 140-3 validation.

How ACME works

  1. Account registration — client generates a keypair and registers with the CA server.
  2. Order creation — request a certificate for one or more domains; server returns a set of authorization challenges.
  3. Challenge response — prove domain control via HTTP, DNS, or TLS-ALPN.
  4. Finalize and download — submit a CSR; server issues the signed certificate.

Challenge types

Challenge Method Use case
http-01 Place a token file at /.well-known/acme-challenge/{token} Web servers with HTTP access on port 80
dns-01 Create a TXT record at _acme-challenge.{domain} Wildcard certificates; servers without HTTP access
tls-alpn-01 Serve a special TLS certificate on port 443 using the acme-tls/1 ALPN token Environments where only port 443 is reachable (RFC 8737)

Standard endpoints

All URLs are relative to the directory URL returned by GET /directory.

Endpoint Method Purpose
/directory GET Discover all ACME endpoint URLs
/acme/new-nonce HEAD / GET Obtain an anti-replay nonce
/acme/new-acct POST Register or look up an account
/acme/new-order POST Create a certificate order
/acme/revoke-cert POST Revoke an issued certificate
/acme/key-change POST Rotate the account keypair

Order lifecycle

pending     Challenges not yet completed
ready       All challenges passed; awaiting finalization (CSR submission)
processing  CA is generating the certificate
valid       Certificate issued and available for download
invalid     Validation failed; order cannot proceed

State machine: pending → ready → processing → valid. Any state can transition to invalid on error.

JWS request structure

All ACME POST requests are signed with JWS. The protected header identifies the account, carries a fresh nonce, and binds the request to a specific URL. The example below is illustrative; use your own ACME server URL.

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/123",
    "nonce": "abc123...",
    "url": "https://example.com/acme/new-order"
  }),
  "payload": base64url({...}),
  "signature": "..."
}

External Account Binding (EAB)

Enterprise ACME servers may require EAB to bind ACME accounts to pre-existing out-of-band credentials. Defined in RFC 8555 §7.3.4. The CA provides a MAC key and key ID; the client includes an EAB JWS in the new-acct request.

Post-quantum considerations

The ACME protocol is algorithm-agnostic. Challenge tokens are random values — no cryptographic change is needed to the challenge mechanism itself. What changes is the keypair used for account authentication and the algorithms in the CSR and issued certificate.

Layer PQC applicability
Account keys Can use ML-DSA or hybrid signatures in place of classical ECDSA / RSA
CSR signing Submit an ML-DSA CSR in the finalize step; the CA issues an ML-DSA certificate
Challenge tokens Random values — no algorithm change required
CAA records DNS CAA validation (RFC 8659) is algorithm-agnostic; works identically for PQC and classical issuance

Quantum Nexum ACME endpoint

Quantum Nexum's hosted ACME endpoint is planned, gated on the PKI refactor. See /acme/ for current status and self-hosting guidance using the Spork ACME server.

Popular ACME clients

Client Language Notes
Certbot Python Official EFF / Let's Encrypt client; large plugin ecosystem
acme.sh Shell Pure shell; 170+ DNS provider integrations
Caddy Go Built-in ACME with automatic HTTPS
Lego Go Library + CLI; 100+ DNS providers
Spork CLI (Quantum Nexum) Rust PQC-native; spork acme subcommands; http-01 / dns-01 / tls-alpn-01 (alpha)

Further reading