DigiCert ACME automation, from issuance to deployment

What DigiCert ACME leaves you to build

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

1. Roll out an ACME client across the estate. One per host, each with its own version, its own config, and its own failure modes. In a mixed environment that means certbot on the Linux boxes and win-acme on the Windows ones, which is two rollouts and two sets of behaviour to learn.
2. Distribute the EAB credentials. Each client registers separately against your DigiCert account, so the Key ID and HMAC land in a config file on every machine that needs a certificate. That is a credential with issuing authority, sitting on your web tier.
3. Write and maintain the post-deploy hooks. The client hands you PEM files. Turning that into a working service means a format conversion, a file move, a config update, and a graceful reload, written once per platform and executed only at renewal, when nobody is watching.
4. Handle the appliances separately. An F5, a firewall, or a mail gateway imports certificates through an API. No ACME client speaks that, so those either get a bespoke script or stay manual, and they tend to be the systems where an expiry is most visible.
5. Add monitoring that checks the wire, not the exit code. A renewal marked successful is not proof the new certificate is being served. Without an external check you learn the difference from a customer.
6. Keep an inventory that survives a bad day. When a CA has to revoke inside 24 hours, the question is which of your hosts hold an affected certificate. Per-server logs do not answer that quickly.

Each item is tractable alone. Together they are a certificate management system, built incidentally, maintained by whoever happens to still be around. With 47-day certificates arriving by 2029, all of it runs roughly twelve times a year, and the last two items stop being nice-to-haves the first time a mass reissue lands on you.

At 47-day lifetimes, that list becomes a monthly cycle. Here's how CertKit takes it over for your DigiCert estate.

Setup takes about ten minutes

1. Delegate validation with one CNAME. A single record per domain, added once. Renewals validate against it from then on.
2. Retrieve your EAB credentials from DigiCert. Sign in to your DigiCert account and choose Automation › ACME Directory URLs to get the Key ID and HMAC for your ACME account.
3. Add DigiCert as an issuer in CertKit. Friendly name, account email, EAB Key ID, and HMAC. Once validated the issuer is available to every collection on the account.
4. Install the CertKit Agent and choose a template. One command per target system, then pick the pre-built deployment template for that platform. It runs on every renewal from then on.

See the issuer documentation →

Why not automate inside the DigiCert console?

DigiCert automates ordering and reissue well, which makes sense: it is the CA's own console, and issuance is the part the CA controls. The boundary is your infrastructure. It does not hold credentials for your F5, does not know which of your servers terminates which hostname, and cannot restart your services.

That boundary also binds you to one CA. Certificates ordered, tracked, and automated inside a CA's console are portable in theory and painful to move in practice, which matters most in exactly the situations where you would want to move.

CertKit sits above the CA instead of inside it. DigiCert issues, CertKit deploys, and the issuer is a setting rather than a migration. See how CertKit compares to DigiCert Trust Lifecycle Manager and other enterprise CLM platforms.