A certificate issued. Did the service actually start serving it?
A successful ACME order is not the end of the job. The awkward bit starts afterwards: which host got the key, did the service reload, and is the public endpoint serving the certificate you think it is?
It is very easy to call certificate automation finished when a job copied two PEM files and returned zero. That is useful progress, but it is not proof. HAProxy can still be serving its old bundle. Nginx can have a bad config. A container can restart with the wrong mounted path. The private key can be on disk while the customer endpoint still presents yesterday's certificate.
The delivery work in CertLocker is built around a less flattering, more useful question: what can we prove after the automation says it worked?
Automation is created in the product, not slipped around it
The end-to-end flow creates a certificate Automation through the Automation language editor, attaches a scoped host token, selects the certificate, and runs it through the same UI an operator uses. The automation stages certificate material, performs the service-specific deployment action, validates or reloads the target, and records an audit message.
What a passing delivery test checks
- A disposable service container starts with a deliberately different bootstrap certificate.
- CertLocker Automation delivers the selected certificate; the harness does not deploy it over SSH or SFTP outside the Automation flow.
- The service validates/reloads using its real command.
- The test makes a live protocol call and compares the served SHA-256 TLS fingerprint with the selected certificate in CertLocker inventory.
- For Nginx, the Automation also writes a marker into the mounted content directory and the test retrieves that exact marker over HTTPS.
This distinction matters. A fingerprint comparison asks the endpoint, not the filesystem. The content marker checks that an Automation action crossed into a real service path. Neither one is a substitute for monitoring in production, but both make the delivery test much harder to accidentally pass.
More than a PEM copy: the automation language is the delivery plan
A CertLocker Automation is not limited to copying a certificate chain and key. The same reviewed, auditable language can build combined bundles, create PKCS12 keystores, invoke container commands, set the ownership and mode a service requires, validate a configuration, reload only the target service, wait for a listener, and write a success or failure audit record. Every one of those actions is attached to the scoped host token and certificate selected in the product.
That matters in mixed estates. A single certificate can need a PEM pair for Nginx, a combined bundle for HAProxy, a watched file update for Traefik, a TLS-only Redis listener, an AMQPS restart, an authenticated Elasticsearch HTTPS endpoint, or a Java keystore for Tomcat, WildFly/JBoss, and GlassFish. The delivery automation owns those service-specific steps; the test harness verifies the endpoint afterwards rather than replacing the automation with an out-of-band deployment.
The verification matrix
- HTTP and HTTPS services: Nginx, Apache HTTP Server, HAProxy, Traefik, Caddy, Elasticsearch, Tomcat, WildFly/JBoss, and GlassFish are opened in Chromium after delivery. Playwright saves a browser screenshot of the live endpoint and checks the response marker.
- Native TLS services: Redis, RabbitMQ, and MySQL are verified through their real TLS protocol clients. Playwright also saves a browser-rendered proof artifact containing the successful native result, because a browser cannot speak RESP, AMQP, or the MySQL protocol.
- Certificate proof: the automation-installed certificate, container-visible material where applicable, and the live listener fingerprint must all match the selected CertLocker inventory certificate.
- Audit proof: the final automation instruction writes a success audit including the certificate, scoped host, token, and endpoint context. The E2E flow queries and asserts that audit record after delivery.
Default templates and custom delivery plans
The saved automation catalog gives operators practical starting points for Nginx, Apache HTTP Server, HAProxy, Traefik, Caddy, Redis, RabbitMQ, Elasticsearch, MySQL, Tomcat, WildFly/JBoss, and GlassFish. Those defaults are deliberately readable: they show the certificate variables, paths, validation command, reload action, and audit outcome an operator is expected to tailor for their own host group.
The E2E matrix then runs those same patterns against disposable Docker targets, from certificate selection through Automation execution, endpoint verification, browser proof, and audit lookup. It is designed to demonstrate both sides of the product: the default service patterns that speed up common deployments, and the custom language needed when a real estate has its own paths, container names, reload semantics, and keystore rules.
Short-lived certificates make renewal testable
The local Pebble test profile is configured for five-minute certificates. CertLocker schedules an auto-renewal workflow at 75% of the certificate lifetime. The E2E assertion checks that the active CA really returned a short-lived certificate, waits for that scheduled workflow, waits for the replacement to issue, and checks that the original inventory record now has a different TLS fingerprint.
The assertion is now in the harness but is still awaiting its first full run. We are keeping that status visible because “the code looks right” is not the same as a finished rotation test. Once it passes, the next extension is to rerun the Nginx Automation and compare the endpoint fingerprint after the replacement has been deployed.
What about a real Let's Encrypt certificate?
The production path is supported through CertLocker's outbound ACME workflows: configure a Let's Encrypt client, prove control with DNS-01 or HTTP-01, store the resulting certificate and key in inventory, then use a scoped delivery path. We do not issue a public certificate as a casual test. It needs an authorised public hostname and a real DNS or HTTP challenge route. Start with Let's Encrypt staging, then use a hostname your team owns for production validation.
The wider point
Certificate operations are tied to the rest of the trust work: hosts and groups identify the target, scoped tokens constrain delivery, automation language records the action, ACME workflow state records issuance, and audit gives a later answer to “what changed?” That is the useful shape for mixed estates: not just Kubernetes, but Nginx, HAProxy, old VMs, containers, internal services and the parts of the estate nobody remembers until expiry day.
Bring one real certificate workflow
Try the hosted evaluation for the product walkthrough, or use a one-month onsite evaluation to test a real certificate, host path and reload process in your own estate.