u/SuccessFearless2102

Any tips of getting them first saas customers I have a budget of 150$ and am on all the social media and linkedin. It's a technical production for engineers and IT people. We haven't had much success. It just seems everyone we've reached out to is either at the wrong time for them or they never reply. I ran an ad campaign and got 100 clicks to my CTA page but no registrations.

For those who are not running in Kubernetes and have something to manage your SSL certificate renewals, what are you using? Certbot + Let's Encrypt? Windows guys, WinAcme?

How are you monitoring renewal dates? I know blackbox exporter does a good job out of the box.
Thanks

Main Post

I recently spent some time getting HAProxy 3.3 ACME to work with a real certificate delivery flow.

It wasn't a run certbot and copy a file" setup. I wanted HAProxy to start fetch a certificate through ACME keep it renewed and serve it at the edge without any help.

It works now. I learned a hard lesson:

"ACME succeeded" and "production is serving the right certificate" are not the same thing.

The issues I ran into were all things that matter at 2am:

• HAProxy needs a certificate file before it can bind to port 443 even if ACME is going to replace it later.

• If the first file is a throwaway self-signed cert you need to be clear about whether HAProxy's reusing that key or the real key.

• HAProxy can fetch a certificate. Then discard it if the public key does not match the private key it used for the CSR.

• reuse-key on matters if you expect HAProxy to reuse an existing PEM key of generating a fresh one per order.

• Key type and curve have to match. ECDSA and bits 256 are not the same as some EC key.

• The admin socket can exist before HAProxy is actually listening on it. If your startup script fires one command and gives up on Connection refused you can boot into a self-signed cert forever.

• A config check is not always the same as validating the startup path.

• ACME error responses need nonce handling or one real error turns into a pile of invalid nonce noise.

• The file on disk is less important than what the process has loaded and what clients receive over TLS.

The private key mismatch was the problem.

HAProxys ACME flow is like this:

1. Generate a key or reuse one from an existing PEM if configured.

2. Build a CSR with the public key.

3. Send the ACME order/finalize flow.

4. Download the certificate.

5. Check that the downloaded certificates key matches the private key used for the CSR.

6. If it does not match, discard it.

That behaviour makes sense. The problem was our certificate source returned a -provisioned certificate from a vault rather than issuing a fresh certificate for whatever CSR HAProxy had just generated.

So HAProxy did the ACME flow downloaded the cert decided the key did not match and kept serving the old material. From the outside a lot of things looked healthy until you checked the endpoint.

The solution was to split the PEM roles:

• bootstrap.pem exists so HAProxy can bind on first start.

• acme.pem is the ACME staging material. Contains the private key HAProxy should reuse for the CSR.

• live.pem is the thing bound to port 443.

On startup:

1. Seed the ACME private key before HAProxy starts.

2. Validate that the staged key and certificate public key match.

3. Start HAProxy with live.pem.

4. Trigger ACME through the runtime/admin socket once HAProxy is actually accepting socket connections.

5. Let HAProxy stage the ACME result.

6. Independently verify the staged key/cert match.

7. Promote the verified bundle into live.pem.

8. Probe the TLS endpoint and record what it is serving.

The verification commands were important:

# Is the staged ACME cert loaded?

echo "show ssl cert @cert-store/name" | socat stdio /var/run/haproxy/admin.sock

# Is the cert loaded?

echo "show ssl cert /usr/local/etc/haproxy/certs/live.pem" | socat stdio /var/run/haproxy/admin.sock

# What does the outside world actually get?

s_client -connect 127.0.0.1:443 -servername example.com </dev/null 2>&1 \

| grep -E "subject|issuer|Verify|Protocol|Cipher"

The main thing I would change earlier is failing loudly before HAProxy starts if the seeded key material is wrong. A running HAProxy process with a bootstrap cert is worse than a dead deploy, in this case because it looks healthy until someone checks the handshake.

For people running HAProxy at the edge: how do you treat certificate automation?

Do you consider the job done when ACME renews, when HAProxy reloads or only after a probe confirms what port 443 is actually serving?

If you are using HAProxy native ACME already are you doing runtime API updates, full reloads or something else?

We built CertLocker because certs, secrets, SSH and RDP access were always messier in the real world than they looked on paper.

Hey all,

I’m Sean, a DevOps engineer and one of the people building CertLocker.

A lot of my background has been in finance, trading and banking-style infrastructure. In those environments, trust matters, audit matters, uptime matters — but in reality, you still see the same problems everywhere:

Certificates stored in random places.
Shared passwords passed around.
SSH keys living too long.
RDP access with very little visibility.
HAProxy cert renewals held together by scripts.
Windows servers, OpenStack, VMs, bare metal and internal apps sitting outside Kubernetes.
Auditors asking awkward but fair questions.

That is really why we started building CertLocker.

Most tools we looked at were either Kubernetes-first, too enterprise-heavy, or solved only one piece of the problem. We wanted something for the infrastructure teams managing the messy middle: real servers, real certs, real secrets, real access, and real audit requirements.

CertLocker brings those operational trust pieces together in one place:

• TLS certificate inventory and expiry tracking
• ACME automation
• HAProxy certificate delivery
• Secrets and private secrets
• SSH access tokens
• Browser-based SSH access
• Browser-based RDP / remote desktop access
• Bastion access
• Endpoint probes
• Groups, RBAC and audit trails
• SaaS or on-prem / VPS install

We’re now looking for beta testers and early feedback from DevOps engineers, SREs, sysadmins, MSPs, infrastructure teams, and anyone who has had to deal with certificate renewals, secrets, SSH/RDP access, bastions, audits or “temporary” scripts that became production-critical.

This is not a polished sales pitch. We genuinely want to know:

Would this solve a real pain you’ve seen?

Or would you already solve this with Vault, step-ca, Ansible, scripts, Guacamole, cert-manager, password managers, or something else?

Site: https://certlocker.io
Technical write-ups: https://certlocker.io/blog

If this sounds relevant to your world, I’d love to hear your thoughts, feedback, objections, or use cases.