What is ACME External Account Binding?

What Are ACME EAB Credentials?

ACME EAB credentials are two cryptographic values issued by the Certificate Authority that, when used together, will bind an ACME client to a specific account.

An EAB credential consists of:

• A Key ID (KID), which is a unique identifier that is provided by the CA and is composed of ASCII characters.
• An HMAC key (the secret key used to create a signature for an ACME account request) that is base64url encoded and is used to create a signature for an ACME account registration event.

Once an ACME client makes an initial registration request to the CA, it supplies the KID and uses the HMAC key to sign its initial registration request. The CA validates the signature provided by the client and, if valid, establishes an EAB account that is permanently associated with that specific EAB credential.

Important Considerations related to EAB Credentials:

• They are only displayed once at the time of creation.
• An EAB credential can be bound to more than one ACME account.
• If an EAB credential is lost or compromised, a new one must be generated.
• They are unique to a specific ACME provisioner/account combination.

What are the Key EAB Components?

To learn more about what EAB is about, we will begin with EAB’s fundamental elements:

ACME Client

ACME clients are the applications that automate the life-cycle of certificates, including registering an account, validating a domain, acquiring a certificate, installing a certificate, and renewing a certificate.

Some examples of ACME clients are Certbot, acme.sh, cert-manager (a Kubernetes ACME client), and Posh-ACME. All of these clients communicate directly with the Certificate Authority’s (CA’s) ACME endpoint.

When EAB support is required, the client must be configured with the supplied Key ID (KID) and HMAC (message-digest) key at the time of account creation.

The client will securely store the ACME account key once it has been registered with EAB, and the client will use the same account key to request or renew future certificates without the need for further EAB credentials.

ACME Server (CA Endpoint)

The CA endpoint, commonly referred to as the ACME server, functions as the API interface of the Certificate Authority (CA) for processing ACME requests.

The ACME server processes requests for new certificate account registrations, accepts requests to validate domain validation challenges such as HTTP-01 and DNS-01, and issues and renews certificates.

In situations where EAB has been put in place, the ACME server also performs an additional verification step to validate the Key ID entry during this new account registration process and verify that the HMAC signature generated by the client is correct to determine if this ACME request was created by an authorized account member.

When this verification fails, the CA will reject the new account registration, thereby protecting against the issuance of certificates to unverified users.

EAB Policy Requirement

When the Certificate Authority (CA) declares that a comprehensive policy defines the account Security Required (EAB) requirement for the new. The New ACME Account Registration (NACAR), any ACME client attempting to create an external account through that CA must present valid EAB credentials issued by the CA.

The EAB requirement provides a strong layer of access control to protect the issuance of automated certificates issued via a specific ACME provisioner or endpoint, making the use of EAB a critical requirement for commercial, enterprise, or private CA deployments.

The EAB requirement ensures that all automated certificate issuance is performed by an organisation, system, or customer that has been validated and approved by the CA.

Key ID (KID)

The key ID (KID) is a unique identifier generated by the CA, which is assigned to the specific external account/provisioner to identify it as the reference point by which the CA will establish whether the ACME client is binding to the correct external account, External Account Certificate (EAC).

Although the KID is not treated as confidential, it must match an existing record with the CA. When the CA receives an ACME account registration request and establishes that the provided KID and HMAC key are used to validate the binding of the ACME account registration request.

They are in the CA’s database, which will complete the account registration and provide the ACME client with Automated Issuance of Certificate Enabled (AICE).

HMAC Key

The Certificate Authority will provide a base64url-encoded HMAC Key alongside its Key ID, which an ACME client will use to generate a cryptographic signature when creating a new ACME account.

A cryptographic signature will prove that an ACME client has the correct shared secret associated with the specified KID (Key ID). The HMAC key is confidential and sensitive; therefore, the server should adequately protect it from being exposed to an unauthorized individual.

Once the ACME account has been successfully created and bound to the ACME client, the EAB credential typically will be marked as used and cannot be reused (this adds a layer of security to the certificate issuance process).

Current ACME and EAB Support on Web Servers

As the industry has rapidly evolved over the last several years, the ability to issue and renew certificates using the ACME protocol has become much easier for web server operators.

However, EAB capability varies widely between platforms based on whether a native ACME client is provided or if an external client is used.

