Automated certificate renewal with Sectigo ACME

How to run Sectigo ACME yourself

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

1. Put an ACME client on every host that terminates TLS. certbot, acme.sh, win-acme, or lego, each installed, configured, and patched separately. The client is the easy part; keeping twenty of them at the same version is not.
2. Copy your Sectigo EAB credentials onto each one. Every client registers its own ACME account against your Sectigo account, which means the Key ID and HMAC end up in a config file on each machine. Rotating them later means visiting all of them.
3. Write a post-deploy hook per platform. Issuance gives you files. Something still has to convert to the format that platform wants, move them into place, update the binding, and reload the service without dropping connections. Each hook is bespoke, and it only gets exercised on renewal, which is exactly when you find out it was broken.
4. Solve the targets that can't run a client at all. A load balancer, a firewall, or a mail appliance takes its certificate through an API or a web UI. No ACME client covers that, so those become a scripted special case or a calendar reminder.
5. Build monitoring, because success is not the default signal. A client that stops renewing does not announce it. You need something checking what is actually being served on each endpoint, not just whether the last cron run exited zero.
6. Assemble an audit trail from scattered logs. Which certificate went where, when, and who changed it, gathered from per-host logs that rotate away.

ACME solved issuance. Everything on that list is fleet management, which it was never meant to touch. With 47-day certificates arriving by 2029, every one of those moving parts runs roughly twelve times a year, and the failure mode is a silent one: a hook that stopped working on the third server behind the load balancer, discovered when the certificate expires.

Twelve renewals a year per certificate is not a workload to run by hand. Here's how CertKit runs it from your Sectigo account.

Setup takes about ten minutes

1. Delegate validation with one CNAME. Point a CNAME record at CertKit once per domain. Every renewal after that validates without another DNS change.
2. Get your EAB credentials from Sectigo. In the Sectigo Certificate Manager dashboard, go to Enrollment › ACME and copy the Key Identifier (KID) and HMAC key for your ACME account.
3. Add Sectigo as an issuer in CertKit. Enter a friendly name, the account email, and the EAB Key ID and HMAC. The issuer is available to every collection on the account once it validates.
4. Install the CertKit Agent and pick a template. One command on each target system, then choose the pre-built deployment template for that platform. CertKit runs it on every renewal.

See the issuer documentation →

Why not run ACME against Sectigo directly?

You can. An ACME client on each server, pointed at Sectigo with EAB credentials, will issue and renew certificates. The problem is what that arrangement becomes at scale: the same EAB credentials copied onto every machine, a renewal timer per host to monitor, and a client that only knows about the one certificate on the one server it runs on. Nothing has a view of whether all of them succeeded.

It also does not solve deployment anywhere the ACME client can't run. A load balancer, a firewall, or a mail server needs the certificate imported through an API or a UI, which is the step per-server ACME was never designed to do.

CertKit separates the two: issuance happens once, centrally, against your Sectigo account, and deployment happens wherever the certificate is actually needed. Compare CertKit to certbot and win-acme.