ACME client comparison 2027: certbot, acme.sh, cert-manager for 100-day certs

Summary. For 100-day public certificates from 15 March 2027, and Let's Encrypt's 64-day default from 10 February 2027, the ACME client matters less than two features: ACME Renewal Information (ARI, RFC 9773), which lets the CA tell your client when to renew, and ACME profiles, which let you choose a certificate type. As of 1 November 2026, certbot 5.9.0 (28 October 2026) checks ARI automatically and has supported profiles since 4.0.0. acme.sh 3.1.6 (20 September 2026) has had ARI on by default since 3.1.4. Caddy 2.11.7 (3 October 2026) gets full RFC 9773 support from CertMagic, with profiles marked experimental. cert-manager 1.21 supports profiles but keeps ARI behind the experimental ACMEUseARI gate, and v1.21.3 fixed an ARI renewal loop. Traefik 3.7.17 has an acme.profile option, but neither its documentation nor its ACME provider code shows ARI. On Windows, Posh-ACME 4.35.0 covers ARI, profiles and experimental dns-persist-01, while win-acme 2.2.9.1 (May 2024) has pre-RFC ARI and a 55-day renewal default you should lower. Pick by platform: certbot for single Linux servers, cert-manager for Kubernetes, Caddy for new front ends, Posh-ACME or win-acme for Windows.

About this article. For DevOps, SRE and Windows teams choosing or upgrading an ACME client. On 1 November 2026 we read each project's release notes, changelog and documentation, and in places its source code, and checked the snippets against them. We did not run hands-on tests of these tools. Projects ship often, so re-check before you commit. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

This is the tool comparison. For the CA/Browser Forum rule itself, the inventory method and the eMudhra lessons, read our 100-day SSL certificate validity checklist. For the Let's Encrypt timeline, see Let's Encrypt's move to 64-day certificates.

What changed for ACME clients in 2025 and 2026

Six changes set the bar any client now has to clear.

1. ARI became a standard. The IETF published ACME Renewal Information as RFC 9773 in June 2025. A client that supports it asks the CA for a suggested renewal window for each certificate, so the CA can spread load and pull renewals forward before a mass revocation.

1. Lifetimes are falling on a fixed schedule. Public TLS certificates are capped at 200 days today, 100 days from 15 March 2027 and 47 days from 15 March 2029, under ballot SC-081v3. Let's Encrypt's default profile moves to 64 days on 10 February 2027 and 45 days on 16 February 2028, and it recommends ARI.

1. Profiles arrived. Let's Encrypt now offers classic (the default), tlsserver (45 days since 13 May 2026) and shortlived (160 hours, and the only profile allowed for IP address certificates). A client that cannot request a profile gets the default.

1. A persistent DNS challenge was approved, but rollout is uneven. Ballot SC-088v3 added a validation method based on a standing _validation-persist TXT record. Google Trust Services went live on 28 September 2026 using IETF draft 01. Let's Encrypt targeted Q2 2026, then a developer there said on 25 June 2026 that deployment would wait for an open draft issue. That issue closed on 23 September 2026, and we found no production date on 1 November 2026. Posh-ACME's guide says draft 02 uses a record format incompatible with draft 01.

1. CAA account binding becomes universal on 15 March 2027. Every CA must then process the accounturi and validationmethods CAA parameters, so a client that silently creates a new ACME account can break issuance.

1. Trust stores turned out to matter. After eight eMudhra intermediate keys were found to be weak in October 2026, The Hacker News reported fixes across Go, Node.js and Linux distributions, and cert-manager v1.21.3 removed the emSign ECC Root CA - G3 root from its base images.

certbot

certbot is the EFF's client and the one many Linux users meet first. The current release is 5.9.0, dated 28 October 2026, under the Apache-2.0 licence.

• ARI: since 4.1.0 (10 June 2025), certbot renew checks ARI automatically when the CA supports it and may renew early. Version 5.0.0 stores the server's Retry-After so it is respected across runs.

