How SPORK ACME Works

SPORK ACME is a multi-protocol certificate server built entirely in Rust. It handles certificate issuance via ACME, EST, and SCEP from a single binary. This page explains its architecture, protocols, and security model.

Architecture Overview

Single Binary, Eight Crates

SPORK ACME compiles to a single static binary from 8 internal Rust crates. All protocols, the admin dashboard, and the setup wizard run in one process on a single port (default 6446).

                        spork-acme (single binary, port 6446)
                        +-----------------------------------------+
                        |                                         |
  ACME clients -------->|  /acme/directory    ACME (RFC 8555)     |
  (certbot, acme.sh)    |                                         |
                        |  /.well-known/est   EST  (RFC 7030)     |
  EST clients --------->|                                         |
                        |  /scep              SCEP (RFC 8894)     |
  SCEP clients -------->|                                         |
                        |  /admin             Admin Dashboard     |
  Browser ------------->|  /health            Health (JSON)       |
                        |  /metrics           Prometheus          |
                        |                                         |
                        |  +-----------------------------------+  |
                        |  |  Signer: micro-CA (local)         |  |
                        |  |  Signer: Windows CA (WinRM)       |  |
                        |  |  Signer: NDES (SCEP bridge)       |  |
                        |  +-----------------------------------+  |
                        |                                         |
                        |  State: /opt/spork-acme/                |
                        |  (SQLite + files, encrypted lockbox)    |
                        +-----------------------------------------+

CA Hierarchy

The setup wizard offers four CA hierarchy modes:

# 2-Tier hierarchy (default)
Root CA (offline key, encrypted in lockbox)
  |
  +-- Issuing CA (operational, signs all certificates)
        |
        +-- End-entity certificates (TLS server, TLS client)

# 3-Tier hierarchy
Root CA (offline key, encrypted in lockbox)
  |
  +-- Policy CA (intermediate, constrained by policy)
        |
        +-- Issuing CA (operational, signs all certificates)
              |
              +-- End-entity certificates

Storage

All state is stored in the state directory (default /opt/spork-acme/):

• SQLite database: Certificates, ACME accounts, orders, authorizations, nonces
• Encrypted lockbox: CA private keys (AES-256-GCM + Argon2id)
• CA certificates: PEM files for the CA chain
• Domain policy: domain-policy.toml configuration file
• Environment file: spork-acme.env with runtime configuration

No external database server is required. The SQLite database and file-based state are fully self-contained.

Three Protocols

SPORK ACME serves three certificate enrollment protocols on a single port. Choose based on your use case:

Challenge Types (ACME)

Three Signers

Each protocol can use any of the three signing backends:

Post-Quantum Cryptography

SPORK ACME supports NIST's post-quantum standards alongside classical algorithms.

Migration Strategy

SPORK ACME supports hybrid certificates that combine a classical signature with a post-quantum signature. This provides backwards compatibility: classical clients verify the ECDSA signature, PQC-aware clients verify both.

The setup wizard offers post-quantum algorithm choices during CA initialization. You can select ML-DSA or hybrid composite algorithms for both the Root CA and Issuing CA.

Security Model

Encrypted Lockbox

All CA private keys are stored in an encrypted lockbox:

• Encryption: AES-256-GCM authenticated encryption
• Key derivation: Argon2id (memory-hard KDF) from a passphrase set during the wizard
• At rest: Keys never exist on disk in plaintext
• In memory: Keys are decrypted only when needed for signing operations

Domain Policy

The domain-policy.toml file controls which domains the server will issue certificates for:

# domain-policy.toml
# Deny-by-default: only explicitly allowed patterns can get certificates

[[allow]]
pattern = "*.quantumnexus.com"

[[allow]]
pattern = "quantumnexus.com"

[[deny]]
pattern = "*.internal.quantumnexus.com"

Domain policy uses glob patterns and is deny-by-default. If no allow rules match a requested domain, the request is rejected. This prevents the CA from being used to issue certificates for unauthorized domains.

Rate Limiting

Built-in rate limiting protects against abuse:

• Per-IP: 600 requests per minute
• Per-account: 300 requests per minute

Rate limits apply to all protocol endpoints (ACME, EST, SCEP). Requests that exceed the limit receive HTTP 429 responses.

Admin Dashboard

The web-based admin dashboard is available at /admin and provides:

• Certificate browser: search, filter, and inspect issued certificates
• CA status: view CA hierarchy, validity, and key status
• ACME dashboard: monitor accounts, orders, and challenge status
• Server configuration and protocol status

Access is controlled via Basic Auth with session cookies. The admin password is set during the setup wizard.

FIPS 140-3 Mode

FIPS 140-3 is enabled by default using aws-lc-rs (NIST Certificate #4816) as the cryptographic backend. This covers all key generation, signing, and verification operations. Non-FIPS pure Rust mode is available via runtime toggle for environments that do not require FIPS compliance.

Endpoints

All endpoints are served on the configured port (default 6446) over HTTPS: