Hand-releasing SSL/TLS certificates no longer scales because it starts with a request. They did so by allowing servers to communicate directly with Certificate Authorities, but Let’s Encrypt’s registration is open, whereas enterprise CAs & commercial providers require verification of who they are issuing a certificate to.
This is where External Account Binding comes in. EAB is the default authentication method for enterprise-wide PKI and commercial CAs; it binds an ACME client to a pre-approved CA account with the use of credentials that are issued ahead of time.
Key Takeaways:
- Identifying what ACME EAB is and why it is a necessity for CAs.
- Where EAB is integrated into the ACME registration process vs the normal registration process
- Where EAB is mandatory
- How to get your certs, set up certbot, acme.sh, and Posh-ACME.
- Install the DigiCert and Sectigo setup packages. Install DigiCert and Sectigo setups.
- The common errors, fixes, and security best practices to follow when using EAB.
What is the ACME External Account Binding (EAB)?
External Account Binding is the process of associating a new ACME account with a controlled account on the Certificate Authority’s arm. Rather, the CA verifies that the one asking for the certificate is already a qualified and recognised customer, and only the customer may request it.
Why RFC 8555 Includes EAB?
Precisely because of this, ACME’s specification, RFC 8555, specifies EAB. The builders who designed the protocol were aware of Let’s Encrypt’s intent to use open registration, but this approach wouldn’t be feasible for some commercial CAs or other CAs with strict requirements for compliance.
How the Client-CA Relationship Works?
The ACME client (Certbot, acme.sh, or other client tools) doesn’t simply request a certificate from the CA. First, it proves that it belongs to a certain account that is well-known to and previously approved by the CA, which signs its registration request using a key ID and HMAC key held by the CA beforehand.
If there are no valid EAB credentials, no account creation; that is a no-brainer.
Why It Matters for Enterprise PKI?
It’s hard to imagine a company with hundreds of internal certificates having engineers whipping up anonymous CA accounts as needed. With EAB enforcing all clients to be on an account someone in security/IT approves, you’re forced back to authentication accounts they already trusted.
How Managed Certificate Platforms Use EAB?
For managed platforms, it’s the same reasoning. They issue EAB certificates that are bound to a customer account, resulting in the right certificate plus the right methods of accessing it, even if dozens of servers are trying to renew them simultaneously.
How EAB Works in the ACME Protocol?
The EAB workflow provides an additional layer of authentication for normal ACME account registration, which only occurs when first-time accounts are created.
Step 1: Generate an ACME Account Key Pair:
Your client (in this case, Certbot, acme.sh, and others) generates a public-private key pair. This key is used to identify the ACME account from now on and to sign all future requests.
Step 2: Request EAB Credentials from the CA:
To get to the ACME client, you log in to your CA’s portal (DigiCert, Sectigo, or enterprise PKI provider) and apply for EAB credentials for your organisation’s account. Or you can purchase ACME SSL from Certera that comes with EAB Credentials.
Step 3: Receive the KID and HMAC Key:
The CA returns two values: a Key Identifier (KID) to indicate which approved account you are binding to and an HMAC key (a shared secret known only to the end user and the CA).
Step 4: The Client builds an EAB Object:
Your ACME client then creates a JSON Web Signature (JWS) document using the HMAC key, but it does not send the HMAC key. It is an object that is signed and is attached to an account registration request.
Step 5: The CA Validates the Signature:
It re-computes the HMAC with its shared secret. A campaign confirms you’re actually the rightful account owner.
Step 6: Registration Succeeds:
You now permanently have the ACME account connected to your CA account.
Step 7: Certificate issuance Proceeds Normally:
All certificate requests from here are standard ACME with no need to register a new account anymore unless you want to.
EAB vs Standard ACME Registration Difference
| Feature | Standard ACME | ACME with EAB |
| Account registration | Open | Restricted |
| Identity verification | Minimal | Required |
| EAB credentials | Not required | Required |
| Enterprise support | Limited | Extensive |
| Commercial CA compatibility | Varies | Common |
| Managed PKI | No | Yes |
| Access control | Basic | Strong |
The simple course and Standard ACME are on the same page regarding ease of use. Alternatively, you can create a key pair, connect to the CA endpoint, and retrieve a certificate.
It is the frictionless approach that is the backbone of Let’s Encrypt’s identity growth and makes it ideal for the individual developer, smaller websites, or anyone who simply needs an effective certificate in one snap.
EAB trades in control for speed. Businesses don’t need frictionless; they need accountability. All certificates given must be able to be referenced to an approved account, relationship with a billing party, or compliance record.
It is for this reason that commercial CAs such as DigiCert and Sectigo rely on EAB as a default. They are not selling anonymous certificates; they are selling certificates attached to recognised organisations and with support contracts and audit trails attached.
Managed PKI platforms build on this. By using EAB, they can enforce access control on hundreds of servers and teams and only alert those certificates available for use under the company’s account, but without sharing admin credentials with all of the servers in the fleet.
When is External Account Binding Required?
In some instances, a simple ACME setup doesn’t require EAB. However, in particular settings, it cannot be compromised.
The leading deployments are Enterprise PKI. If a business provides certificates for hundreds of internal services, then EAB will link each request to a validated account rather than relying on the key of anyone with a key.
EAB is also mandated by default for Commercial Certificate Authorities such as DigiCert and Sectigo at their ACME endpoints. There isn’t any anonymous registration with either CA; customers must be onboarded to get their EAB credentials.
Managed ACME services and certificate management platforms in the cloud implement tenant boundaries with EAB. An automatic renewal for each customer remains within the scope of their billing and access.
One of the issues at scale is that for Multi-tenant certificate platforms, dozens of clients are hitting a single ACME endpoint, and they need to be able to prove which account they are in.
Internal corporate PKI teams base it on a CA that doesn’t exist in the market, just to manage which server will use their internal CA to request certificates when it’s used.
For Government environments, it’s a recommended component for compliance and audit purposes – every certificate needs an attributable and verifiable requester.
When EAB is used by the host provider, which runs certificates for client domains, it allows EAB to limit automation to the appropriate management account particularly at higher issuance rates.
ACME EAB Authentication Flow Explained
In Section 2, you learned the big-picture steps. Let’s take a look under the hood, going through that HMAC exchange.
All messages are wrapped within a JSON Web Signature (JWS), a signed JSON message payload, proving that the sender has control of a particular key. The outer JWS is based on your ACME account key.
It contains another JWS as an inner object signed separately by the CA using an HMAC key for the EAB JWS.
That nesting matters. The outermost outer signature will ensure your control of the ACME account key pair. The inner signature is proof that you also have the pre-shared HMAC secret: There are two proofs, one for each request.
Why HMAC specifically: It’s not a symmetric encryption method; it is a symmetric signing method. The client generates a signature using the shared secret for the request payload, but sends the signature (but not the secret itself).
The CA re-calculates the same signature using the key stored in its copy of the key store, and compares. If it does match, the client has shown that it contains the secret but never put it on the wire. A signature is used, not a key that can be re-used.
This is only the real security payoff. The CA does not need to trust whoever presented the valid pair; rather, whoever had an account and used the ACME protocol to register the same is trusted, but only because the CA had previously verified the validity of the relationship.
If validation is successful, the CA makes the account permanent, and regular certificate issuing is followed thereafter.
How to Get EAB Credentials
Don’t write any command to touch Certbot or acme.sh without taking two values from your CA before you do: the Key Identifier and the HMAC key.
The KID is a one-of-a-kind string which is associated with your individual account on the CA’s system (akin to a username for the binding process). The HMAC key is a private string that you share with others to verify you’re allowed to use that account.
Both come together, and you will just paste them into your ACME client’s configuration.
They might be obtained from different places depending on the mode in which your CA works. Most commercial providers, like DigiCert and Sectigo, issue EAB credentials via a web-based management portal.
Upon login, you proceed to the “ACME” or “automation” tab and generate a new key pair that is associated with your account.
More commonly, enterprise PKI platforms offer a reporting centre, which is accessible, but perhaps at the team or project level.
If the deployment is larger, it is entirely avoided. When building dozens of certificates automatically against multiple servers, provisioning via the API comes in handy, as you can programmatically request EAB credentials.
Some organisations do this even more centrally – an administrator would give out manual credentials on a one-by-one basis and continue to have more control over who would have automated issuance rights.
Setting up Certbot with EAB
Certbot has built-in support for EAB. There’s no special plugin for EAB. The things you need to get started are Certbot installed, the ACME server URL for your CA, your KID, and your HMAC key.
certbot register \
--server https://acme.example-ca.com/directory \
--eab-kid YOUR_KEY_IDENTIFIER \
--eab-hmac-key YOUR_HMAC_KEY \
--email [email protected] \
--agree-tosWhat each flag does
- –server points to Certbot’s endpoint of the ACME directory endpoint in your CA’s default directory position. Each CA provides a separate URL at this point, so please verify with your provider’s documentation.
- –eab-kid includes the Key Identifier identifying the CA’s pre-approved account to which you are to bind.
- –eab-hmac-key passes the shared secret Certbot uses to sign the EAB object. The HMAC signing is done entirely by Certbot, so never use raw cryptography!
Verifying Registration
Register and run certbot certificates. If there are no Errors in the Output, the account was bound successfully.
If you see an “invalid EAB” or unauthorised error, it means that the KID or HMAC key is not the same as the one expected by the CA.
Renewal Considerations
EAB only applies during initial registration. After you have set up your account, you will not have to pass the EAB flags again when certbot renew runs.
Common Mistakes
The proportion of mismatched server URL scenarios is greater than that of bad credentials, so mismatched URLs lead to more failures.
The production CA URL and the staging credentials (and the other way round) generate misleading errors, such as HMAC errors. Check your direction of pointing in the first place.
Setting up acme.sh with EAB
EAB is supported by simple command-line flags with acme.sh, without the need for additional plugins. Just ensure that you have the latest version: EAB support was only joined into later versions, so please always ensure that you have the latest among those if you installed acme.sh some time ago.
acme.sh --register-account \
--server https://acme.example-ca.com/directory \
--eab-kid YOUR_KEY_IDENTIFIER \
--eab-hmac-key YOUR_HMAC_KEYUsing the –server flag sets the URL of the CA’s directory;
the –eab-kid flag and
–eab-hmac-key flags pass the credentials your CA issued for this registration, only using it for this CA one time.
Issuing Certificates
After registration, the issuance works as normal acme.sh usage:
acme.sh --issue -d yourdomain.com --serve https://acme.example-ca.com/directoryRepeat flagging for EAB is not done here; it has been done for the account.
Renewal
Unless you want to remove your subscription from acme.sh and register again, no EAB client is involved in the automatic renewal of certificates that acme.sh.js includes in the built-in cron job.
Debugging Registration Failures
To get verbose output of any command, append –debug 2. This displays the raw ACME requests and CA responses, making it easier to identify mismatches in HMAC, along with malformed KIDs.
Common Pitfalls
The most common error: Using a pre-existing “account directory” from a previous CA, but changing CAs without discarding the outdated config can result in silent binding issues.
Specify –server on all commands.
Setting up Posh-ACME with EAB
With Posh-ACME, the Automation Controller for Microsoft (ACME) capabilities and features are brought to PowerShell, making it the most natural choice for Windows Server environments.
PowerShell 5.1 or higher and the Posh-ACME module must have been installed using Install-Module -Name Posh-ACME.
Registering with EAB
Set-PAServer https://acme.example-ca.com/directory
New-PAAccount -Contact [email protected] -EABKeyID YOUR_KID -EABHmacKey YOUR_HMAC_KEY
Set-PAServer is used to set the URL for the directory of your CA. New-PAAccount is used to register; -EABKeyID and -EABHmacKey are the credentials provided by your CA, just as Certbot and acme.sh.
Requesting Certificates
If the binding is successful, the certificate request behaves as in any other Posh-ACME pipeline:
New-PACertificate yourdomain.com -AcceptTOSNo EAB flags needed here; the bound account handles authentication.
Automating Renewals
Administrators normally place Submit-Renewal or the entire renewal script into the Task Scheduler and set up their scripts to execute daily.
If the certificate is scheduled to expire, Posh-ACME will automatically alert and renew it, ensuring that scheduled tasks are lightweight.
Such an environment is the ideal best practice for environments that run IIS, where certificate automation also typically meant exporting and importing certificates in each environment.
Troubleshooting
PowerShell scripts are not signed by default; if the automation script won’t run, check Get-ExecutionPolicy first.
For EAB-specific failures, Get-PAAccount shows your current account status, which quickly reveals whether the binding actually succeeded or silently failed during registration.
DigiCert & Sectigo ACME EAB Setup
DigiCert
EABs are created using DigiCert’s CertCentral solution. Generate an ACME certificate profile, and CertCentral generates the ACME directory URL and EAB credentials, which will feature your key identifier and HMAC key, in a pop-up.
Be sure to copy both of these values at once; they will never show up in the DigiCert EAB’s if you close the window.
Based on your account type, DigiCert supports a variety of ACME endpoints such as a hosted DigiCert ONE account utilising a directory URL: one.digicert.com/mpki/api/v1/acme/v2/directory.
Enterprise automation also shares the same EAB credentials for all the servers that request that credential type, allowing for large deployments without regenerating keys for each server.
Sectigo
For all ACME registrations, Sectigo’s Certificate Manager (SCM) needs to bind to the External Account.
The Accounts section of Enrollment → ACME is where you create one of these accounts by clicking Add and filling in the required information.
EAB credentials will be automatically generated.
The Key ID and HMAC key will be found on the account details page, under External Account Binding, and the ACME directory URL will be acme.sectigo.com/v2/DV.
The typical Sectigo enrollment for Certbot looks like:
certbot certonly --standalone --agree-tos \
--server https://acme.sectigo.com/v2/OV \
--eab-kid YOUR_KEY_ID \
--eab-hmac-key YOUR_HMAC_KEY \
--domain yourdomain.comComparison
| Feature | DigiCert | Sectigo |
| Enterprise PKI | Yes | Yes |
| Managed ACME | Yes (CertCentral) | Yes (SCM) |
| EAB support | Required for 3rd-party clients | Required for all ACME accounts |
| Automation | Certbot, win-acme, cert-manager | Certbot, win-acme, custom connectors |
| API integration | REST API for credential generation | REST API via SCM |
Common ACME EAB Errors and Troubleshooting
Even a correctly configured client hits EAB errors occasionally. Here’s what each one actually means.
| Error | Possible cause | Solution |
| Invalid HMAC | Incorrect key | Verify the HMAC key matches exactly, with no trailing spaces or line breaks |
| Unknown KID | Wrong account | Confirm the KID matches the account you intended to bind |
| Unauthorized | Invalid credentials | Regenerate EAB credentials through your CA’s portal |
| Bad signature | Clock mismatch or signing issue | Check system time sync and client configuration |
| Registration failed | Wrong ACME directory | Verify you’re pointing at the correct endpoint URL |
| Permission denied | Account restrictions | Contact your CA administrator |
The two errors, Invalid HMAC and bad signature, have the same outward manifestations but have different causes. Typically, HMAC errors occur due to copy-and-paste issues.
The real issue is that most signature errors relate to the time malleability of JWS signing: with an incorrect signature, an ACME server clock that is within a few minutes of being off is enough for the signature to be rejected even if the credentials are correct.
Debug logs matter more than guessing:
Run Certbot with –debug, acme.sh with –debug 2, or Posh-ACME with verbose logging enabled. These show the raw request and CA response, which usually points straight at the actual problem.
Network and firewall issues masquerade as EAB failures too:
If your server cannot even connect to the ACME directory URL, it will report a connection timeout – never assume that there is some sort of authentication issue unless you have at least checked network connectivity first.
API Rate Limits on the CA side can also block registration attempts during testing. Spacing out retries usually resolves this without needing new credentials.
Best Practices for ACME EAB Security
Your HMAC key is equivalent to a password; use it as such. People who obtain it are able to register an account using your organisation’s identity.
Change EAB credentials frequently, particularly when employees change jobs, or when you suspect there may be exposure to EAB. Most CAs will allow you to generate new certificates without impacting any existing certificates that are issued through the old binding.
Use the principle of ‘least privilege’ when creating credentials. With one certificate or one team, the range of dissemination is restrictable if anything leaks.
Do not store HMAC keys directly in your scripts or even version-controlled config files! That’s the most common method for credential loss, typically by committing them to a public GitHub repository by accident.
Don’t store secrets in a plaintext file on the server – use a dedicated secrets manager or HSM for enterprise deployments. Both HashiCorp Vault and AWS Secrets Manager can be integrated seamlessly into ACME automation pipelines.
Where your CA will allow it, use audit logging and look at account registration periodically. If an EAB credential is issued from an unknown IP or server, it is an indication of compromise rather than any other alerts.
If enabled by your CA, limit access by credential set to specific ACME endpoints and profiles.
Conclusion
Before you can enable certificate issuing automation with a CA, you need to prove who you are to it, which is a real problem solved by External Account Binding.
However, enterprise PKI providers and commercial CAs such as DigiCert and Sectigo have made it the standard, as they cannot follow the open registration business model as Let’s Encrypt does.
Once you’ve got the right registration step, store your HMAC key as any other production secret, and EAB becomes a setup cost—the remainder of certificate automation proceeds exactly as in a normal ACME.
Frequently Asked Questions
What is the ACME “External Account Binding (EAB)”?
EAB is an identity assurance system that connects a new ACME account with a pre-existing user-approved account at the Certificate Authority and verifies the identity of a requester prior to issuing certificates automatically.
Why is the Certificate Authority requesting EAB?
For enterprise and managed PKI environments, where anonymous account creation is unacceptable, EAB enables CAs to properly verify customer identity before they are allowed to begin automation.
What is suggested by information regarding EAB credentials?
These include a Key Identifier (KID) that refers to your particular CA account, as well as an HMAC key, which is a shared secret that you use to sign the registration request.
Is it mandatory to use EAB with Let’s Encrypt?
No, not for the common signing of certificates. It’s the default, but some managed ACME integrations using Let’s Encrypt may use it.
Yes, you can use EAB with Certbot.
Yes. Certbot adds the following native support for EAB: it allows configuring EAB during the registration process using the –eab-kid and –eab-hmac-key flags.
Which ACME clients support EAB?
There is support for it by Certbot, Posh-ACME and nearly all other RFC 8555-compliant clients.
Does EAB have to be applied for for all certificate requests?
EAB will only be used when you register your account for the first time. All certificate requests, as well as subsequent renewals, are done with the standard ACME account key.
Where should I have my EAB credentials secured?
Always keep the KID and HMAC key in a Secrets Manager, and access and rotate them frequently; don’t hardcode them in scripts or into version control.
