Build Notes: ACME Workflows, Cloud Imports, and Deployment Hardening

We want CertLocker to be a product customers can trust operationally, not just a clean UI around certificates. That means being open about the work behind the scenes: what we improved, what we learned, and where we tightened behavior after running the product through real deployment paths.

This is a short engineering update from the last week of work across the CertLocker application, HAProxy edge container, and Ansible deployment repo. We also onboarded a customer into a private trial. We are not naming them here, but that kind of hands-on evaluation is useful because it forces the product to meet real operator expectations instead of only demo-path expectations.

ACME moved from endpoint support to visible workflows

CertLocker already had ACME support, but an operator needs more than a directory URL. They need to see the orders, authorisations, challenge state, certificate issuance state, and history when something does not behave exactly as expected.

The latest UI work adds an ACME section with reusable clients, order views, and workflow tracking. The important part is not the table itself. It is the ability to follow an ACME request from client configuration through challenge handling and final certificate issue.

That visibility matters because ACME failures are often boring and specific: the wrong hostname, a stale nonce, a route going to the wrong backend, or a client expecting a challenge response that never arrives. Surfacing workflow state gives operators a faster way to answer where did this stop? instead of reading proxy logs first.

We added Pebble as a repeatable ACME test environment

We also added optional Pebble deployment support in our Ansible stack. Pebble is the small ACME test server from the Let's Encrypt project, and it gives us a controlled place to exercise ACME behavior without pretending the public CA path is the only path worth testing.

This is internal test infrastructure, not a customer-facing feature by itself. But it is important. Certificate systems fail in boundary conditions: challenge timing, retry behavior, nonce handling, route prefixes, and client-specific assumptions. Pebble gives us a way to make those paths repeatable instead of anecdotal.

The HAProxy work now includes optional Pebble routing as well, so a deployment can expose the test ACME backend when needed and omit it when not needed.

HAProxy routing got sharper around trust UI versus ACME gateway

One of the more useful fixes was also one of the least glamorous: splitting operator ACME UI/API traffic from RFC 8555 ACME protocol traffic at HAProxy.

The trust UI has operator routes such as ACME clients and orders. The gateway has protocol routes such as directory, nonce, new-account, new-order, authorisation, certificate, revoke, and key-change. Treating every /rest/acme/* path the same was too blunt, so the HAProxy routing now sends protocol paths to the gateway while leaving operator JSON routes on the UI/Edge path.

That distinction is easy to miss during development and painful in production. It is also exactly the kind of edge behavior we want to talk about honestly: certificate automation is only reliable when routing, client behavior, and audit visibility all line up.

Cloud host import became more operator-friendly

We made progress on AWS and OpenStack host import flows. The goal is simple: if your infrastructure already exists in a cloud inventory, CertLocker should help you bring hosts under certificate and access management without retyping everything by hand.

The import work covers discovery, preview, duplicate detection, group mapping, usernames, and private key handling. For AWS, the importer can parse credential text, discover EC2 instances, infer useful groups from metadata, and match uploaded PEM keys by key name. For OpenStack, the flow supports both form-based credentials and clouds.yaml-style input, including application credentials.

There is a product principle underneath this: import should be reviewable before it changes anything. Operators need to see what will be created, which hosts already exist, what groups will apply, and what key material is being associated with each host.

Endpoint probes remain the backstop

One thing we keep coming back to is that certificate renewal is not the same as certificate correctness. A certificate can be present in storage and still not be the certificate your users are seeing.

Endpoint probes are how CertLocker keeps that distinction visible. They check what an endpoint is actually serving, not just what the inventory says should be deployed. That catches reload gaps, wrong paths, old certificates still cached in a process, and mismatches between expected and served TLS state.

Audit is not decoration

ACME automation, cloud imports, secrets, SSH access, and certificate delivery all create security-relevant events. We spent more time making sure those flows are visible through the product rather than hidden in application logs.

For a certificate platform, audit is not a compliance afterthought. It is how a team answers who created a token, which import changed host access, why a certificate was requested, and what happened during renewal.

The honest status

The honest status is that this was infrastructure-heavy work. Some of it is user-visible now, especially the ACME workflow screens and importer improvements. Some of it is the scaffolding that makes future customer deployments less fragile: Pebble labs, HAProxy route separation, optional landing/Pebble backends, health checks, and deployment templates.

That is the shape of a product like CertLocker. The visible workflows matter, but the quiet operational details matter just as much. Certificate management only earns trust when the boring paths are tested, observable, and recoverable.