ACME Client Configuration Options for SSL Certificate Automation

The Automatic Certificate Management Environment (ACME) protocol is a standard, but every ACME client is different. Two customers using the same protocol against the same Certificate Authority (CA) can end up with completely different behavior because their clients are configured differently. One requests a new SSL Certificate every seven days. Another waits until thirty days before expiry. A third uses Hypertext Transfer Protocol (HTTP) authentication while a fourth uses Domain Name System (DNS) authentication for the same domain.

None of that is determined by the SSL Certificate license, the Certificate Authority (CA), or the protocol itself. It is determined entirely by the client software you choose and how you configure it.

This article walks through the configuration options that ACME clients commonly expose, with concrete examples from the most widely used clients : acme.sh, Certbot, win-acme, Lego, Posh-ACME, and the Trustico® cPanel plugin. The goal is to make it clear what each setting actually controls so you can match a client to your environment and configure it to behave the way you want.

The ACME protocol itself only specifies how a client and a Certificate Authority (CA) negotiate the issuance of an SSL Certificate. Everything around that, from when to request, how to authenticate, what key to use, where to put the resulting files, and who to e-mail when something fails, sits in the client. Explore the protocol fundamentals in our article on The ACME Protocol 🔗

ACME Client Choice Shapes Your Configuration Options

Different ACME clients exist because different environments need different things. A Linux administrator working from a terminal has nothing in common with a Windows administrator clicking through Internet Information Services (IIS), and neither resembles a Kubernetes operator managing SSL Certificates across hundreds of pods.

acme.sh is a shell script that runs on almost any Unix-like operating system without external dependencies. It is the most flexible of the popular clients and exposes the widest range of configuration options. Certbot is the official client from the Electronic Frontier Foundation, written in Python, and well suited to Linux servers running Apache or nginx.

win-acme is a Windows-native client built around Internet Information Services (IIS) integration. Lego is a single statically compiled Go binary, popular in containerized environments and as a library inside other tools. Posh-ACME is a PowerShell module suited to Windows administrators who already work in PowerShell. The Trustico® cPanel plugin sits inside a shared hosting control panel and exposes a streamlined set of options through a graphical interface.

Each of these clients has its own configuration syntax, its own file locations, its own defaults, and its own plugin ecosystem. The same conceptual setting, such as choosing Elliptic Curve Cryptography (ECC) keys over Rivest-Shamir-Adleman (RSA) keys, looks different in every client. Discover our recommended ACME Clients 🔗

Authentication Challenge Types Available Through ACME

Every time an ACME client requests a new SSL Certificate, it must prove that you control the domain. The protocol defines three challenge types : HTTP-01, DNS-01, and TLS-ALPN-01. Your client decides which one to attempt, and you can usually override that choice in configuration.

HTTP-01 places a small file at a predictable Hypertext Transfer Protocol (HTTP) path on your web server, specifically /.well-known/acme-challenge/, and waits for the Certificate Authority (CA) to fetch it on port 80. It is the easiest to set up for a single web server with port 80 open to the public internet. It cannot be used for Wildcard SSL Certificates because wildcards cover a class of subdomains rather than a specific server. Learn About The Well-Known Validation Folder 🔗

DNS-01 places a TXT record at _acme-challenge.example.com and waits for the Certificate Authority (CA) to query it. This works regardless of whether your server has port 80 open, works for Wildcard SSL Certificates, and works for infrastructure that is not reachable from the public internet at all. The trade-off is that your ACME client needs to be able to write to your Domain Name System (DNS) provider, which usually means storing an Application Programming Interface (API) token somewhere on the client machine.

TLS-ALPN-01 uses a Transport Layer Security (TLS) handshake on port 443 to prove control. It is useful when port 80 is closed but port 443 is open, and it does not require Domain Name System (DNS) Application Programming Interface (API) access. Support varies by client and by the server software in front of the client. Explore our guide on Choosing Between HTTP-01 and DNS-01 🔗

