CertLocker's Gateway acts as an ACME responder. Every server that already knows ACME — HAProxy, WIN-ACME, any ACME client — can pull its certificate directly. No agents. No scripts. No custom tooling required.
Scoped tokens tie each machine to the certificates it may fetch through the Gateway.
The CertLocker Gateway speaks ACME (RFC 8555). This means your infrastructure doesn't need to learn anything new. HAProxy's native ACME client, WIN-ACME on IIS, Certbot, or any standards-compliant ACME client can request and renew certificates automatically.
All traffic routes through the Gateway — it validates requests, applies your access policy, and responds with the certificate. Each machine authenticates with its own scoped token. One machine's token cannot retrieve another machine's certificate.
# HAProxy native ACME — points at CertLocker Gateway
acl is_acme path_beg /.well-known/acme-challenge/
# Resolve cert via CertLocker ACME endpoint
frontend https-in
acme-provider https://gateway.certlocker.io/acme
acme-domains api.example.com
✓ HAProxy requests cert via ACME on startup
✓ Renews automatically before expiry
If it speaks ACME, it works with CertLocker out of the box.
HAProxy 2.3+ includes a native ACME client. Point it at the CertLocker Gateway and it handles issuance and renewal automatically — no Certbot, no cron jobs.
WIN-ACME is the standard ACME client for Windows IIS. Configure it to use the CertLocker ACME directory and it manages cert bindings on IIS automatically.
Certbot, acme.sh, Caddy, Traefik, and any RFC 8555-compliant client can request certs from the CertLocker Gateway using a standard ACME directory URL.
All delivery routes through the CertLocker Gateway. Clients authenticate with a scoped token — no inbound access to your network required.
The Gateway is the single point of control. Every certificate request — from any client, on any platform — goes through it.
Add your TLS certificate and its private key to CertLocker. Assign it a scoped access token that identifies which client may request it.
Point your ACME client (HAProxy, WIN-ACME, Certbot, or any other) at the CertLocker ACME directory endpoint. Use the scoped token as your ACME account credential.
Your ACME client fetches the certificate on first run and handles renewal automatically using its built-in renewal cycle. No scripts, no cron jobs, no custom agents.
HAProxy, IIS, and most ACME-integrated servers restart or reload automatically after renewal. The new certificate is live within minutes of expiry approaching.
CertLocker is a credential vault and delivery platform, not a certificate authority. You upload certificates you have issued (via Let's Encrypt, a commercial CA, or your own PKI). CertLocker stores them securely and delivers them to your infrastructure via ACME.
No. CertLocker delivers certificates via standard ACME — the same protocol used by Let's Encrypt. If your server already has an ACME client (HAProxy native ACME, WIN-ACME for IIS, Certbot), you only need to point it at the CertLocker Gateway. Nothing new to install.
WIN-ACME supports configurable ACME directories. You set the CertLocker Gateway ACME endpoint as the CA URL in WIN-ACME, configure your scoped token as the credential, and WIN-ACME handles IIS certificate binding and automatic renewal from there.
Any ACME client that supports a custom ACME directory URL (RFC 8555) will work. Certbot, acme.sh, Caddy, Traefik, and step-ca are all compatible. If your client supports pointing at a custom CA URL, it works with CertLocker.
ACME-native. Works with HAProxy, IIS, and any standards-compliant client. No agents, no scripts.