• Profiles: --preferred-profile and --required-profile arrived in 4.0.0 (7 April 2025), and 4.1.0 saves the choice in the renewal configuration.

• Renewal timing: since 4.0.0, certificates renew with one-third of their lifetime left (half if the lifetime is under 10 days), replacing the old fixed 30 days before expiry. An early ARI window overrides a later renew_before_expiry.

• IP certificates: --ip-address arrived in 5.3.0 and webroot support in 5.4.0.

• DNS-01: 13 first-party certbot-dns-* plugins (Cloudflare, Route 53, Google, DigitalOcean, OVH, RFC 2136 and others), plus third-party plugins its docs list for Azure, GoDaddy, Hetzner and more.

• Limits: certbot stopped publishing its Windows beta installer in 2.10.0 (April 2024). No release supports dns-persist-01 yet; a pull request opened in October 2026 was still open on 1 November.

Best for: Linux servers running Apache or NGINX where you want a packaged, widely documented client with ARI on by default.

acme.sh

acme.sh is a single shell script with no Python dependency, GPLv3-licensed and officially maintained by ZeroSSL. The latest release is 3.1.6, dated 20 September 2026; it adds signed release tags and no functional change from 3.1.5.

• ARI: 3.1.4 (17 July 2026) added RFC 9773 support enabled by default, and the installed cron job now runs every six hours to react to renewal windows. Set NO_ARI=1 to disable it.

• Profiles and IP certificates: supported since 3.1.2 (November 2025).

• dns-persist-01: supported since 3.1.4, with --make-dns-persist-value to print the record, an optional wildcard policy and --dns-persist-days for an expiry. The README cites draft 01.

• DNS-01: the widest built-in coverage here outside lego, with about 200 DNS API scripts, plus a DNS alias mode for delegating _acme-challenge. Each release adds providers; 3.1.5 added eight.

• Renewal timing: every 30 days by default, or earlier when the CA's ARI window opens. An explicit --days or --valid-to outranks ARI.

• Gotcha: the default CA is ZeroSSL, not Let's Encrypt. Teams that want Let's Encrypt should run acme.sh --set-default-ca --server letsencrypt first.

Best for: minimal systems, routers, NAS boxes, BSD and appliances, and teams with an unusual DNS provider.

cert-manager

cert-manager is the CNCF project for certificates in Kubernetes and OpenShift, under Apache-2.0. Supported releases are 1.21 (8 July 2026) and 1.20 (10 March 2026), with 1.22 expected around November 2026. Version 1.21 supports Kubernetes 1.33 to 1.36. See our Kubernetes 1.36 upgrade notes if a cluster needs to move first.

• ARI: experimental in 1.21, behind the ACMEUseARI feature gate. Patch v1.21.3 (23 October 2026) added status.acme.ari.certID to fix a loop where a stale ARI window from the previous certificate triggered repeated re-issuance until the CA's rate limit was hit.

• Profiles: since 1.18 (June 2025), via the profile field on an Issuer or ClusterIssuer.

• DNS-01: eight built-in providers (ACMEDNS, Akamai, AzureDNS, Cloudflare, DigitalOcean, Google Cloud DNS, RFC 2136 and Route 53) and a webhook interface for the rest. The docs do not mention dns-persist-01.

• Renewal timing: two-thirds of the issued lifetime by default, with renewBefore and renewBeforePercentage overrides. 1.21 adds a renewal field for maintenance-window scheduling.

• Accounts: each Issuer generates its own ACME account key unless you set disableAccountKeyGeneration and supply an existing one. That matters once CAA accounturi binding is in force.

            # cert-manager 1.18+: request Let's Encrypt's tlsserver profile
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    profile: tlsserver
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - dns01:
        route53: {}
          

            # Helm values, cert-manager 1.21.3+: enable experimental ARI (try staging first)
featureGates: "ACMEUseARI=true"
          

Best for: anything running in Kubernetes. Upgrade to v1.21.3 or later before relying on ARI.

Caddy (built-in ACME)

Caddy is a web server and reverse proxy that obtains and renews certificates automatically, under Apache-2.0, and describes itself as a project of ZeroSSL. The latest release we found is 2.11.7 (3 October 2026). Its TLS automation comes from the CertMagic library, which documents full support for RFC 9773.

• ARI: yes, through CertMagic.

• Profiles: added in 2.10 (April 2025) and labelled experimental.

• Renewal timing: one-third of lifetime left by default, unless the CA's ARI window says otherwise.

• Issuer fallback: by default Caddy tries Let's Encrypt, then ZeroSSL, then backs off and retries for up to 30 days. We found no other tool here documenting failover between CAs by default.

• DNS-01: through provider plugins from the caddy-dns repositories, so you need a build that includes yours, plus credentials for your provider.

• On-demand TLS: obtains certificates at the first TLS handshake for names you approve through an ask endpoint, which suits SaaS platforms serving customer domains.

Best for: new web front ends, reverse proxies and multi-tenant platforms where certificate handling should be invisible.

Traefik (built-in ACME)

Traefik is a reverse proxy and ingress controller under the MIT licence. The latest stable release is 3.7.17 (30 October 2026), with 3.8.0-rc.1 in testing. It embeds the lego library, whose documentation lists more than 200 DNS providers and which supports RFC 9773, profiles and draft dns-persist-01 as a standalone client.

• Profiles: the ACME resolver reference includes an acme.profile option.

• ARI: the resolver documentation does not mention it, and we found no ARI call in the ACME provider source on 1 November 2026, although lego itself supports it.

• Renewal timing: by default Traefik assumes 90-day certificates and starts renewing 30 days before expiry. The code picks the window from certificatesDuration, in hours: 90 days or more renews 30 days before expiry, 30 to 89 days renews 10 days before, and 6 to 29 days renews 2 days before. So the default keeps working on 64-day and 45-day certificates, renewing at about day 34 and day 15. Setting 1,536 hours for a 64-day certificate narrows your margin to 10 days. Set 160 for shortlived, because the default would treat a six-day certificate as always due.

• DNS-01: one DNS provider per resolver. Traefik's docs suggest CNAME delegation when domains sit with different providers.

Best for: teams already using Traefik as their proxy or ingress who accept fixed renewal timing until ARI arrives.

NGINX has also gained native ACME support, announced in September 2025 according to Let's Encrypt, which may remove the need for a separate client on some NGINX hosts.

Windows: win-acme and Posh-ACME

certbot no longer ships a Windows installer, so Windows estates usually pick one of these two. Our Windows Server 2016 migration options cover the wider upgrade.

win-acme (Apache-2.0) is the GUI-and-CLI client most IIS administrators know. The recommended download on win-acme.com is 2.2.9.1, and its latest GitHub release, v2.2.9.1701, dates from 25 May 2024. Those release notes describe moving ARI support to draft 3 of the specification, which predates RFC 9773. It installs into IIS, the Windows certificate store, the IIS Central Certificate Store, PEM or PFX files and Azure Key Vault, and lists about 20 DNS plugins plus acme-dns and script hooks. Its CLI reference shows no profile option. The setting that matters is RenewalDays, default 55: fine for 90-day certificates, tight for 64-day ones (9 days of margin), and longer than a 45-day certificate. A RenewalMinimumValidDays safety net (default 7) and ARI suggestions, on unless you set RenewalDisableServerSchedule, soften this. We would still set RenewalDays to 30 now: that is 47% of a 64-day lifetime and 67% of a 45-day one.

Posh-ACME (MIT) is a PowerShell module that runs on Windows PowerShell 5.1 and PowerShell 6.2 or later on all supported platforms. Version 4.35.0 is dated 11 October 2026. It added ARI in 4.24.0 (June 2024), with a DisableARI switch per server, profiles in 4.28.0 (February 2025), preliminary dns-persist-01 in 4.32.0 (March 2026), and draft 02 support with new pre-provisioning workflows in 4.35.0. Its README cites ARI draft 07 and also lists experimental dns-account-01.

Best for: win-acme when IIS administrators want an interactive tool; Posh-ACME when Windows automation lives in PowerShell pipelines or you want to trial dns-persist-01 on Windows.

Head-to-head comparison

The table summarises the sections above, using the same sources. Not documented means we found no mention, not that the feature is absent.

Worked example: renewal load in a mixed estate

Take an illustrative estate on Let's Encrypt: 40 Linux VMs with certbot (one certificate each), two Kubernetes clusters with 300 certificates managed by cert-manager, and 15 IIS servers with win-acme. That is 355 certificates, and we assume two names per certificate and renewal at two-thirds of the lifetime.

The arithmetic: 365 ÷ (64 × 2/3) ≈ 8.555 renewals per certificate per year; 355 × 8.555 ≈ 3,037; doubled for two names, 6,074 TXT records created (and as many deleted). Authorisation reuse falls to 10 days in February 2027 and seven hours in 2028, so these renewals all need fresh validation, as they already do on a 60-day cycle with 30-day reuse.

Three conclusions follow:

• Rate limits are not the constraint. Let's Encrypt says renewals are exempt from its issuance limits.

• DNS credentials are. Thousands of DNS API writes a year means API tokens on many machines. Use narrowly scoped tokens or delegate _acme-challenge to a dedicated zone. Consider dns-persist-01 once your CA and client both support it.

• Defaults need checking. certbot's one-third rule is safe here. win-acme's 55-day default needs lowering to 30.

India and data-residency notes

ACME clients generate private keys on your own machines and send the CA only a certificate signing request, so the private key stays on your infrastructure whichever CA you use. Let's Encrypt stopped sending expiry reminders in June 2025, so do not rely on an account email. After the October 2026 eMudhra incident, CERT-In's advisory CIAD-2026-0050 told administrators to review applications, runtimes, container images and appliances that carry their own CA bundles. ACME clients are themselves TLS clients that talk to the CA, so keep them, and the images they run in, current. A client that can switch CAs by changing one setting, as all seven here can, turns a distrust event into a configuration change.

Implementation checklist

1. Inventory clients and versions. Upgrade certbot to 4.1.0 or later (ideally 5.9.0), acme.sh to 3.1.4 or later, cert-manager to v1.21.3 (v1.20.5 on the 1.20 line, which lacks ARI), and Posh-ACME to 4.35.0.

1. Confirm ARI is active where supported. Look for an acme_renewal_info section in the certbot renewal configuration, run acme.sh --info -d example.com and read Le_NextRenewTimeStr, and test the ACMEUseARI gate in cert-manager staging.

1. Remove fixed day counts. Search cron jobs and scripts for 83, 80 and 60, as Let's Encrypt suggests. Set win-acme RenewalDays to 30, and set Traefik certificatesDuration only for profiles that need it.

1. Choose profiles deliberately. Stay on classic for the 10 February change, or opt into tlsserver early on services with mature automation. Use shortlived in staging to flush out timing bugs.

1. Set the CA explicitly, above all in acme.sh and Caddy.

1. Stabilise ACME account keys before adding CAA accounturi binding. In cert-manager, reuse one account across clusters with disableAccountKeyGeneration.

1. Lock down DNS-01 with scoped tokens or CNAME delegation.

1. Wire deploy hooks and verification. Reload services, push to load balancers, then check the served certificate's expiry date from outside.

1. Alert externally at 14, 7 and 3 days before expiry, and watch Certificate Transparency for unexpected issuance.

1. Rehearse a CA switch on one service before 15 March 2027.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our DevOps services team can standardise certificate automation across Linux, Kubernetes and Windows estates, with ARI, scoped DNS credentials, deploy hooks and external expiry monitoring. Talk to us at /contact-us/.

Last updated: 1 November 2026.

References

1. Certbot change log — Electronic Frontier Foundation

1. acme.sh releases, 3.1.2 to 3.1.6 — acme.sh project

1. Caddy releases, including v2.10.0 and v2.11.7 — Caddy project

1. CertMagic README: RFC 9773 support — Caddy project

1. Release notes 1.21, including v1.21.3 — cert-manager

1. ACME certificate resolver reference — Traefik

1. ACME provider source, provider.go, v3.7 branch, read 1 November 2026 — Traefik

1. Posh-ACME change log, 4.35.0 and earlier — Posh-ACME project

1. win-acme releases, v2.2.9.1701, 25 May 2024 — win-acme project

1. settings.json reference: RenewalDays — win-acme project

1. RFC 9773: ACME Renewal Information (ARI) Extension, June 2025 — RFC Editor

1. Baseline Requirements for Publicly-Trusted TLS Server Certificates, version 2.3.1, 4 October 2026 — CA/Browser Forum

1. 64-Day Certificate Lifetimes Coming Feb 2027, 7 October 2026 — Let's Encrypt

1. Decreasing Certificate Lifetimes to 45 Days, 2 December 2025 — Let's Encrypt

1. Profiles, last updated 4 October 2026 — Let's Encrypt

1. Ballot SC-088v3: DNS TXT Record with Persistent Value DCV Method, 9 October 2025 — CA/Browser Forum

1. Google Trust Services Supports ACME DNS-PERSIST-01 Challenge, 28 September 2026 — Google

1. DNS-PERSIST-01: A New Model for DNS-based Challenge Validation, 18 February 2026 — Let's Encrypt

1. Dns-persist-01 deployment status and timeline, staff reply of 25 June 2026 — Let's Encrypt Community Support

1. Issue 64: Record should include client-computed information, closed 23 September 2026 — IETF ACME working group draft repository

1. Using Persistent DNS Challenges, note dated October 2026 — Posh-ACME project

1. Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software, October 2026 — The Hacker News

1. Six-Day and IP Address Certificates Available in Certbot, 11 March 2026 — Let's Encrypt

1. User guide: DNS plugins and renewal — Certbot

1. Pull request 10798: add support for DNS-PERSIST-01, opened 7 October 2026 — Certbot

1. acme.sh README: ARI, DNS persist mode and supported CAs — acme.sh project

1. Supported releases — cert-manager

1. Release notes 1.18: ACME certificate profiles — cert-manager

1. ACME issuer configuration — cert-manager

1. DNS01 configuration: supported providers — cert-manager

1. Certificate resources — cert-manager

1. Caddy README — Caddy project

1. Caddyfile tls directive: profile and renewal_window_ratio — Caddy

1. Automatic HTTPS — Caddy

1. Traefik releases, v3.7.17 and v3.8.0-rc.1, 30 October 2026 — Traefik

1. lego documentation: supported RFCs and DNS providers — lego project

1. Native ACME Support Comes to NGINX, 11 September 2025 — Let's Encrypt

1. win-acme home page — win-acme project

1. DNS validation plugins — win-acme project

1. Command line reference — win-acme project

1. Posh-ACME README — Posh-ACME project

1. Shorter Certificate Lifetimes and Rate Limits, 24 February 2026 — Let's Encrypt

1. Expiration Notification Service Has Ended, 26 June 2025 — Let's Encrypt

1. Advisory CIAD-2026-0050: Compromise of eMudhra Intermediate CA Certificates, 21 October 2026 — CERT-In

1. renewal.py: ACME Renewal Info handling, read 1 November 2026 — Certbot