CertDX

One ACME daemon for your whole fleet. CertDX runs ACME in a single place, caches the certificates, and hands them out to as many services as you need over HTTPS or gRPC SDS — so individual hosts never touch ACME, DNS APIs, or rate limits.

Highlights

• One issuer, many consumers — certdx_server is the only thing that talks to Let's Encrypt or Google Trust Services. Every other host pulls finished certificates from it.
• Wildcards out of the box — DNS-01 challenges via Cloudflare or Tencent Cloud, including *.example.com. One wildcard certificate is shared across all consumers, so you never hit CA rate limits no matter how many hosts or services need it.
• Drop-in for what you already run:
  • Standalone agent that writes <name>.pem / <name>.key to disk and runs systemctl reload nginx (or any command).
  • Caddy plugin as a get_certificate provider.
  • Envoy via gRPC SDS — hot-swaps certificates with no restart.
  • Kubernetes secrets refreshed in place: the client patches annotated kubernetes.io/tls secrets on every renewal.
  • Tencent Cloud resources re-bound to the renewed certificate on CLB / CDN / WAF / TEO and friends.
• Auth that fits the deployment — shared bearer token over HTTPS for simple setups, mTLS or gRPC SDS for everything else.
• Resilient by design — clients support a standby server with automatic failover; the server keeps a local cache so restarts are cheap.

How it works

ACME CA  <----->  certdx_server  ----->  certdx_client       --(file + reload)-->  nginx / haproxy / ...
                       |                       |             --(patch secret)-->  Kubernetes TLS secrets
                       |                       +---------------(re-bind)------->  Tencent Cloud CLB / CDN / WAF / TEO
                       |          ----->  Caddy plugin        --(in-memory)----->  Caddy
                       +--------- ----->  Envoy (SDS)         --(hot reload)---->  Envoy listeners

The server is the only component talking to the ACME CA; everything else is a consumer.

Supported clients

Client	How it works
certdx client	Standalone daemon. Runs an update action per certificate: write cert/key files and run a reload command, patch annotated Kubernetes TLS secrets, or re-bind Tencent Cloud resources.
Caddy plugin	Caddy get_certificate module — certificates stay in memory, no files.
Envoy (gRPC SDS)	Envoy connects to the server's SDS endpoint directly; certificates are hot-swapped with no restart.
certdx tools	General-purpose CLI: inspect the cache, generate mTLS material, register Google ACME accounts, and more.

Quick start

Grab the latest release archive for your platform from GitHub releases, unpack it and move it into place:

tar -xzf certdx_linux_amd64.tar.gz
sudo mv certdx_linux_amd64 /opt/certdx

/opt/certdx now has certdx_server, certdx_client, certdx_tools, example configs under config/, and ready-to-use systemd units under systemd-service/. Edit config/server_config.toml and config/client_config.toml, then enable the units:

sudo cp /opt/certdx/systemd-service/certdx-server.service /etc/systemd/system/
sudo cp /opt/certdx/systemd-service/certdx-client.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now certdx-server certdx-client

Full walk-through: docs/quickstart.md.

Documentation

Quickstart	5-minute server + client setup.
Setup guide	All deployment options (mTLS, gRPC SDS, Envoy, Caddy, K8s).
Server reference	Every option in server_config.toml.
Client reference	Every option in client_config.toml.
Caddy plugin	Caddyfile syntax.
Tools	certdx_tools subcommands (cache inspection, mTLS material, ACME accounts).
Docker	The container image: contents, building, running server/client/tools.

External: DeepWiki.