We are pleased to announce that BastionXP now supports ACME External Account Binding (EAB).

This update brings a critical layer of security to your automated certificate management. By combining standard EAB authentication with BastionXP’s robust, configurable ACME policies, IT admins can now enforce strict control over who can access the Private CA and exactly which certificates can be issued.

Here is a breakdown of what EAB is, how our policy engine works, and why the combination provides the ultimate control for your infrastructure.

1. What is ACME External Account Binding (EAB)?

External Account Binding (EAB) is a feature defined in the ACME protocol standard (RFC 8555).

In a standard, open ACME setup (like Let’s Encrypt), anyone who can reach the server can register an account. In a private enterprise environment, “open” is often a security risk.

How EAB Solves the Anonymous Account Registration Security Problem:

EAB acts as a gatekeeper for account registration. It requires the ACME client to present two specific credentials to the BastionXP server before it allows an account to be created:

• Key ID (KID): The identifier for the account.
• HMAC Key: A symmetric key used to cryptographically sign the registration payload.

Why is it Useful?

• Authentication: It prevents anonymous or unauthorized clients from registering with your ACME server. If a client doesn’t have the HMAC key, they cannot even begin the process of requesting a certificate.
• Binding: It cryptographically binds an ACME account to an external identity known by the CA.
• Auditability: Every certificate request is tied to a verified account, making it easier to track which team or service owns a certificate.

BastionXP implements EAB strictly according to the RFC standard, ensuring compatibility with all major ACME clients (Certbot, acme.sh, cert-manager, etc.).

Secure by Design: Single-Use & Time-Bound Credentials

EAB credentials (the Key ID and HMAC) are designed to be temporary “bootstrapping” keys, not permanent passwords. It doesn’t replace the role of the Account private key.

Single-Use:

EAB credentials are typically used only once—during the initial registration handshake and are bound to a client account internally. Once the ACME account is successfully created using the EAB credentials, the credentials will be marked as used. After the ACME account is successfully created with the ACME server, the client relies on its own locally generated private key for all future communications with the server. The EAB keys are no longer needed and can be safely discarded, effectively closing the door behind the user.

Basically, ACME EAB credentials are a single-use ticket provided to an ACME client to register an account with the ACME server.

Time-Bound:

When generating an EAB key in BastionXP, admins can set a strict expiration window (e.g., “valid for 1 hour”). If the credentials are not used to register a client within that timeframe, they automatically become invalid. This prevents unused keys from lingering as “ghost” credentials that could be exploited days or months later.

How EAB Works: The Workflow

External Account Binding changes the very first step of the ACME conversation—the Account Registration. It transforms an anonymous “hello” into a verified “secure handshake.”

Phase 1: The Secure Handshake (EAB Authentication)

Before any certificate can be requested, the ACME client must register an account with the BastionXP server.

1. Client Preparation: The ACME client (e.g., Certbot) is configured with a Key ID (KID) and an HMAC Key issued by BastionXP CA to each validated client.
2. Signing the Request: The client generates a standard ACME registration payload. However, instead of just sending it, it uses the HMAC Key to compute a cryptographic signature (MAC) over the registration data and its own public key.
3. Transmission: The client sends the registration request to the BastionXP ACME server, including:
   • The Key ID (so BastionXP knows which key to look up).
   • The MAC signature.
   • The client’s ACME account public key.
4. Server Verification: BastionXP looks up the secret key associated with that Key ID. It re-computes the signature.
   • Match: The client possesses the correct secret. The server creates an ACME account and binds it to that external identity.
   • No Match: The server rejects the request with an unauthorized error.

Key Takeaway: If the handshake fails, the client cannot proceed. No account is created, and no further communication is allowed.

Part 2: Standard ACME Workflow Kicks-in After EAB Validation

It is important to understand that in the standard ACME protocol (RFC 8555), EAB is strictly an account registration step. Once the EAB handshake is successful, the server treats the client like any other registered account.

The “special” EAB credentials (KID, HMAC key) are typically NOT used again; the client uses the Account private key, it just created, for all future signing.

Here is the standard workflow that kicks in immediately after the EAB validation passes:

1. Account Object Creation

The ACME server creates a new Account Object in its database. It links the client’s public key to the External Account ID (Key ID). The server responds to the client with a 201 Created status and the URL of this new account.

• State: The client is now “logged in.”

2. Order Placement

The client sends a POST request to the /newOrder endpoint. This request contains the list of Identifiers (domains or IPs) it wants a certificate for (e.g., www.example.com).

• Standard Behavior: The ACME server generally accepts the order and creates “Authorization” objects for each identifier. It does not typically check “permission” here; it just sets up the test.

3. Authorization & Challenges

The server returns a list of Challenges (DNS-01, HTTP-01, or TLS-ALPN-01) for each identifier.

• The server is essentially saying: “Okay, you want a certificate for example.com? Prove you control it by putting this token in your DNS or Web Server.”
• The client performs the action and tells the server it is ready.
• The server verifies the challenge.

4. Finalization (CSR Submission)

Once the challenges are solved (status becomes valid), the client generates a Certificate Signing Request (CSR) and sends it to the server’s /finalize endpoint.

5. Issuance

The server signs the CSR and issues the certificate. It returns a URL where the client can download the final certificate chain.

2. Granular Control with BastionXP ACME Policies

While EAB handles authentication (verifying if the client is allowed to talk to the CA), it doesn’t inherently control what that client can do. That is where BastionXP’s Configurable ACME Policies come in.

We have also designed a flexible policy engine (not required by the ACME standards) that resides on the BastionXP CA. This allows IT admins to define explicit rules about what certificates can be requested/issued, regardless of who is asking.

These policies are structured like a typical network router or firewall Access Control List (ACL) rules that allow/deny a range of domains/IPs or a specific domain/IP.

What you can control:

• Allowed Domains: Whitelist specific domains (e.g., *.corp.local) and reject everything else.
• Allowed IPs: Control which IP addresses can be included in the certificate SANs (e.g., ‘10.1.1.0/24’).
• Deny Lists: Explicitly block sensitive domains or reserved IP ranges.

This policy layer ensures that even a valid, authenticated ACME client cannot go rogue and request a certificate for a domain it isn’t authorized to manage.

3. Better Together: Authentication + Authorization

The real power for IT admins comes from using these two features in tandem. By layering EAB (Authentication) with Configurable Policies (Authorization), BastionXP provides a Zero Trust approach to certificate issuance. BastionXP enables certificate management automation without compromising security.

The Workflow:

1. The Handshake (EAB): A server attempts to register with BastionXP. It presents its EAB Key ID and HMAC. BastionXP validates the signature. Result: The client is authenticated and allowed to proceed.
2. The Request: The authenticated client requests a certificate for db.production.local with IP 10.0.1.5.
3. The Guardrail (Policy): Before issuance, BastionXP checks the configured policies:
   • Is *.production.local in the allowed domains list?
   • Is 10.0.1.5 in the allowed IP subnet?
4. The Decision:
   • If the request matches the policy: Certificate Issued.
   • If the request violates the policy: Request Denied.

Summary Table

Step	Standard ACME	ACME with EAB + BastionXP Policy
1. Connect	Anonymous connection allowed.	Connection requires valid Key ID & HMAC.
2. Account	Anonymous account created.	Account bound to known Identity.
3. Order	Client requests any domain.	Client requests domain.
4. Check	CA checks if domain exists.	BastionXP checks if domain is ALLOWED by Policy.
5. Validate	DNS/HTTP Challenge.	DNS/HTTP Challenge.
6. Result	Certificate Issued.	Certificate Issued (only if Policy permits).

The Benefit for IT Admins

This dual-layer approach solves the “internal threat” problem. Previously, simple network access to the CA might have been enough to get a cert. Now, you have:

• No Anonymous Access: Only clients with EAB keys can connect.
• No Scope Creep: Even valid clients are restricted to the domains and IPs you explicitly defined in the policy.

Conclusion

With the addition of ACME EAB support, BastionXP continues to make internal PKI both more automated and more secure. We give you the standard tools to authenticate your automation, and the policy controls to ensure that automation stays within the lines.

Secure your private PKI today with BastionXP.