acme.sh

acme.sh defaults to HTTP-01 if you specify a webroot directory. To switch to DNS-01, you pass a --dns flag naming a Domain Name System (DNS) provider plugin. To use TLS-ALPN-01, you pass --alpn.

acme.sh --issue -d example.com -w /var/www/html

acme.sh --issue -d example.com --dns dns_cf

acme.sh --issue -d example.com --alpn

Certbot

Certbot uses --webroot, --nginx, or --apache for HTTP-01, and a Domain Name System (DNS) plugin like --dns-cloudflare for DNS-01. TLS-ALPN-01 is supported through the --preferred-challenges tls-alpn-01 option when the server has compatible software in front of it.

certbot certonly --webroot -w /var/www/html -d example.com

certbot certonly --dns-cloudflare -d example.com

certbot certonly --preferred-challenges tls-alpn-01 -d example.com

win-acme

win-acme defaults to HTTP-01 through Internet Information Services (IIS) bindings, which it discovers automatically. DNS-01 requires installing a Domain Name System (DNS) plugin separately and configuring credentials either interactively or in the settings.json file. TLS-ALPN-01 is supported but limited because Internet Information Services (IIS) does not expose the necessary handshake hooks easily.

Lego

Lego selects the challenge type with a positional argument. The --http flag selects HTTP-01, --dns providerName selects DNS-01, and --tls selects TLS-ALPN-01.

lego --email me@example.com --domains example.com --http run

lego --email me@example.com --domains example.com --dns cloudflare run

lego --email me@example.com --domains example.com --tls run

Posh-ACME

Posh-ACME uses the -Plugin parameter to select a Domain Name System (DNS) provider or web server plugin. The WebRoot plugin handles HTTP-01, while named Domain Name System (DNS) plugins handle DNS-01.

New-PACertificate example.com -Plugin WebRoot -PluginArgs @{WRPath='C:\inetpub\wwwroot'}

New-PACertificate example.com -Plugin Cloudflare -PluginArgs @{CFToken=$token}

Trustico® cPanel Plugin

The Trustico® cPanel plugin typically uses HTTP-01 because the panel already controls the web server. DNS-01 is not always exposed to end users on shared hosting, and TLS-ALPN-01 is rare.

Reissue Scheduling and Frequency Settings

This area causes more confusion than any other. The SSL Certificate license you purchase from Trustico® gives you the right to obtain SSL Certificates for a set period. The Certificate Authority (CA) issues each SSL Certificate with a validity period set by industry rules. Neither of those things tells your ACME client when to request a new SSL Certificate. That decision lives entirely in the client.

One client may request a new SSL Certificate every seven days. Another may wait until thirty days before expiry. A third may be set to run only on demand. Different defaults explain why two customers can describe their SSL Certificate behavior completely differently while using the same Certificate Authority (CA) and the same license. Learn About How SSL Certificate Reissue Works 🔗

Each reissue is a complete new request. The client re-authenticates the domain, generates or reuses a Certificate Signing Request (CSR), and receives a new SSL Certificate. Authentication happens every time, regardless of how recently the previous SSL Certificate was issued.

acme.sh

acme.sh installs a cron job by default that runs once per day at a randomized time. The script checks each SSL Certificate and reissues any that fall within sixty days of expiry. You can override this with the --days N option on the --renew command.

acme.sh --renew -d example.com --days 30

acme.sh --cron

Certbot

Certbot ships with a systemd timer or cron job that runs twice per day. It will reissue an SSL Certificate that has less than thirty days until expiry. You can change the threshold per SSL Certificate by setting renew_before_expiry in the SSL Certificate's reissue configuration file.

# /etc/letsencrypt/renewal/example.com.conf
renew_before_expiry = 30 days

win-acme

win-acme installs a Windows scheduled task on first run. The default reissue window is fifty-five days before expiry, configurable through the settings file as the RenewalDays value.

Lego

Lego does not install a scheduler. You run it from your own cron job or systemd timer. The renew subcommand takes --days N to control the threshold at which a new SSL Certificate is requested.

lego --email me@example.com --domains example.com --dns cloudflare renew --days 30

Posh-ACME

Posh-ACME has a Submit-Renewal cmdlet but does not install a scheduler. The default is to reissue when an SSL Certificate is within thirty days of expiry, controllable with the -RenewDays parameter.

Trustico® cPanel Plugin

The Trustico® cPanel plugin runs on the cPanel daily cron schedule. Reissue thresholds are not usually exposed to end users in the panel interface as they are determined at the time of installation, though the plugin can be used at any time to instigate a reissue.

Cryptographic Algorithm and Strength Settings

Every SSL Certificate is built around a key pair. The two algorithm families in use for new SSL Certificates today are Rivest-Shamir-Adleman (RSA) and Elliptic Curve Cryptography (ECC). RSA is older and produces larger keys. ECC produces smaller, faster keys that achieve comparable security at much lower computational cost.

Most ACME clients default to RSA at 2048 or 4096 bits because every client and server in production supports it. ECC requires more recent client and server software but performs better and produces smaller SSL Certificate files. Explore our article on RSA, DSA, and ECC Encryption 🔗

acme.sh

acme.sh uses the --keylength flag for both algorithm families. Numeric values like 2048 or 4096 request RSA. Values prefixed with ec-, such as ec-256 or ec-384, request Elliptic Curve Cryptography (ECC).

acme.sh --issue -d example.com -w /var/www/html --keylength 4096

acme.sh --issue -d example.com -w /var/www/html --keylength ec-256

Certbot

Certbot separates the choice into two flags. The --key-type option takes rsa or ecdsa, paired with --rsa-key-size for RSA or --elliptic-curve for Elliptic Curve Cryptography (ECC).

certbot certonly --key-type rsa --rsa-key-size 4096 ...

certbot certonly --key-type ecdsa --elliptic-curve secp256r1 ...

win-acme

win-acme sets the algorithm in the settings.json file under the PrivateKey section. Acceptable values include RSA, EC256, and EC384.

Lego

Lego uses the --key-type flag with values like rsa2048, rsa4096, ec256, or ec384.

lego --email me@example.com --domains example.com --key-type ec256 --http run

Posh-ACME

Posh-ACME uses the -KeyLength parameter on the New-PACertificate cmdlet. Pass numeric values such as 2048 or 4096 for RSA, or values like ec-256 and ec-384 for Elliptic Curve Cryptography (ECC).

Trustico® cPanel Plugin

The Trustico® cPanel plugin generally defaults to RSA 2048 with additional options available within the user-facing interface.

Account Credentials and External Account Binding Storage

An ACME account is an Elliptic Curve Cryptography (ECC) or Rivest-Shamir-Adleman (RSA) key pair held by the client. Every request is signed with the account key so the Certificate Authority (CA) can recognize you. Both the Sectigo® and Trustico® ACME endpoints require External Account Binding (EAB), where a Key Identifier (KID) and a Hash-Based Message Authentication Code (HMAC) tie your account to your reseller record.

Which endpoint your ACME client connects to depends on the SSL Certificate product you purchased. Sectigo® branded products are issued through the Sectigo® ACME endpoint, while Trustico® branded Certificate as a Service (CaaS) products are issued through the Trustico® ACME endpoint. The External Account Binding (EAB) credentials supplied through your Trustico® account are matched to the correct endpoint for your purchase.

Where each client stores those credentials matters for backup, migration, and security. If you lose the account key, you cannot manage SSL Certificates already tied to that account. If the External Account Binding (EAB) credentials leak, someone else can request SSL Certificates against your billing account.

acme.sh

acme.sh stores account data under ~/.acme.sh/ca/. Register an account against the appropriate ACME endpoint with the External Account Binding (EAB) credentials supplied through your Trustico® account.

