Skip to content

Managing ACME Accounts

This guide covers creating, configuring, and managing ACME accounts, including domain bindings and External Account Binding (EAB) credentials.


What is an ACME Account?

An ACME account is the identity that an ACME client uses to authenticate with the platform and request certificates. Each account:

  • Is bound to a specific ACME server configuration
  • Has a unique public/private key pair (generated by the client)
  • Has configured domain bindings that control which certificates it can request
  • May require External Account Binding (EAB) for registration

Unlike traditional ACME servers where accounts are self-service, Zaita requires administrators to pre-provision accounts before clients can register.


Creating an Account

  1. Navigate to AdminACME Servers and select your server configuration.
  2. Select the Accounts tab, then Add Account.
  3. Enter a descriptive Name (e.g., web-prod-01, api-gateway-staging).
  4. Configure Domain Bindings (see below).
  5. Save the account.

The account is created in a pending state. It becomes active when an ACME client registers using its EAB credentials, at which point the client's public key is stored.


Domain Bindings

Domain bindings control which domains an account can request certificates for. This replaces the traditional ACME challenge-response flow — no HTTP-01, DNS-01, or TLS-ALPN-01 challenges are required.

Binding Types

Option Description Example
Exact domain Certificates for this exact domain only example.com allows only example.com
Allow subdomains Certificates for any subdomain example.com with subdomains allows app.example.com, api.example.com
Allow wildcard Wildcard certificates example.com with wildcard allows *.example.com

Adding a Binding

  1. From the account view, select Add Domain Binding.
  2. Select a domain from your registered domains.
  3. Choose the binding options:
  4. Allow Subdomains — Enable to permit certificates for any subdomain
  5. Allow Wildcard — Enable to permit wildcard certificates
  6. Save the binding.

Combining Options

You can enable both subdomain and wildcard options on a single binding:

Configuration Permitted Certificates
example.com (exact only) example.com
example.com + subdomains example.com, app.example.com, api.sub.example.com
example.com + wildcard example.com, *.example.com
example.com + subdomains + wildcard example.com, *.example.com, app.example.com, *.sub.example.com

Multiple Bindings

An account can have bindings for multiple domains. A certificate request can include any combination of domains for which the account has appropriate bindings.

For example, an account with bindings for both example.com and example.org (with subdomains enabled) can request a single certificate covering: - app.example.com - api.example.org


External Account Binding (EAB)

EAB ties the ACME client's registration to a pre-provisioned account in the platform. This ensures only authorised clients can register.

How EAB Works

  1. An administrator creates an account and generates EAB credentials
  2. The credentials are securely provided to the ACME client operator
  3. The client includes the credentials when calling /new-account
  4. The platform verifies the HMAC signature and activates the account
  5. The EAB credentials are marked as used and cannot be reused

Generating Credentials

  1. From the account view, select Generate EAB Credentials.
  2. Copy both values immediately:
  3. Key ID (kid) — A unique identifier (32 hexadecimal characters)
  4. HMAC Key — A shared secret (64 hexadecimal characters, base64url-encoded for transmission)

Warning: The HMAC key is displayed only once. Store it securely and transmit it to the client operator through a secure channel. If lost, you must regenerate credentials.

Regenerating Credentials

If credentials are lost or potentially compromised before use:

  1. From the account view, select Regenerate EAB Credentials.
  2. The previous credentials are invalidated.
  3. New credentials are generated.

Note: You cannot regenerate credentials for an account that has already been activated. The account's public key is locked once registration completes.

EAB vs Non-EAB

Mode Registration Flow Use Case
EAB required (recommended) Client must provide valid EAB credentials Production environments
EAB optional Client can register without EAB Development/testing only

When EAB is required at the server level, all accounts on that server require EAB credentials before they can complete registration.


Account Status

Status Description
Pending Account created but not yet registered by a client
Valid Account active and can request certificates
Deactivated Account disabled by administrator or client
Revoked Account revoked; cannot request certificates

Deactivating an Account

To prevent an account from requesting new certificates:

  1. From the account view, select Deactivate.
  2. Confirm the action.

Deactivation: - Immediately prevents new orders - Does not revoke existing certificates - Is reversible (the account can be reactivated)

Reactivating an Account

Select Reactivate from a deactivated account's view page.


Viewing Account Activity

Orders

The Orders tab shows all certificate orders placed by this account:

  • Status — pending, ready, processing, valid, invalid
  • Domains — Requested identifiers
  • Created — Order timestamp
  • Certificate — Link to issued certificate (if valid)

Certificates

The Certificates tab shows all certificates issued to this account:

  • Serial Number
  • Common Name
  • SANs — Subject Alternative Names
  • Valid From / To
  • Status — Valid, Expired, Revoked

Account Key Rotation

The ACME protocol supports key rotation via the /key-change endpoint, allowing clients to update their account key pair without creating a new account.

Note: Key rotation is not currently implemented. Clients requiring a new key pair must create a new account.


Deleting an Account

  1. Deactivate the account first.
  2. From the account view, select Delete.
  3. Confirm the action.

Deleting an account: - Removes the account record - Does not revoke certificates issued to the account - Frees the EAB credentials (if unused)


Best Practices for Account Management

One Account Per System

Create a dedicated account for each system or application that needs certificates. This provides:

  • Auditability — Clear tracking of which system requested which certificates
  • Least privilege — Each account has only the domain bindings it needs
  • Isolation — Compromising one account does not affect others

Minimal Domain Bindings

Grant only the domain bindings each account actually needs:

  • Avoid broad "allow all subdomains" bindings unless required
  • Avoid wildcard permissions unless the system genuinely needs wildcard certificates
  • Review bindings periodically and remove unused permissions

Secure Credential Distribution

When distributing EAB credentials:

  • Use a secure channel (encrypted email, secrets manager, secure file transfer)
  • Never commit credentials to source control
  • Delete credentials from local storage after configuration

Next Steps