ACME External Account Binding, or EAB, lets a certificate authority connect a newly registered automated certificate-management account to a customer or other account already known outside ACME. The client receives a key identifier and a secret MAC key through an independent enrolment channel, then places a MAC-protected proof inside its signed ACME newAccount request. The server checks that the proof identifies the same public account key used to sign the request.
The essential security boundary is narrower than a certificate issuance decision. EAB can establish that an authorised holder of an externally provisioned MAC secret approved binding a particular ACME account key to a particular CA account. It does not by itself prove control of a domain, authorise every future certificate order, attest to any AI agent’s intelligence, or replace HTTPS transport, identifier validation and certificate policy. A contemporary software agent can automate these operations, but this is not evidence that artificial superintelligence exists.
This article follows RFC 8555 Section 7.3.4, derives the two different JWS envelopes, works a three-tenant onboarding case with explicit counts and error denominators, and shows failure diagnosis, secret custody, account rollover and a changed-context transfer exercise. All operational numbers are constructed examples; no claims are made about production systems or a certification authority’s measured error rates.
Contents and learning pathways
Learn the exact protocol: external identity and ACME account · outer JWS · nested EAB JWS · five verification duties · solved transfer exercise.
Why ACME registration can involve two identities · The protocol job is account onboarding, not a full certificate lifecycle · Identify the parties and the secrets before implementation · Read the directory metadata before attempting account creation · The outer ACME request is signed with the account private key · The inner EAB JWS proves approval from an external account · Understand JWS protected-header bytes and base64url boundaries · The CA has five independent EAB verification duties
A complete three-message example without fictional live evidence · A valid EAB MAC can still be attached to the wrong account key · The URL field binds the proof to a specific newAccount endpoint · The outer nonce and inner no-nonce rule are deliberately different · Protect the MAC key as a registration capability · Hand-checked capacity planning for three fictional tenants · Identity binding does not define every privilege of a tenant · Existing ACME accounts are not automatically new registrations
Account-key rollover has its own signed exchange · The out-of-band channel deserves its own threat model · A server response must be interpreted in context · Construct independent positive and negative protocol tests · Client support cannot be inferred from basic ACME support · Diagnose registration failures in the right order · A constructed weekly operations example separates counts from claims · Changed-context transfer: a different CA and shared account · What EAB cannot establish and what evidence is still required
Frequently asked questions · Primary documents · Relevant eduKate reading.
Why ACME registration can involve two identities
An automated certificate client normally creates an ACME account controlled by a public-private key pair. The public account key is the durable cryptographic identifier for requests. A certificate authority may also have a billing, enterprise tenancy, eligibility or organisational customer record that predates the ACME account. Without an explicit binding procedure, the server may have no proof that the requester who generated the new ACME key is entitled to act for that external record.
EAB supplies one way of making that association during account creation. The CA or its authorised enrolment service gives the customer a key identifier and MAC key outside the ACME protocol. A request signed with the new ACME private key also contains an EAB object proving possession of the externally issued MAC key and naming the new ACME public key. The server then knows which external record and ACME key have been connected under its binding rules.
The two identities should never be casually merged. The ACME account is used to authenticate later ACME protocol messages, while the external record can govern pricing, organisation, compliance or permitted enrolment. Certificate identifiers such as example.org have yet another validation process. Treating one successful account binding as permission to issue any certificate confuses three separate questions: who registered, whose external account is referenced, and which domain identifiers may be certified.
Consider an organisation with three automated deployment services. It might choose one ACME account shared through tightly controlled orchestration or separate accounts per service. EAB does not prescribe that architectural choice. The decision affects account-key custody and incident scope, while the external account mapping affects the CA’s interpretation of each newly registered key. The correct design needs a written ownership model rather than a universal claim that one client equals one customer.
The protocol job is account onboarding, not a full certificate lifecycle
ACME covers a sequence of activities: discovering server endpoints, creating an account, placing an order, proving control or authority for requested identifiers, finalising an order and retrieving a certificate. Renewals and key rollover can appear later. EAB belongs to the new-account part of that sequence and modifies the request payload used during account registration.
A successful EAB check need not produce an issued certificate, and a certificate challenge cannot substitute for a required EAB field. A customer can correctly control a domain yet fail to register because the provided external key identifier is unknown. Conversely, an account can pass EAB while a later domain-control challenge fails. A trustworthy automation system reports these as separate stages with separate status and remediation.
The resulting account object may contain the verified externalAccountBinding field. Under RFC 8555, a server that does not verify a supplied binding must not reflect that field in the resulting account. If the server verifies it and creates the account, the returned object must contain the same binding value. The presence or absence of the reflected field has defined protocol significance, although operators still need to interpret it alongside the server’s own policy and recorded account state.
For agent builders, the actionable lesson is to draw a boundary around initial authorisation. The onboarding step should finish with a known ACME account URL and protected account key; a later order is a new operation subject to its own permissions and policy. Never describe EAB as an all-purpose authorisation token. Its exact reader problem is cryptographically connecting an external registration record with an ACME public key.
Identify the parties and the secrets before implementation
A typical flow has a CA-operated ACME server, an external enrolment service or customer account system, an ACME client and the operator responsible for the client’s keys. The external enrolment service distributes a key identifier, commonly called a kid, and a symmetric MAC secret. The ACME client separately holds a newly generated account signing key pair. The CA holds corresponding information needed to verify the MAC and identify the external record.
The key identifier is not the secret. It labels the externally provisioned MAC key and helps the CA retrieve the correct verification material. The secret MAC key must be protected against disclosure, because possession may permit someone to construct valid EAB proofs under the CA’s issuance and reuse policies. The ACME private account signing key is a different secret with a different role and recovery plan.
RFC 8555 requires the EAB key identifier to be ASCII. The standard recommends distributing the MAC key in base64url form for compatibility, which is an encoding choice, not encryption. Whoever sees the encoded key may be able to decode it back to the original secret bytes. A deployment should therefore put this value into a suitable secret-delivery system, not into a document or public issue tracker.
Draw a custody diagram before giving an agent credentials. One role can authorise external enrolment, another can run certificate management, and another can approve production deployment. If a single unattended worker is given every credential and permission, a compromise might cross all three boundaries. EAB helps with one cryptographic registration boundary; it does not design the complete organisational segregation of duties.
Read the directory metadata before attempting account creation
An ACME client begins by discovering the CA’s directory object. RFC 8555 defines entries for resources such as newNonce and newAccount, alongside optional metadata. One metadata member, externalAccountRequired, tells a client whether that CA requires new account requests to include an externalAccountBinding value. The field is a boolean when present.
If a CA requires EAB, the specification says it must advertise externalAccountRequired as true in its directory metadata. If the client then submits newAccount without a binding, the CA should return the externalAccountRequired problem type. A missing or false requirement flag does not justify assuming that every CA has the same onboarding policies, because directories and provider practices can differ.
An agent should use the newAccount URL supplied by the directory rather than assemble an assumed endpoint from a hostname. The actual protected JWS url value must identify the request endpoint exactly as required by the ACME message integrity rules. A worker pointed at a staging directory cannot safely reuse production expectations just because the two endpoints share a software implementation or visual naming pattern.
For a reproducible diagnostic, capture only non-secret information: the directory URL, returned newAccount endpoint, the public EAB requirement flag, client version and current workflow state. Do not log MAC key material or the client’s private key. Directory discovery is an observable first stage that can distinguish an unsupported client from a missing provisioned secret before any account creation is attempted.
The outer ACME request is signed with the account private key
ACME POST requests use JSON Web Signature objects. A newAccount request’s outer protected header contains an algorithm identifier, the client’s public account key in the jwk parameter, a server-provided replay nonce and the target request URL. The client signs this outer message with the matching private key. The signature authenticates possession of that private key and protects the request payload, which includes any nested externalAccountBinding object.
For newAccount, RFC 8555 requires the outer JWS to identify its key through the jwk header rather than a previously assigned account URL. It also requires a nonce in the outer protected header and rejects a protected header using the none or MAC family as its signing algorithm. The client is not yet an existing ACME account and therefore cannot refer to an account URL in the same way as later signed requests.
This outer signature answers a precise question: does the party creating the account control the private key corresponding to the registered public key? It does not answer whether that party belongs to a pre-existing CA customer record. The latter claim is supplied by the separate EAB construction. Keeping these evidentiary roles separate prevents a verifier from accepting an otherwise well-signed account registration for an unauthorised external record.
The outer JWS can use an asymmetric signing algorithm such as ES256, subject to the server’s supported algorithms and protocol rules. In contrast, the inner EAB JWS uses a MAC-based algorithm. Mixing up these two layers can yield either a protocol-invalid outer request or an EAB proof the CA cannot verify. A correct debugging trace labels them outer account signature and inner external-binding MAC.
The inner EAB JWS proves approval from an external account
The externalAccountBinding field contains a JWS object nested within the JSON payload of the signed newAccount request. Unlike the outer message, this JWS is MAC-protected using the secret provisioned outside ACME. Its protected header includes an algorithm from a MAC-based family, the external key identifier in kid, and the same newAccount URL as the outer JWS. It must not include a nonce.
The inner payload is the ACME account public key in JWK form. That choice is critical: the MAC does not simply cover an external customer ID, the order’s domain name or a list of email addresses. It binds the externally authorised MAC holder to the particular public key being registered as an ACME account. The server separately confirms that this inner JWK represents the very same key authenticated by the outer signature.
The nested proof is not a bearer token to be copied into later certificate orders. Its purpose is the account registration binding. Implementations should follow the exact JWS encoding and verification rules rather than string-concatenate visible JSON and call the result a MAC. The protected header and payload are base64url-encoded parts of the defined JWS signing input.
The two envelopes let the CA learn two things without surrendering either secret. The public-key signature shows control of the ACME account key; the MAC shows possession of the externally provisioned secret. Combining the proofs is useful only when the server checks their identity link and the external record’s policy. Without the equality check, a valid MAC for one key might be misleadingly associated with another.
Understand JWS protected-header bytes and base64url boundaries
A JWS is not merely a JSON dictionary with a signature field appended. In its normal protected representation, the integrity input consists of the base64url-encoded protected header, a period separator, and the base64url-encoded payload. The signature or MAC is computed over those encoded components as specified by JOSE. Altering protected bytes after computing the MAC invalidates that integrity check.
Suppose an implementation constructs an inner protected header containing alg HS256, kid tenant-17 and url https://ca.example/acme/new-account. It then base64url-encodes the protected JSON and the public JWK payload and computes the HMAC-SHA-256 value using the CA-provisioned secret bytes. This is a conceptual example, not a deployable credential. The exact signature value depends on the canonical bytes chosen by the client and cannot be inferred from a text illustration.
JSON property order and whitespace can change the bytes being encoded, even where two decoded JSON objects look semantically similar. A verifier must use the received protected serialization for the JWS cryptographic check, not silently re-create an alternative representation and assume the MAC will match. Separately, comparing the public JWK identity with the outer key must follow the protocol’s representation and key-equivalence rules.
Base64url is not ordinary base64 with a name change. Its alphabet and common unpadded encoding conventions matter for interoperability. Treat the key identifier, encoded MAC key and encoded JWS fields as three distinct data types. An enrolment secret that has been accidentally interpreted as literal UTF-8 base64url text rather than decoded secret bytes will produce a different HMAC and fail verification.
The CA has five independent EAB verification duties
RFC 8555 describes a five-step EAB verification procedure. First, the binding value must be a well-formed JWS. Second, its protected header must meet the defined MAC algorithm, kid, no-nonce and same-URL requirements. Third, the server retrieves the correct MAC key using that kid. Fourth, it verifies the MAC under that key. Fifth, it verifies that the inner payload denotes the same public account key used by the outer JWS.
Each duty prevents a different confusion. Well-formed structure protects parsing; header checks protect algorithm and endpoint interpretation; secret lookup identifies the external record; MAC verification proves possession of the provisioned secret; and the key-equality test prevents binding proof for one key being transferred to a different new account. A single green check on the existence of an externalAccountBinding field is not enough.
The RFC also gives explicit outcomes: when the CA elects to verify a supplied binding and one of these verification checks fails, it must reject the newAccount request. If it successfully verifies and creates the account, the returned account object includes the binding. If it does not verify the binding, it must not reflect the field. An implementation should not claim a successful binding merely because a request with an ignored field produced an account.
A robust server records the reason for failure internally without exposing more secret-dependent information than appropriate to the client. The operator can distinguish a malformed request, unknown identifier, failed MAC or JWK mismatch through trusted traces. Public error details should not become an oracle for probing external tenants. This logging and disclosure design is an operational consideration layered over the protocol’s minimum verification procedure.
A complete three-message example without fictional live evidence
Construct a training scenario with a fictional CA at ca.example and a customer record called Campus-Labs. The CA’s provisioning channel supplies an ASCII key identifier campus-labs-2026 and an independent high-entropy MAC secret. The client’s agent generates a new asymmetric account key pair. It knows the ACME directory’s exact newAccount URL and obtains the server nonce needed for the outer ACME request.
First, the client builds the inner EAB JWS. Its protected header contains an approved MAC algorithm, the campus-labs-2026 kid and the discovered newAccount URL, but no nonce. The payload is the public JWK of the newly generated account key. The client computes the MAC with the provisioned secret. Nothing in this step requests a certificate for a domain.
Second, the client builds the outer ACME newAccount JWS. Its protected header has the account JWK, an accepted asymmetric algorithm, the supplied replay nonce and the same exact URL. Its payload contains ordinary account-registration fields such as contact information and, as one member, the inner externalAccountBinding JWS. The client signs this outer request using the new ACME account private key.
Third, the CA authenticates the outer request, checks EAB as required, creates the ACME account if all registration policies pass, and returns the account representation. The client stores the returned account URL with its protected private key. Only after this point does it begin a distinct certificate order and domain-control validation process. This is an explanatory sequence, not a record of a completed real transaction.
A valid EAB MAC can still be attached to the wrong account key
Take two newly generated public keys A and B. A client mistakenly computes a valid EAB JWS whose payload contains A, but its outer newAccount JWS is signed by B and identifies B in the outer jwk field. The external secret and kid are correct, and the inner MAC could verify perfectly. Yet the registration is not validly bound because the two public keys differ.
This is the case the fifth verification check is designed to catch. Accepting the request would let an authentic proof for A be misassociated with an account controlled through B. It would undermine the binding’s meaning even without a broken HMAC implementation. Server tests should therefore include mismatched JWK pairs whose other signature and header checks are individually valid.
On the client side, the earliest repair is to derive the nested JWK and the outer signature from the same intended account-key object. Do not serialize a cached JWK for one account while generating a new key pair for another tenant. Deterministic small tests can compare public-key parameters after decoding both envelopes, without exporting either private signing keys or HMAC secrets to logs.
An account-key mismatch should not trigger blind generation of a new account and another registration attempt. First discover which key was actually used, which external customer record is intended and whether a partial registration was created. Retry logic can otherwise create orphan accounts, weaken auditability or exhaust rate limits, even when the original error was an ordinary object-selection bug.
The URL field binds the proof to a specific newAccount endpoint
Both JWS layers contain a protected url value identifying the newAccount resource, and RFC 8555 requires the inner EAB protected url to equal the outer one. This constraint prevents a developer from treating a MAC created for an unrelated request endpoint as a generic transferable authorisation. It also makes staging-versus-production configuration a security-relevant distinction.
Imagine that a sandbox CA and a production CA use different newAccount URLs. A copied EAB proof whose protected header names the sandbox endpoint does not meet the same-URL requirement of a production request. The correct repair is to construct a fresh proof using the intended CA’s exact endpoint and its properly provisioned secret, not to replace one visible URL string inside an already authenticated JWS.
Endpoint equality must be tested at the protected-header level. It is not enough that both requests happen to use the same hostname after an HTTP redirect or that an operator regards two aliases as logically equivalent. ACME’s request URL integrity rules require a precise binding between signed message and request destination. A client should prefer the directory-provided endpoint and avoid guessing canonical forms.
The URL protection does not turn the EAB MAC into a TLS certificate verifier. HTTPS authentication of the server and normal ACME transport protections remain necessary. A malicious or misconfigured endpoint may cause other failures that EAB alone cannot repair. Treat endpoint binding as one line in a layered security argument, not the whole argument.
The outer nonce and inner no-nonce rule are deliberately different
The outer ACME JWS contains a replay nonce issued through the server’s ACME nonce mechanism. This protects ACME requests against replay under the protocol’s normal authentication rules. The nested EAB protected header must not contain a nonce. Those requirements are both true at once; developers sometimes copy a generic outer JWS builder into the nested path and accidentally violate the inner rule.
A useful mental model is that the outer signed request authenticates a fresh ACME protocol operation, while the inner MAC proves a key-to-external-account association within that operation. The outer request is the envelope being submitted to newAccount. The inner binding proof is not an independent ACME POST message with its own replay nonce and has a different header contract.
If the CA reports a bad or stale outer nonce, the client should follow the standard ACME recovery procedure and obtain an appropriate nonce before constructing a replacement authorised request. If the CA rejects the inner header because it contains a nonce, fixing the outer nonce will not solve that problem. Diagnose by layer: transport, outer JWS, inner EAB JWS, and external policy.
Never infer that the absence of an inner nonce means any captured binding is safe for unlimited reuse. The CA controls policy around EAB key issuance, expiry and allowed account registrations. The signed outer request also has replay protection. Credential reuse or replay risk therefore requires examining both protocol validation and the CA’s explicitly documented enrolment policy, without inventing universal single-use guarantees.
Protect the MAC key as a registration capability
The external MAC key is a symmetric secret. Anyone able to use it under a CA’s registration rules may be able to produce an acceptable binding for a new public account key. That makes its custody a consequential operational problem, even though it is not the same as the ACME account private key. Protect it in a secret manager or an equivalent controlled process.
Avoid putting the key in command-line history, ordinary application configuration files, stack traces, chat transcripts or CI test fixtures committed to version control. A base64url-encoded form is still sensitive. A client can be configured through a secret injection path with narrowly scoped access, but the precise method depends on the provider, deployment platform and threat model.
The record should include non-secret identifiers such as key ID, CA endpoint, tenant label, provisioning time and authorised owner. Keep the secret itself protected. If a credential is rotated, coordinate the external CA record and the client configuration rather than changing only one side. An HMAC mismatch can result from an otherwise correct signing procedure using an obsolete secret.
Do not claim that all CAs universally issue one-use MAC keys, that all allow reusable keys or that a key can always be revoked through a standard ACME endpoint. RFC 8555 defines EAB verification, while key provisioning and account-association policies are handled by the CA’s external system. Query the actual provider’s current procedure before relying on an unstated property.
Hand-checked capacity planning for three fictional tenants
Consider three fictional customers A, B and C. Each plans four independent ACME agent accounts under a CA that allows those account registrations according to its own external policy. If each agent uses a separate account, the intended total is 3 customers×4 accounts per customer=12 new ACME accounts. If each customer instead coordinates its four agents through one existing ACME account, there are only three ACME accounts, though key-sharing changes the compromise boundary.
Suppose the twelve-account plan needs a distinct externally provisioned EAB credential for each planned registration, as a local policy chosen for this example rather than a universal ACME requirement. Then twelve labelled credentials are prepared. The CA might instead support another enrolment mapping, but the arithmetic is clear: twelve planned new registrations require twelve binding proofs, even if credential provisioning rules differ.
In a rehearsal, say ten registrations succeed and two fail: one because the MAC secret was decoded incorrectly, another because the inner JWK does not match the outer account JWK. The observed synthetic success fraction is 10/12=83.33 percent and the synthetic failure fraction is 2/12=16.67 percent. Those percentages are not industry data or evidence about any real CA; they simply force explicit denominators.
The operational response differs by cause. The decoding error calls for checking base64url handling and the corresponding provisioned key; the key mismatch calls for checking construction of the nested public-key payload. Repeatedly buying new credentials or regenerating all twelve accounts would be an expensive and unnecessary general repair. Use per-stage evidence before changing the allocation model.
Identity binding does not define every privilege of a tenant
Successful external account binding gives the CA a basis for associating a new ACME account with an external record. The protocol does not independently grant a list of domains, wildcard rights, certificate profiles, renewal priority or billing terms. Those may be governed by the CA’s customer system and its applicable certificate policy. A designer should not equate possession of an EAB secret with unlimited authority.
If a customer record is permitted to request certificates only for approved identifiers, that eligibility restriction should be enforced independently of whether EAB succeeds. Domain-control validation still has to occur as required by ACME and the relevant CA policy. A malicious or simply mistaken agent might register correctly and then ask for an inappropriate identifier; account onboarding success must not bypass later checks.
This separation becomes especially important in multi-tenant automation. The client may have technical access to the same certificate service used by several customers, but each request must be bound to the correct customer identity and permitted resources. Cross-tenant mistakes often arise not from broken cryptography but from incorrect environment variables, job routing or secret-selection logic.
A practical owner matrix records the intended external record, agent workload, ACME account key, allowed certificate identifiers and human escalation owner. Each column answers a different question. EAB proves a specified cryptographic link inside that matrix; an access-control system and the CA’s validation workflow enforce the other columns. That is how a narrowly defined standard fits a broader trustworthy system.
Existing ACME accounts are not automatically new registrations
After successful onboarding, an ACME client normally authenticates later orders through its established account key and account URL. A certificate renewal is not necessarily a new ACME account creation. It may create a fresh certificate order under the same account, relying on normal identifier authorisations and the server’s renewal policies. EAB should therefore not be blindly repeated on every renewal job.
Suppose a service renews thirty certificates per month under three established ACME accounts. Those thirty renewal orders do not imply thirty new EAB registrations. They concern certificate validity, challenge results and deployment state. If the service deliberately creates one brand-new ACME account per renewal, that is a separate architectural choice needing justification and can create unnecessary credential-management workload.
The site’s ACME Certificate Renewal guide explains challenges, renewal information and safe deployment as a different problem. This article concerns the point where a new public ACME account key becomes associated with a CA-side customer record. Confusing the stages can lead to incorrect alerts and wasteful creation of duplicate accounts.
When a renewal fails, first establish whether account authentication, order creation, identifier validation, certificate issuance or live certificate deployment failed. EAB is relevant if the operation actually attempted to create a new account or a new client has not been properly enrolled. It is not a general explanation for every expired-certificate incident.
Account-key rollover has its own signed exchange
An organisation may need to change its ACME account private key following a security concern or on a scheduled rotation. RFC 8555 Section 7.3.5 defines account-key rollover through a keyChange request containing assertions signed by the old and new keys. This is a different cryptographic process from first-time external account binding.
The rollover exchange establishes consent between the existing account key holder and the new key holder for the same account. The specification describes the protected nested signatures and checks against existing accounts. Successful rollover should not invalidate pending orders or authorisations solely because the account key changed. That continuity distinguishes proper account maintenance from registering a second, unrelated account.
A poor migration pattern is to treat loss of a client-side key reference as permission to create arbitrary new accounts and attach whichever stored EAB secret is available. Such behaviour can create ownership ambiguity and duplicate customer mapping. A better runbook first identifies the authoritative account URL and checks whether the intended operation is rollover, recovery, deactivation or new registration.
The EAB association with the external customer can persist as account metadata while a legitimate key rollover changes the account’s signing key. However, the precise CA policy around that association remains provider-specific. Do not assert that a new EAB exchange is always required during rollover, nor that it can never be requested by a provider. Treat the standards-defined keyChange flow and external administrative policy separately.
The out-of-band channel deserves its own threat model
A CA must provide the MAC key and identifier to the intended external account holder through some mechanism outside ACME. That might be an authenticated customer dashboard, a controlled administrative API or another approved enrolment process. RFC 8555 does not standardise a single user interface or delivery channel for these credentials, which means clients should not assume that every provider supports identical provisioning methods.
The out-of-band channel is a natural attack target. If an adversary tricks a client into accepting a substituted key identifier and secret, it may cause registration under an unintended external record. If the adversary steals a valid secret, it may be able to construct its own binding proof subject to the CA’s policies. HTTPS and authenticated client workflows are essential but do not remove all insider or configuration risks.
An agent should confirm the provider identity, selected directory endpoint and expected tenant label before using a provisioned secret. Human oversight may be warranted when a first registration alters an organisation’s CA account mapping. Never silently send an EAB credential from one CA to another CA’s endpoint merely because both describe their service as ACME-compatible.
Provenance can be documented without exposing credentials. Record who approved enrolment, which authorised provider delivered the key, what external tenant was intended and which new public ACME key was registered. Such records help investigate a future mismatch without turning logs into a repository of long-lived registration secrets.
A server response must be interpreted in context
The ACME directory may advertise externalAccountRequired=true, and an omitted binding may trigger an externalAccountRequired error. An unrecognised kid, wrong MAC, malformed nested JWS or mismatched public key can cause a separate registration rejection. User-facing error detail varies, so an agent should not guess one specific server string for every cryptographic failure.
If a request returns an account representation, verify the expected account URL, status and any returned externalAccountBinding value according to the RFC’s reflection rules. When the binding was required and verified, the returned value should match the submitted one. That is an important integrity check but should be combined with the authoritative CA state and the intended tenant mapping.
When an HTTP request times out after submission, do not automatically assume it failed or succeeded. The account may have been created even if the response was lost. Recover through the standard ACME account lookup or known account-key mechanisms where supported and authorised, then reconcile the intended key and external record before any retry. Blind creation can cause duplicates or account ownership confusion.
A clean incident note states what was observed: directory requirement, endpoint, masked kid, signature validation status, returned account URL and any relevant failure stage. It does not log private keys or MAC secrets. This makes it possible to distinguish policy refusal, transport failure, malformed JWS and genuine server fault.
Construct independent positive and negative protocol tests
Begin with one positive test: the CA has provisioned a known test MAC key and identifier; the outer newAccount request is correctly signed with a newly generated account key; the inner JWS names the exact newAccount URL, has an approved MAC algorithm and no nonce, and contains the matching public JWK. The expected outcome is a successfully verified external binding under an authorised test CA.
Next change exactly one property per test. Submit an incorrect kid while keeping the MAC construction otherwise intact. Change one byte of the encoded inner payload without recomputing the MAC. Introduce a protected nonce into the inner header. Use a different newAccount URL. Provide a valid MAC for JWK A but an outer signature by JWK B. Each failure probes a separate required check.
For arithmetic coverage, imagine six independent negative fixtures and one positive fixture, seven in total. Passing all seven expected outcomes would mean 7/7=100 percent of this tiny constructed test set passed, not that the implementation is perfectly secure or that a production failure rate is zero. A single success percentage without coverage details is a weak assurance statement.
Add boundary tests for base64url decoding, malformed or unsupported algorithms, unexpected headers, account state and secret-selection mistakes. Test against a sanctioned staging CA or local conformance harness, not against real customer accounts in an uncontrolled environment. Check RFC rules independently of one popular library’s happy path.
Client support cannot be inferred from basic ACME support
A program may implement ACME certificate issuance while omitting EAB configuration. If a selected CA requires externalAccountBinding, such a client may not be suitable for new account onboarding even though it works with a different public CA. Before deployment, check the actual client version and its documented options for key ID and MAC secret.
The existence of an option named EAB is not enough. Confirm which CA directory it targets, whether base64url MAC keys are decoded properly, whether the inner header uses MAC authentication and no nonce, and whether the outer account key is the same as the inner JWK. These are protocol requirements, while the user interface for providing the values is implementation-specific.
Avoid copying command examples between clients without checking flag semantics. Some clients take a literal encoded string; others may expect raw key bytes or a reference to protected configuration. A mismatched interpretation can look like a cryptographic failure even though each component is behaving consistently with its own API. The exact fix is to align key encoding and documented configuration.
The method should remain auditable after software updates. A new library may change defaults for cryptographic algorithms, key serialization or retry behaviour. Maintain a small authorised conformance suite and run it when updating the client or CA endpoint. The goal is to detect a regression before a critical certificate registration occurs in production.
Diagnose registration failures in the right order
Start with discovery. Is the client using the intended CA directory, and does it reveal an EAB requirement? If yes, is the expected external account provisioned? Can the intended agent access the correct key identifier and MAC secret through the approved secret channel? A surprising number of apparent protocol errors can be explained at this stage without touching cryptographic code.
Next inspect the outer ACME request. Is its account JWK correct, is its asymmetric signature valid, does its protected URL match the endpoint, and is its replay nonce acceptable? If outer authentication fails, an EAB MAC cannot rescue the request. Correct the earlier layer before generating repeated external proofs or changing customer records.
Then check the inner binding JWS. The header must use a MAC algorithm, carry the correct external kid, omit nonce and name the exact outer URL. The MAC must verify with the CA-side secret, and the payload must represent the same JWK used by the outer signature. If the server rejects the binding, use trusted local evidence to identify which rule failed rather than retrying every possible variation.
Finally check the account state after any ambiguous completion. Did the CA create an account under the intended key and customer record? A time-out does not justify blind re-creation. Once a valid account is established, continue to order validation as a separate workflow. This ordering reduces damage from retries and preserves a comprehensible audit trail.
A constructed weekly operations example separates counts from claims
Imagine a certificate automation team with twelve intended new account registrations this week and forty-eight certificate renewal orders under accounts registered previously. The team records a total of sixty workflows, but only twelve need first-time EAB consideration under this architecture. The EAB-related fraction is 12/60=20 percent; the remaining 48/60=80 percent concerns an existing-account certificate lifecycle.
Suppose one of the twelve registration attempts lacks a required binding and another has a mismatched kid, while ten register successfully. The registration success fraction is 10/12=83.33 percent, not 10/60, because renewal orders are not in the registration denominator. A dashboard that mixes these populations could hide recurring onboarding defects under a large volume of successful renewals.
Now suppose forty-seven of forty-eight renewal orders succeed and one fails because the domain validation check cannot complete. The synthetic renewal success is 47/48=97.92 percent. That renewal failure is not an EAB failure. Reporting two separate rates reveals the actual nature of work to be repaired: registration credential configuration and domain validation process.
No real reliability conclusions follow from the invented figures. Their purpose is to teach denominator discipline. When applying this method to production, record actual observed counts, sample periods, authoritative system events and ambiguous states. Distinguish created accounts, submitted attempts, repeated retries and completed certificate deployments.
Changed-context transfer: a different CA and shared account
Consider a second fictional organisation with five application services, two certificate authorities and a plan to use one ACME account per CA. A previous example used one new account per agent, but here all five services submit through a centrally controlled account per CA. How many account registrations are initially needed? How many EAB proofs must be constructed if both CAs require one new-account binding and permit this architecture?
There are two account registrations: one for each CA. The services may generate many certificate orders, but the initial registrations remain two. Two required new-account binding proofs are needed, one for each registration. Five services times two CAs equals ten possible service-CA relationships, but it does not mean ten new ACME accounts when the architecture deliberately reuses one account per CA.
Now change the rule: each application service must have its own isolated ACME account at both CAs. The number of registrations becomes five services×two CAs=ten. If the CAs require a distinct binding proof for every new account, the process needs ten binding proofs. Whether ten distinct external MAC secrets are issued remains a CA provisioning-policy question; the protocol does not impose a universal one-secret-per-account rule.
The critical transfer insight is the difference between account topology and customer eligibility. The first architecture has fewer account private keys but a larger shared compromise boundary. The second isolates service keys at the cost of more registrations and operational state. EAB binds each newly registered key to an external record; it does not decide which topology is safest for a particular organisation.
What EAB cannot establish and what evidence is still required
EAB does not independently prove control of a certificate’s requested DNS identifiers. That evidence comes from ACME authorisation and challenge processes and the CA’s validation policy. Nor does EAB prove that the secret’s human custodian is trustworthy, that the directory response was obtained from the intended service or that a newly issued certificate was deployed correctly.
EAB also cannot protect a stolen or broadly shared MAC secret from misuse under permissive registration policies. Appropriate credential delivery, monitoring, rotation and revocation procedures must be supplied by the CA’s external account system and the client operator. The standard’s binding algorithm is one component of that larger security design, not an end-to-end substitute for it.
For current AI-enabled workflows, the sensible role is constrained automation. An agent can inspect directory metadata, request authorised secret material, assemble cryptographic protocol structures with a vetted library and check returned account state. It should not improvise credential disclosure, register accounts under another tenant or proceed after an access refusal. There is no reason to frame these existing software capabilities as evidence that future artificial superintelligence already exists.
The central lesson is to make two independent cryptographic attestations meet at one exact public key: an outer account signature and an inner CA-provisioned MAC, both bound to the same newAccount endpoint. When the five validation checks, customer policy and later certificate lifecycle are treated separately, agent automation becomes easier to audit and safer to operate.
Frequently asked questions about ACME EAB
Is EAB mandatory for every ACME CA?
No. RFC 8555 permits an ACME server to require external account binding, but it does not mandate EAB for all CAs. When the server requires it, the directory must advertise externalAccountRequired=true. Verify the selected CA’s actual documented onboarding requirements.
Does an EAB key identify a domain owner?
No. It associates a newly registered ACME public account key with an existing external CA account record under the CA’s verification rules. Domain identifier validation is a separate part of the certificate issuance process.
Why are there two different JWS algorithms?
The outer newAccount JWS is asymmetrically signed with the new ACME account private key; its algorithm cannot be a MAC type under the standard request-authentication rule. The inner EAB JWS uses a MAC algorithm with the CA-provisioned external secret.
Why must the inner JWS omit a nonce?
The inner object is a binding proof inside the outer ACME request, not an independent replay-protected ACME POST. RFC 8555 expressly requires the inner protected header to have no nonce. The outer signed request still includes the normal ACME replay nonce.
Can the key identifier be published openly?
The kid identifies which externally provisioned MAC key the CA should look up, and is not itself the MAC secret. Nevertheless, account labels and metadata can be sensitive in context, so log only what is necessary. The MAC key must be protected as a secret.
Can the same EAB secret be used repeatedly?
RFC 8555 does not prescribe a universal one-use credential lifecycle. A particular CA may constrain registration count, expiry, customer eligibility or revocation through external policies. Check those policies before designing automated retries or provisioning.
Is EAB required for every certificate renewal?
Not ordinarily as an intrinsic part of renewal under an existing authenticated ACME account. EAB concerns newAccount registration. A client that creates a new account during its renewal workflow is performing another onboarding operation, which should be evaluated separately.
What if the MAC verifies but the public keys differ?
The CA must reject the binding when its payload does not represent the same public key used by the outer JWS. A valid MAC on JWK A cannot justify an outer account controlled by a different key B.
Can a successful binding be treated as certificate authorisation?
No. Account binding is not a replacement for validation of requested identifiers, order status, challenge completion, compliance policy or safe deployment of a new certificate. Those activities must have their own checks.
What is the safest initial diagnostic?
Confirm the intended directory, externalAccountRequired flag, masked key identifier, outer request key and inner-to-outer public JWK match without printing private keys or MAC material. Determine the failing layer before changing credentials or creating another account.
Original standards, verification rules and publication dates
Primary standard: RFC 8555, Automatic Certificate Management Environment, Section 7.3.4 External Account Binding, published March 2019. This is the controlling source for EAB required directory metadata, inner JWS header requirements, MAC verification, public JWK matching and account-object reflection.
The complete RFC 8555 also explains ACME outer request authentication in Section 6.2, replay nonces in Section 6.5, directory metadata in Section 7.1.1, account objects in Section 7.1.2, account key rollover in Section 7.3.5, and the independent certificate issuance stages in Sections 7.4 and 7.5.
For JOSE encoding and HMAC algorithm definitions consult RFC 7515, JSON Web Signature and RFC 7518, JSON Web Algorithms. Those standards explain the protected-header signing input and MAC-based algorithm family. Any live client configuration must additionally follow the actual CA and library documentation.
The official RFC 8555 information and errata page is the location to check later corrections and updates. Standards claims here are based on the stated normative source, not on a fictional deployment, retrospective measurement or a provider’s promotional account.
Verified related eduKate pathways
Start at How Super Intelligence Works to situate today’s constrained software-agent tooling within a larger discussion of models, tools, human oversight and the limits of unproven future AI capabilities.
Once an ACME account exists, the independent ACME Certificate Renewal — Challenges, ARI Windows and Verified Deployment guide explains renewal and deployment risks that account-binding integrity alone does not address.
The DNS CAA Policy — Authorized CAs, Wildcard Rules and Issuance Checks guide addresses certificate authority policy discovery from DNS, a different problem from possession of an external account MAC key.
The Certificate Transparency — SCT Promises, Merkle Proofs and Monitoring guide covers monitoring and evidence after issuance. Linking these stages preserves their differences instead of calling every certificate-related control EAB.
A reader should finish able to answer four independent questions: who controls the newly registered ACME public key, who approved its external account binding, which domain identifiers are later authorised, and which certificate is actually served after deployment.