External Account Binding (EAB)

External Account Binding is defined in section 7.3.4 of RFC 8555. The CA gives you a key identifier (kid) and a MAC key through its website or API. When the ACME client creates its account, it includes an extra JWS that signs the new account's public key with that MAC key, proving the registration was authorized by a known customer. After registration, the ACME account works normally; EAB is not needed for each order.

Why it matters

Let's Encrypt does not require EAB, but many other ACME CAs do, because they need to tie certificates to a billing account, a pre-validated organization or abuse controls. ZeroSSL, Google Trust Services and SSL.com, for example, require EAB credentials before an ACME account can be created. EAB is also how OV certificates can be automated: the organization is validated once in the CA's portal, and ACME then handles domain validation and renewals.

Example

# Certbot with a CA that requires EAB
certbot register --server https://acme.example.com/directory \
  --eab-kid "<KID>" --eab-hmac-key "<HMAC_KEY>" -m admin@example.com

# acme.sh
acme.sh --register-account --server https://acme.example.com/directory \
  --eab-kid "<KID>" --eab-hmac-key "<HMAC_KEY>"

Replace the placeholders with the values from your CA's console and keep them out of shell history and version control.

Common misconceptions

• The EAB key replaces the ACME account key. It is used once to bind the account; the account key still signs every later request.
• EAB credentials are harmless to share. Anyone holding them may be able to register ACME accounts tied to your CA account, so treat them as secrets.
• EAB replaces domain validation. Each domain still needs DCV unless the CA has already validated it for your account.