CertKit vs. open-source ACME clients

Certbot is good software. But you don't want to manage it across dozens of servers.

Free ACME clients automate one thing well: renewing a certificate on the machine they run on. The comparison with CertKit is about architecture, one system that issues centrally, deploys everywhere, and verifies the result.

Start free trial See how it works

When the free ACME client is the right call

Plenty of environments don't need CertKit. A free ACME client is the right answer when:

If that is your situation, keep your setup. The rest of this page is about what changes when the certificate count grows and the server list stops fitting in one person's head.

The clients, taken one at a time

certbot

The EFF's certbot is the default because it's packaged everywhere, with web server plugins that edit configuration for you, and renewal timers out of the box. Its unit of operation is one machine. Every server needs its own install, its own configuration, and for wildcard certificates, its own DNS API credentials sitting on disk. certbot renews the certificate on that one box. It does not know whether that certificate is actually being served, and it has no answer for the other systems that might also need that certificate.

acme.sh

acme.sh runs anywhere a Linux shell runs, supports well over a hundred DNS providers, and stays out of your way. The model is the same: per-server installs, DNS provider API keys distributed to every machine that issues, and deploy hooks you write and maintain yourself. At fleet scale, that is a configuration management project written in shell.

win-acme

win-acme is the Windows answer: IIS binding discovery, certificate store integration, and a scheduled task for renewals. For IIS it is close to turnkey. Beyond IIS, Windows services like Exchange, RD Gateway, and SQL Server need custom installation scripts on each server, which is where the DIY trajectory usually begins.

Your custom renewal script

Every DIY setup eventually grows one: the script that copies certificates to the systems the client cannot reach, restarts services, and posts to Teams. It starts as 47 lines of bash, then wildcards, then monitoring, then the appliances. It runs as root, is on every critical server, and no one understands it anymore.

You built your own certificate management system

When the free path gets expensive

None of these costs show up on day one, which is why the free client wins every first evaluation. They show up as the fleet grows:

Per-server ACME clients CertKit
Issuance Each server runs its own client and credentials Centralized. One account issues for every domain
Wildcards DNS API keys stored on each issuing server One CNAME record. No DNS credentials anywhere
Appliances Manual import, or custom scripts per device The CertKit Agent pushes renewals over each device's API or CLI.
Built-in integrations.
Verification The cron job exited 0. Hopefully that means it worked Connects to the domain and confirms the renewed certificate is being served
Inventory A text file, a spreadsheet, or nobody knows Discovery from Certificate Transparency logs, plus a full audit trail
Cost Engineering time on every change Paid, with public pricing

The wildcard row deserves emphasis. DNS validation with a free client means placing DNS API credentials on servers, and one compromised credential controls your entire zone. CertKit validates through a delegated CNAME, so the worst case is a failed challenge, not a hijacked domain.

Why no DNS API

What CertKit changes

CertKit acts as one centralized ACME client for your whole infrastructure. Your servers do not run ACME, do not hold credentials, and do not open ports. The CertKit Agent makes outbound connections only, deploys each renewed certificate where it belongs, restarts the service, and CertKit then verifies the right certificate is live. No scripts, no cron jobs, no 2am alerts. Every stage of certificate lifecycle management, from one account.

Why servers shouldn't need ACME How certificate automation works

Running your own CA is a different decision

step-ca and EJBCA come up in this comparison, but they answer a different question. They are certificate authorities, not renewal automation. Choosing one means running private PKI, with root distribution to every machine and person who would otherwise hit a warning. For most internal infrastructure, publicly trusted certificates over DNS validation are the simpler path.

You probably don't need private PKI

Comparing platforms instead?

If the alternative on your desk is a Venafi, Keyfactor, or DigiCert quote rather than a free client, that comparison runs the other way: CertKit as the automation without the enterprise platform around it.

CertKit vs. enterprise CLM platforms

CertKit is an invaluable tool for administrators managing public TLS certificates in Microsoft environments like Always On VPN (SSTP) and DirectAccess (IP-HTTPS), as it simplifies and fully automates Let's Encrypt certificate issuance and renewal. CertKit eliminates the security risks and complexities of manual DNS challenges or API key exposure.

Richard Hicks, Consultant and Microsoft MVP

Pricing

Homelab

Free

Personal, non-commercial use.

Professional

$99/mo

For busy IT with no time to babysit certificates.

Business

$399/mo

For businesses with diverse IT infrastructure.

Enterprise

Contact

For corporations with complex PKI needs.

Every paid plan starts with a free 90-day trial, no credit card required. Resellers, MSPs, and system integrators can enable co-branded multi-tenant environments with volume discounts.

See pricing Book a meeting