Let's Encrypt wildcard certificates without running Certbot

The certificates are free. The plumbing is what costs you.

Let's Encrypt solved certificate cost and made automation the default. What it did not solve is the machinery around it, which lands on you: an ACME client on every host, a renewal timer per machine, DNS API credentials wherever a wildcard is involved, and no view across any of it. That arrangement holds fine on one server and frays across twenty, especially as certificate lifetimes keep shortening.

CertKit is a Let's Encrypt ACME client that runs in one place instead of on every box. No account to create, no credentials to generate, no client to install on the servers themselves. The CertKit Agent takes each renewal and installs it where the certificate is actually served.

Start free trial Watch demo

Wildcards are where per-server ACME breaks down

A wildcard certificate can only be validated with DNS-01. There is no HTTP alternative, because proving control of *.example.com means proving control of the zone rather than of a web root. That single constraint is what makes wildcards awkward to automate.

The usual answer is to give the ACME client an API token for your DNS provider so it can write and delete TXT records on demand. It works, and it means a token with write access to your DNS is now sitting on a web server, in a config file, alongside a renewal script. If that host is compromised, the blast radius is your entire zone, not one machine.

CertKit uses delegated DNS validation instead. You create one CNAME pointing the ACME challenge record at CertKit, once. CertKit answers challenges there for every future renewal, including wildcards, and never holds credentials for your DNS provider. Your zone stays yours; the only thing delegated is a single record that exists solely to answer challenges.

Running Certbot yourself, and what comes with it

The do-it-yourself version:

Install a client and the right DNS plugin on every host. Certbot, acme.sh, win-acme, or lego. For a wildcard the plugin has to match your DNS provider, so the choice is made per environment and maintained per machine.
Put DNS API credentials on the web server. DNS-01 is mandatory for wildcards, and the standard implementation means a token with write access to your zone living in a file next to a renewal script.
Write a post-deploy hook per platform. Certbot renews a file. Making that a live certificate means a reload or restart, a format conversion on Windows, and a copy step for anything that isn't the local machine. The hook runs only at renewal, which is the worst time to discover it has a typo.
Solve the hosts that can't run a client. A load balancer, a firewall, or a mail appliance has no shell to run Certbot in. Those get a bespoke push script or a diary entry.
Build your own monitoring, because there is none. Let's Encrypt ended its expiration notification emails in June 2025, so nothing external warns you any more. A timer that stopped firing looks exactly like one that is working until the browser warning appears.
Reconstruct an audit trail when someone asks. What was issued, for which names, installed where, and when. That lives in per-host logs that rotate away.

None of this is Certbot's fault; it does the job it was designed for on the machine it runs on. The work above is everything outside that scope, and it grows with the number of hosts rather than the number of certificates. With 47-day certificates coming by 2029, the window between "renewal broke" and "site is down" gets shorter every year. Compare CertKit to certbot, acme.sh, and win-acme.

At 47 days, hand-tended Certbot stops being viable. Here's how CertKit automates Let's Encrypt end to end.

How it works

 Let's Encrypt            CertKit              Your systems
┌──────────────┐   ┌─────────────────┐   ┌──────────────────┐
│              │   │  no account,    │   │                  │
│  ACME  ◄─────────── no EAB, no     │   │  ┌─────────────┐ │
│  directory   │   │  client on the  │   │  │CertKit Agent│ │
│      │       │   │  servers        │   │  └──────┬──────┘ │
│      ▼       │   │                 │   │         │        │
│  Certificate ───►│  Renew on time  │   │         ▼        │
│  *.example   │   │       │         │   │  nginx    [x]    │
│              │   │       ▼         │   │  IIS      [x]    │
│              │   │  Deploy ───────────►│  F5       [x]    │
└──────────────┘   └─────────────────┘   └──────────────────┘
   DNS-01 via         one CNAME,            deployed and
   delegation         no DNS tokens          verified

Let's Encrypt is built into CertKit and ready to use, so there is nothing to configure before issuing your first certificate. Renewals run on a schedule CertKit holds centrally, with enough margin that a failed attempt retries long before the expiry date.

CertKit makes what many companies struggle with much easier to manage while at the same time providing great value compared to the traditional vendors in the space.

Ben Story, Managed Services Director, RedEye Network Solutions

What CertKit handles

Issue immediately, with no account setup. Let's Encrypt is the built-in issuer. Unlike commercial CAs there are no External Account Binding credentials to generate, so the first certificate is minutes away.
Wildcards without DNS API credentials. One delegated CNAME covers every wildcard renewal, and no DNS provider token is stored anywhere.
No ACME client on your servers. Nothing to install, patch, or debug per host. The agent receives certificates; it does not negotiate for them.
Deploy to things that cannot run Certbot. Appliances, load balancers, Windows services, and mail servers take the certificate through the agent instead of an ACME client.
Renew early, then verify. Every renewal is followed by a TLS connection to the endpoint, confirming the new certificate is the one actually being served.
Alert when a renewal fails. The failure mode of a per-server timer is silence. CertKit raises the failure while there is still time to fix it.
Keep the history. Every issuance, renewal, and deployment recorded, across every host, in one place. At the cadence 47-day certificates impose, that record is the only thing that can answer what was running when.

Setup takes about five minutes

Add your domain. No issuer configuration. Let's Encrypt is available on every account from the start.
Delegate validation with one CNAME. A single record per domain, which covers wildcards and every renewal from then on.
Install the CertKit Agent and pick a template. One command per target system, then choose the deployment template for that platform.

See the issuer documentation →

Let's Encrypt is one issuer among several

CertKit issues from Let's Encrypt alongside Google Trust Services, ZeroSSL, Sectigo, DigiCert, GoDaddy, GlobalSign, and Actalis, and from a private CA for internal hostnames and mTLS client certificates that no public CA will sign. Monitoring covers all of them from one inventory.

See all integrations

Start automating Let's Encrypt 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