acme.sh --register-account --server <your-acme-endpoint> --eab-kid YOUR_KID --eab-hmac-key YOUR_HMAC

Certbot

Certbot stores account data under /etc/letsencrypt/accounts/. External Account Binding (EAB) credentials are passed on the initial register call and persisted with the account.

certbot register --server <your-acme-endpoint> --eab-kid YOUR_KID --eab-hmac-key YOUR_HMAC --email you@example.com

win-acme

win-acme stores accounts under %programdata%\win-acme in a directory named after the Certificate Authority (CA) endpoint. External Account Binding (EAB) details are entered during interactive setup or pre-populated in the settings.json file.

Lego

Lego stores account data in the path supplied via --path, defaulting to a .lego directory in the working directory. External Account Binding (EAB) values are passed at registration time.

lego --email me@example.com --server <your-acme-endpoint> --eab --kid YOUR_KID --hmac YOUR_HMAC run

Posh-ACME

Posh-ACME keeps accounts at %LOCALAPPDATA%\Posh-ACME on Windows and ~/.config/Posh-ACME on Linux or macOS. External Account Binding (EAB) is configured with the Set-PAAccount cmdlet.

Trustico® cPanel Plugin

The Trustico® cPanel plugin manages account storage within the user directory. End users do not typically need to interact with the account key directly.

Deploy Hooks and Post-Issuance Automation

An SSL Certificate sitting in a file on disk does nothing. Web servers and other appliances need to be told the SSL Certificate has changed before they will serve it. Deploy hooks let an ACME client run a command after a successful issuance, typically to reload a service, restart a daemon, or copy the SSL Certificate to another machine.

acme.sh

acme.sh ships with deploy hooks for common appliances and services. You can call a built-in hook by name or write a shell script and reference it by path.

acme.sh --deploy -d example.com --deploy-hook nginx

acme.sh --deploy -d example.com --deploy-hook /usr/local/bin/post-issue.sh

Certbot

Certbot accepts --deploy-hook at issuance and saves it to the SSL Certificate's reissue configuration file so future reissues run the same hook automatically.

certbot certonly ... --deploy-hook "systemctl reload nginx"

win-acme

win-acme calls these installation steps. The interactive wizard offers options to install into Internet Information Services (IIS), run a PowerShell script, or copy files to a remote location. Choices are saved into the reissue record so they repeat on every reissue.

Lego

Lego runs commands listed under the --run-hook flag after a successful issuance.

lego ... --run-hook "/usr/local/bin/post-issue.sh"

Posh-ACME

Posh-ACME uses the -Install switch on the New-PACertificate cmdlet to copy the SSL Certificate into the Windows Certificate Store, and Set-PAOrder -PostScript to run additional commands after each issuance.

Trustico® cPanel Plugin

The Trustico® cPanel plugin installs SSL Certificates against the relevant cPanel account automatically. Custom deploy logic is not normally exposed to users.

Provider Plugins for Domain Name System Validation

Choosing DNS-01 means your ACME client must be able to write a Domain Name System (DNS) record at your Domain Name System (DNS) provider. Every client ships with a set of provider plugins, and the list differs significantly between clients.

acme.sh has the widest plugin list among the popular clients, with over a hundred Domain Name System (DNS) providers supported through community-contributed scripts. The naming convention is dns_PROVIDER, for example dns_cf for Cloudflare or dns_gd for GoDaddy. Plugin credentials are stored as environment variables that acme.sh persists in the account.conf file.

Certbot keeps its plugins as separate Python packages. The official set is small, covering certbot-dns-cloudflare, certbot-dns-route53, and a handful of others. Third-party plugins exist for many other providers. Each plugin reads its credentials from a configuration file with explicit Application Programming Interface (API) tokens or keys.

win-acme supports Domain Name System (DNS) validation through downloadable plugins distributed alongside the main installer. Major providers including Cloudflare, Route 53, Azure Domain Name System (DNS), and GoDaddy are covered.

