ZeroSSL ACME automation without per-server clients

ZeroSSL will issue the certificates. Getting them installed is on you.

ZeroSSL does the issuance side properly: External Account Binding credentials, a standard ACME directory, 90-day certificates out the other end. What it does not do is put those certificates onto the machines that serve them, or tell you when one of them quietly stopped arriving.

CertKit covers both. It holds your ZeroSSL EAB credentials, tracks every certificate's expiry itself, renews with enough margin to absorb a failure, and the CertKit Agent installs each renewal across your servers and appliances, then verifies it is live. That matters more every year: as certificate lifetimes keep getting shorter, the same work runs roughly twelve times a year instead of six.

Start free trial Watch demo

Where all those ZeroSSL certificates came from

ZeroSSL is unusual among commercial certificate authorities: it is the default CA of acme.sh, and has been since 2021. That means estates accumulate ZeroSSL certificates one server at a time, each install registering its own ACME account with whatever contact email was configured that day, without a deliberate CA decision ever being made.

The consequence shows up later. The certificates are real and trusted either way, but the view of them is scattered across whatever registrations each host created, and even where the dashboard shows a certificate, it cannot say where that certificate is actually installed. The first complete inventory most teams see is the expiry warning.

CertKit issues through the EAB credentials of your ZeroSSL account, so every certificate lands under one registration on ZeroSSL's side and one inventory on CertKit's, with the deployment target recorded for each. Certificates from the old per-host installs are replaced at their next renewal, which at 90-day lifetimes is never far away.

Wiring up ZeroSSL ACME by hand

The do-it-yourself version, once you have EAB credentials:

Install and configure a client per host. acme.sh is the common choice with ZeroSSL, and it works well. It also has to be installed, pinned, and upgraded on every machine, and its cron entry is the only thing standing between you and an expiry.
Register each client with your EAB credentials. One ACME account registration per client, each holding a copy of the Key ID and HMAC from your ZeroSSL dashboard.
Pin a renewal offset on every client, and keep them in step. Each client renews on whatever fixed offset you configured. Set it too tight and a failed attempt has no room to retry; set it loose and you reissue more than you need to. Either way the number lives in a config file per host, and the hosts drift apart over time.
Write post-deploy hooks for every platform. Convert, place, reference, reload. Once per platform, run only at renewal, and silently broken in between.
Handle what has no shell. Load balancers and appliances import certificates through an API or a UI that no ACME client drives.
Build the monitoring and the log. Something has to check the served certificate on each endpoint and keep a record of what was installed where. Neither comes with the client.

None of that is exotic; it is just work that grows with the number of hosts rather than the number of certificates. As certificate lifetimes fall toward 47 days and renewals run roughly twelve times a year, the margin for a stale offset on one forgotten host disappears.

At 47 days, nobody keeps twenty renewal offsets in step by hand. Here's how CertKit runs ZeroSSL instead.

How it works

   ZeroSSL               CertKit             Your systems
┌──────────────┐   ┌─────────────────┐   ┌──────────────────┐
│              │   │                 │   │                  │
│  ACME  ◄─────────── EAB creds      │   │  ┌─────────────┐ │
│              │   │  (stored once)  │   │  │CertKit Agent│ │
│      │ issues│   │                 │   │  └──────┬──────┘ │
│      ▼       │   │  CertKit owns   │   │         │        │
│  Certificate ───►│  the schedule   │   │         ▼        │
│              │   │  and the retry  │   │  nginx    [x]    │
│              │   │       ▼         │   │  Apache   [x]    │
│              │   │  Deploy ───────────►│  Docker   [x]    │
└──────────────┘   └─────────────────┘   └──────────────────┘
   one registration,   one CNAME             deployed and
   not one per host    delegation              verified

One registration against ZeroSSL, one place holding the configuration, and nothing to install on the servers themselves. Validation runs through one delegated CNAME, which also means wildcard certificates work without handing over DNS API credentials.

Using CertKit to manage our public-facing SSL certificates has been an excellent decision. The platform is user-friendly, certificates are easy to deploy, and the automation agent streamlines the entire certificate lifecycle, eliminating concerns around shortening certificate validity periods.

Chris Austin, IT Engineer, Buckman

What CertKit handles

Keep one renewal schedule, not twenty. Per-certificate expiry tracking with enough margin that a failed attempt has room to retry, held centrally instead of pinned into a config file on each host.
Alert on renewal failure, not on expiry. A renewal that did not happen raises an alert while there is still time to act, which is the failure mode a cron job cannot report on.
Hold EAB credentials once. Not copied onto every host that needs a certificate.
Issue wildcards without DNS API access. Delegated CNAME validation covers wildcard names, so no DNS provider token is required.
Deploy and reload. The CertKit Agent installs each renewal in the format the platform expects and restarts or reloads what needs it, including appliances that cannot run an ACME client.
Verify the certificate on the wire. A TLS connection after each deployment, checking serial, names, and expiry.
Keep a record of every cycle. Each renewal and install is logged, so a certificate's whole history is reconstructable rather than inferred from whatever is currently on disk. At the renewal frequency the industry is moving to, that history is the only practical audit trail.

Setup takes about ten minutes

Delegate validation with one CNAME. One record per domain, added once, covering wildcards too.
Get your EAB credentials from ZeroSSL. Sign in to ZeroSSL and open the Developer section of your dashboard to generate the EAB Key ID and HMAC.
Add ZeroSSL as an issuer in CertKit. Paste the Key ID and HMAC alongside a name and contact address, and the issuer goes live once it registers.
Put the agent on each target. A single install command, then choose the platform's deployment template.

See the issuer documentation →

Why not point acme.sh at ZeroSSL?

Plenty of people do, and for a single host it is a reasonable arrangement. The strain shows up at the second and third machine, because each one needs its own copy of the EAB credentials, its own timer, and its own idea of when to renew. Nothing has a view across them, so a client that quietly stopped renewing in March announces itself as an outage in June.

It also cannot reach anything that will not run a shell script. A load balancer or a firewall takes its certificate through an API or a web UI, which is not something a per-server ACME client was built to do.

CertKit runs the ACME side once, centrally, against your ZeroSSL account, and treats deployment as its own problem with its own verification. Compare CertKit to acme.sh, certbot, and win-acme.

ZeroSSL is one issuer among several

CertKit is not tied to any one certificate authority. It issues from ZeroSSL alongside Sectigo, DigiCert, GoDaddy, GlobalSign, Actalis, Google Trust Services, and Let's Encrypt, and from a private CA for the internal names no public CA will sign. Monitoring covers every certificate regardless of who issued it.

See all integrations

Start automating ZeroSSL certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing