Which ACME client should I choose?
How to choose between DigiCert managed automation and third-party ACME clients for Windows, Linux, Kubernetes, and enterprise infrastructure.
ACME (Automated Certificate Management Environment) is an open protocol for automating certificate enrollment and renewal. DigiCert Trust Lifecycle Manager supports ACME automation with compliant third-party ACME v2 clients, but choosing an automation approach is more than choosing a client. You also need to decide who should own installation, binding, validation, renewal, monitoring, and operational support in your environment.
DigiCert managed automation or a third-party ACME client?
DigiCert managed automation uses DigiCert Agents for supported Windows and Linux server applications and DigiCert Sensors for supported network appliances, cloud services, and vaults. Trust Lifecycle Manager provides centralized orchestration, status tracking, inventory context, and deployment validation for these managed workflows.
Third-party ACME automation uses an ACME client such as Certbot, Posh-ACME, win-acme, acme.sh, or cert-manager. The client runs on or in the target platform, connects to the DigiCert ACME service using the ACME Directory URL and External Account Binding (EAB) credentials, and handles the client-side workflow configured by the operator.
Note: A DigiCert Agent is not simply another third-party ACME client. For supported server automation, the DigiCert Agent uses the ACME protocol as part of Trust Lifecycle Manager's managed automation workflow, including certificate installation and endpoint testing.
When a third-party ACME client is a good fit
- The target platform already has a mature ACME client or controller that your team operates.
- You want certificate automation to remain inside an existing Linux, Windows, Kubernetes, or DevOps workflow.
- Your team is prepared to own client configuration, software updates, credential protection, deployment logic, and troubleshooting.
- The client supports the ACME v2 capabilities your DigiCert profile requires, including External Account Binding (EAB).
- You have a reliable way to verify that renewal resulted in the new certificate being installed and actively presented by the service.
Common third-party ACME client options
Certbot for common Linux web-server workflows
Certbot is a widely used open-source ACME client produced by the Electronic Frontier Foundation (EFF). Its current official support focuses on major Linux and BSD variants. On supported systems, plugins can integrate certificate issuance and renewal with web servers such as Apache and NGINX.
Choose Certbot when:
- You operate supported Linux or BSD systems.
- You use Apache or NGINX and want a well-established client with web-server integration options.
- Your team is comfortable operating and supporting open-source software.
- You can automate the required ACME challenge method and post-renewal deployment behavior.
DigiCert compatibility note: DigiCert documentation provides Certbot examples for Trust Lifecycle Manager. Client-specific configuration and troubleshooting remain dependent on the Certbot implementation and your environment.
Posh-ACME for Microsoft PowerShell-centric automation environments
Posh-ACME is an open-source PowerShell ACME client with support for ACME v2, External Account Binding, multiple challenge plugins, and automated renewals. It runs on Windows PowerShell and on supported versions of PowerShell Core. For Windows service deployment such as IIS, the companion Posh-ACME.Deploy module provides deployment functions.
Choose Posh-ACME when:
- Your automation standards are PowerShell-centric.
- You want scriptable control over enrollment, challenge handling, renewal, and deployment steps.
- You need a client that supports EAB and can be integrated into broader Windows automation.
- You are comfortable validating and maintaining the deployment scripts or companion modules used after issuance.
win-acme for Windows and IIS
win-acme is an ACME v2 client for Windows designed to support both simple interactive setup and unattended operation. Its IIS workflow can derive certificate identifiers from site bindings, obtain the certificate, update IIS bindings, and create a scheduled renewal task. The project also supports more advanced validation, storage, and deployment options.
Choose win-acme when:
- You manage Windows servers, especially IIS.
- You want an interactive setup path but also need unattended renewals.
- You want the ACME client to participate directly in IIS certificate installation and binding updates.
- You prefer a Windows-focused client rather than a PowerShell module-based workflow.
acme.sh for general Unix environments
acme.sh is an open-source ACME client written in Unix shell. It supports common ACME validation modes, automated renewal, deploy hooks, and Docker-based operation without a Python dependency. It still relies on standard system utilities and cryptographic tooling, so it should not be treated as literally dependency-free.
Choose acme.sh when:
- You prefer shell-based automation on Linux or another Unix-like environment.
- You want a lightweight client without a Python runtime dependency.
- You need DNS, webroot, standalone, or deploy-hook based workflows.
- You are prepared to own the scripting and service-specific installation logic.
cert-manager for Kubernetes and OpenShift
cert-manager is a Kubernetes certificate controller rather than a traditional host-level ACME client. DigiCert documents cert-manager as a supported third-party ACME integration pattern for Kubernetes and OpenShift workloads. It is typically the better abstraction when certificates are declared and reconciled as Kubernetes resources.
Choose cert-manager when:
- Certificates are consumed by Kubernetes or OpenShift workloads.
- Your platform team manages certificates declaratively through cluster resources.
- You want renewals and secret updates reconciled by a Kubernetes-native controller.
- You can protect and govern the DigiCert ACME credentials used by the issuer configuration.
Choose by environment and operating model
- Supported Windows/Linux server, centralized DigiCert-managed workflow — DigiCert Agent / TLM managed automation. Best when centralized orchestration, installation, status, and endpoint validation are priorities.
- Windows + IIS; endpoint-managed ACME — win-acme. Windows-focused workflow with IIS integration and unattended renewal.
- Windows / PowerShell automation — Posh-ACME (plus deployment module where needed). Good for script-driven workflows and PowerShell-native operations.
- Linux/BSD + Apache or NGINX — Certbot. Established open-source client with common web-server integration options.
- Unix / minimal or shell-centric environment — acme.sh. Shell-based client with broad challenge and deploy-hook options; no Python runtime dependency.
- Kubernetes / OpenShift — cert-manager. Kubernetes-native certificate controller and DigiCert-documented ACME integration pattern.
- Network appliance, cloud service, or vault; centralized managed workflow — DigiCert Sensor plus supported connector / TLM managed automation. These are not ACME-client selection scenarios by default; use the supported managed integration when it fits the target.
Selection criteria that matter more than popularity
- Deployment behavior: Can the client install the certificate where the application actually needs it, update bindings or references, and safely reload the service if required?
- Challenge automation: Does it support the validation method your environment can automate, such as HTTP-01 or DNS-01, and can the required credentials be scoped securely?
- External Account Binding: DigiCert ACME workflows use EAB credentials to associate the ACME account with the appropriate DigiCert configuration. Verify client support before standardizing on it.
- Private-key handling: Understand where the private key is generated, how it is stored, which account can access it, and whether the storage approach meets your policy.
- Renewal state and observability: Know how the client decides when to renew, where its renewal configuration is stored, how failures are surfaced, and how you verify live deployment.
- Operational ownership: Third-party ACME can be very effective, but your organization owns the client lifecycle and its deployment logic. DigiCert managed automation shifts more of that workflow into Trust Lifecycle Manager for supported targets.