Lego has a large built-in list of Domain Name System (DNS) providers, maintained by the upstream project. Provider credentials are typically supplied as environment variables read at runtime.

Posh-ACME ships with a large set of Domain Name System (DNS) plugins as part of the module. PowerShell users can also write their own plugins using the documented plugin interface.

The Trustico® cPanel plugin does not typically expose Domain Name System (DNS) provider configuration because the panel handles issuance against the domains it already manages.

Logging, Notifications, and Error Handling

Automation only works if it tells you when it breaks. Every ACME client logs its activity somewhere, and most can also send an e-mail or run a script on failure. Log paths, log levels, and failure notification options all differ by client.

acme.sh

acme.sh writes log output to ~/.acme.sh/acme.sh.log by default. You can change the path with --log and the verbosity with --debug or --log-level. Notifications are sent through configurable hooks that include e-mail, Telegram, and other channels.

Certbot

Certbot writes detailed logs to /var/log/letsencrypt/letsencrypt.log. The --quiet and --verbose flags adjust console output. Failure notifications can be configured by wrapping the Certbot command in a script that sends e-mail on a non-zero exit code.

win-acme

win-acme writes logs under %programdata%\win-acme\Log. Built-in notification options include e-mail and Windows Event Log entries on success or failure.

Lego

Lego writes output to standard error and does not maintain its own log files. Operators typically redirect output to a log file from the cron job or systemd unit calling Lego.

Posh-ACME

Posh-ACME writes verbose output through PowerShell's standard streams and stores its account data and SSL Certificate history at %LOCALAPPDATA%\Posh-ACME. Custom logging is left to the surrounding script.

Trustico® cPanel Plugin

The Trustico® cPanel plugin logs to the cPanel system and user log files. End users see SSL Certificate status through the panel interface rather than reading the underlying logs.

Choosing the Right ACME Client for Your Environment

The right ACME client for you depends on the operating system, the web server, the team's familiarity with the relevant tools, and the breadth of provider support you need.

On a Linux server running nginx or Apache, both acme.sh and Certbot are reasonable choices. Pick acme.sh if you need an unusual Domain Name System (DNS) provider or want a single self-contained shell script. Pick Certbot if you are running an Apache or nginx setup where the official integrations save you from writing your own deploy logic.

On Windows servers running Internet Information Services (IIS), win-acme is the most direct fit because it integrates with Internet Information Services (IIS) bindings automatically. Posh-ACME suits Windows shops where PowerShell is already the orchestration tool of choice.

In containerized or scripted environments, Lego often wins because it is a single static binary that can be embedded in build pipelines or run inside a sidecar container without dragging in language runtimes.

On shared hosting through cPanel, the Trustico® cPanel plugin is the most practical option because it is pre-configured for our Certificate as a Service (CaaS) model and handles installation through the panel. Learn About The Trustico® cPanel Plugin 🔗

Trustico® supports automated reissue through any conformant ACME client. SSL Certificates can be issued through either the Sectigo® or Trustico® ACME endpoint depending on the product purchased. Discover the Certificate as a Service 🔗 model that ties this all together.

Closing Thoughts on Configuration Choices

Every behavior you observe from an ACME client is the result of a configuration choice. The reissue schedule is a choice. The challenge type is a choice. The key algorithm is a choice. The deploy hook is a choice. The Domain Name System (DNS) provider plugin is a choice.

That cuts two ways. It means there is no single right answer to how an ACME client should behave, because the right answer depends on your environment. It also means that if your client is doing something you do not want, such as requesting SSL Certificates too often, using the wrong challenge type, or generating keys with the wrong algorithm, you can change it. The defaults that came with the installer are starting points, not constraints.

The SSL Certificate license you purchase from Trustico® is independent of the client you choose to run against it. Choose the client that fits your environment, configure it to behave the way you want, and let the protocol do the rest.