Homelab
Personal, non-commercial use.
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.
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 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 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 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.
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.
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.
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
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.
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 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
Personal, non-commercial use.
For busy IT with no time to babysit certificates.
For businesses with diverse IT infrastructure.
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.
Sign up, connect your domains with one CNAME, and watch certificates issue, deploy, and verify on their own. Free 90-day trial, no credit card required, with direct access to our engineering team to get you set up.
Not ready? See every certificate CertKit finds on your domains, free.