ACME Endpoint Tester and Meerkat Test CA: Protocol Validation for RFC 8555

What Is ACME?

The Automatic Certificate Management Environment (ACME), defined in RFC 8555, is the protocol that lets a web server request, renew, and revoke a TLS certificate from a CA without any human involvement. A client proves control of a domain using a standardised challenge, and the CA issues or revokes a certificate in response — all over HTTPS, all machine-to-machine.

Let's Encrypt popularised ACME; today it is supported by every major publicly trusted CA that issues DV TLS certificates, and by most private CA platforms used in enterprise environments. Clients including Certbot, lego, and acme.sh speak RFC 8555 natively.

The protocol's simplicity is deceptive. Under the hood, every request is a JSON Web Signature (JWS) object with a protected header carrying a server-issued nonce, the request URL, and the caller's account key. Challenge types differ in how proof of domain control is delivered — and the RFC is precise about what is required at each step. Getting any of it wrong produces a CA that issues to the wrong people, fails to revoke when it should, or accepts tokens it was supposed to reject.

The Meerkat ACME Web Service

The Meerkat ACME Web Service is a full RFC 8555 implementation running a test CA. It is not a sandbox for Let's Encrypt — it is an independently operated CA with its own issuing hierarchy, its own certificate repository, and its own CT log. Certificates issued here carry embedded SCTs and appear in a public directory, but they are not trusted by any browser or operating system. They exist solely to let you test ACME flows end-to-end against a real, conformant server.

The server's directory endpoint is the entry point all ACME clients need. From there, every subsequent URL is discovered dynamically from the directory response — no hardcoding required.

The ACME Endpoint Tester

The ACME Endpoint Tester is a browser-based tool that walks the complete RFC 8555 flow against any ACME server you point it at. It is not a client that issues certificates you plan to use — it is an inspector that drives the protocol step by step, checks conformance at each step, and captures every raw request and response for review.

What it tests

The tester covers the full protocol lifecycle in a single session:

1. Directory validation — fetches the directory, verifies all five required fields are present, and notes whether the optional renewalInfo field is advertised for ARI. newNoncenewAccountnewOrderrevokeCertkeyChange
2. Account creation — generates an ephemeral RSA-2048 key pair, fetches a nonce, and creates an ACME account. If External Account Binding credentials are provided, they are included in a correctly formed EAB JWS using HS256.
3. Order placement — places a new order for the specified domains and validates the server's response against RFC 8555 §7.4.
4. Authorization and challenge — fetches each authorization, selects the requested challenge type, computes the key authorisation value, and presents it. For dns-01, it shows the base64url SHA-256 token value you would add as a TXT record.
5. Finalization — generates or accepts a CSR, converts it to base64url DER, and submits it to the finalize URL. Polls the order until it reaches valid status.
6. Certificate download — retrieves the issued certificate chain, displays the subject, issuer, validity window, and SANs, and offers copy, download, lint, and parse actions.
7. Post-issuance tests — runs revocation via revoke-cert and, if the server advertises renewalInfo, queries the ARI window for the just-issued certificate.

Conformance checks

At each step the tester flags deviations from the RFC. Examples include: a server returning 200 instead of 201 on account creation, a POST response missing the Replay-Nonce header, an order response missing the finalize field, or a Content-Type header that does not match application/json. These appear as yellow warnings rather than hard failures — the test continues, but the deviation is recorded.

Deprecated and forbidden challenge probing

Selecting tls-sni-01, tls-sni-02, or proofOfPossession from the challenge method selector puts the tester into a probe mode. Rather than trying to complete the challenge, it signals the challenge to the server and checks whether the server accepts it. RFC 8555 and the CA/Browser Forum Baseline Requirements forbid these methods; a conformant server must reject them. The result is recorded as either compliant (rejected) or BR violation (accepted).

External Account Binding

When EAB credentials are provided, the tester constructs a correctly formed EAB object — a JWS signed with HS256 using the MAC key, with the protected header containing alg, kid, and url, and with the account public JWK as the payload. This is embedded in the newAccount request as the externalAccountBinding field. The random EAB generator produces a well-formed key ID and a 32-byte (256-bit) base64url MAC key — correctly formatted but guaranteed to be rejected by any real CA, making it safe for testing EAB rejection paths.

The Protocol Evidence Report

Every HTTP exchange in a session is captured in full: the step name, method, URL, request body (JWS objects with key material stripped), response status, response headers, and response body. At the end of the flow, the Generate Report button assembles all of this into a structured Protocol Evidence Report you can review inline or download as JSON.

The report includes a URL summary table that maps each ACME resource URL to the steps that contacted it, the HTTP methods used, and the response codes received. This gives a complete, auditable record of the conversation between the tester and the ACME server — every nonce used, every order URL referenced, every challenge signalled.

How They Work Together

The tester and the Meerkat ACME Web Service are designed to be used together. The web service directory URL is pre-filled as the placeholder in the tester's endpoint field. Running the tester against the Meerkat server lets you complete the full ACME lifecycle — account, order, domain validation, issuance, revocation, and ARI — end-to-end, against a server that implements every RFC 8555 feature, without needing to control real DNS or serve real HTTP challenge tokens.

For http-01 validation, the server checks the token at the domain you list in the order — so the domain must resolve to a server you control. For exploring the rest of the flow without owning a domain, dns-01 against a test domain you can edit, or Pebble running locally, is the practical choice. The Skip TLS verification checkbox allows the tester to connect to self-signed, untrusted, or staging endpoints.

Who This Is For

CA developers and platform engineers

Building or maintaining an ACME server implementation requires testing the full protocol surface: account lifecycle, order state machine, challenge signalling and polling, finalization, certificate delivery, revocation, and ARI. The tester drives that surface systematically, flags non-conformant responses with the specific RFC clause they violate, and produces a report you can use in a pull request review or a conformance test suite.

The forbidden-method probe is particularly useful during initial CA development: many ACME server libraries do not reject tls-sni challenges by default. Running the probe against a staging build before it is deployed catches that class of BR violation before it reaches production.

PKI auditors

A CA that issues certificates via ACME is required by the Baseline Requirements to implement domain control validation correctly and to handle revocation within the mandated timeframes. The protocol evidence report gives auditors a verbatim transcript of the server's behaviour — response codes, nonce handling, error types, and challenge acceptance — without requiring the auditor to write their own ACME client or install any tooling.

The Meerkat ACME Web Service also provides a reference point: if a behaviour is present in the Meerkat server and absent or different in the CA under audit, that difference is a finding worth investigating.

Automation and DevOps engineers

Engineers integrating Certbot, lego, acme.sh, or a custom ACME client against a private CA often hit the same first-hour problem: the client fails with a cryptic error and it is not obvious whether the issue is in the client configuration, the CA's ACME implementation, or the network path. The tester narrows the failure to a specific step and shows the raw server response at that step — making it far faster to distinguish a misconfigured challenge from a server-side protocol error.

For engineers validating a private CA deployment, running the tester against the new CA's directory before rolling it out to clients confirms that the full protocol flow works end to end before Certbot or lego ever touches it.

Using Standard ACME Clients Against Meerkat

Any RFC 8555-compatible client can issue certificates from the Meerkat ACME Web Service by pointing it at the directory URL. The web service page has copy-pasteable commands for Certbot, lego, and acme.sh covering single-domain http-01, multi-SAN, wildcard dns-01, and key type selection (RSA 4096, ECDSA P-384). No account registration, no EAB, no portal — just the directory URL and a domain you can prove control of.

This is useful when verifying that a client version handles a specific RFC 8555 feature correctly — for example, confirming that a Certbot version supports ARI (--preferred-chain and renewal window awareness) before upgrading a fleet, or that a lego build handles multi-value SANs in the expected order during finalization.