Below is a high-level overview based on the state of current support trends:

Webserver / Platform	Native ACME Client	EAB Support	Type of Implementation	Note / Internal Client
Apache HTTP Server	No	Yes (via external client)	External (Certbot, acme.sh, lego…)	Plugin e.g.certbot-apache; client handles EAB (works with DigiCert’s ACME).
NGINX (until 1.24)	No	Yes (via external client)	External (Certbot, acme.sh…)	Older NGINX versions do not support ACME natively.
NGINX (from 1.25)	Yes	No	Native	Built-in ACME client does not provide support for EAB; an external client must be used for DigiCert’s ACME.
LiteSpeed Web Server / OpenLiteSpeed	Yes	Yes	Native (acme.sh internally)	acme.sh integrated client for ACME; full EAB support (DigiCert ACME).
Caddy	Yes	Yes	Native	Automated certificate issuance EAB support.
Traefik	Yes	Yes	Native	EAB supported by ACME management on the reseller.
HAProxy	Partially (via hooks)	Yes (via external client)	External client (acme.sh, Certbot…)	ACME client issues certificate and uses hooks to reload service.
Lighttpd	No	Yes (via external client)	External client	acme.sh or dehydrated; client handles EAB.
Microsoft IIS / Microsoft Exchange (Windows)	Yes	Yes	External (win-acme, Certify The Web)	Certificate management is 100% automated EAB supported (DigiCert ACME).
Apache Tomcat / Eclipse Jetty / Java servers	No	Yes (via external client)	External client + hooks	Certificate must be converted to JKS/PKCS12 format; client manages EAB.
Postfix / Dovecot / Exim	No	Yes (via external client)	External client + hooks	Certificate deployment via scripts; EAB managed by client.
cert-manager (Kubernetes)	Yes	Yes	Controller / Issuer	Full support for EAB – appropriate for assigning certificates that are issued by DigiCert ACME.
Envoy Proxy	Experimental	Partially (via external managers)	Integration via SDS / cert-manager	An external controller manages the provision of certificates using ACME, client manages EAB.
Cloudflare / Amazon Web Services / Google Cloud Platform	Yes (own management)	Internal (outside standard EAB)	Cloud-managed	DigiCert’s ACME uses an external ACME client, outside of native cloud-based certificate systems.

ACME EAB Configuration Commands and Examples

Below are practical examples of configuring ACME clients with EAB credentials:

Certbot (Command Line)

Certbot supports EAB using additional parameters during account registration:

certbot register \
 --server https://acme.example-ca.com/directory \
 --eab-kid YOUR_KEY_ID \
 --eab-hmac-key YOUR_BASE64_HMAC_KEY \
 --agree-tos \
 -m [email protected]

After registration, Certbot stores the ACME account key and uses it for future renewals.

acme.sh

With acme.sh, EAB credentials are passed during registration:

acme.sh --register-account \
 --server https://acme.example-ca.com/directory \
 --eab-kid YOUR_KEY_ID \
 --eab-hmac-key YOUR_BASE64_HMAC_KEY

Once registered, you can issue certificates normally.

Posh-ACME (PowerShell)

For Windows environments using Posh-ACME:

New-PAAccount -AcceptTOS `
 -Contact [email protected] `
 -Server https://acme.example-ca.com/directory `
 -EabKeyId "YOUR_KEY_ID" `
 -EabHmacKey "YOUR_BASE64_HMAC_KEY"

This is commonly used in IIS and enterprise Windows deployments.

cert-manager (Kubernetes)

In Kubernetes, EAB credentials are configured in the Issuer or ClusterIssuer resource:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer

metadata:

name: digicert-issuer
Spec:
 Acme:
   server: https://acme.example-ca.com/directory
   email: [email protected]
   privateKeySecretRef:
     name: acme-account-key
   externalAccountBinding:
     keyID: YOUR_KEY_ID
     keySecretRef:
       name: eab-secret
       key: hmac-key

Kubernetes Secrets are where HMAC keys are held securely.

Conclusion

This is all about ACME EAB. By using CheapSSLWEB, you avoid leaving your infrastructure vulnerable and wasting money on enterprise-grade security. We offer you the opportunity to obtain an SSL certificate, receive free expert assistance, and get the best pricing on the market. Protect your automation by visiting CheapSSLWEB today!

Search