Understanding Automated Renewals

Automated renewals are one of the primary benefits of using ACME, but they often behave differently than customers expect.

This page explains how renewals work—the background service, CA eligibility rules, and ACME Renewal Information (ARI) (recommended for production). For where to set [service] in TOML, see Renewal Timing and Configuration.

Acronyms used on this page

How automated renewals work

With the DigiCert ACME Client, renewals are handled by a local service (DigicertAcmeClient) running on your system.

At a high level:

1. The client tracks issued certificates locally after a successful enroll
2. The service monitors expiration and/or polls DigiCert’s ARI endpoint
3. When renewal conditions are met, it initiates a new ACME request
4. DigiCert determines whether the request is treated as a reissue on the existing order or a new enrollment

From the ACME client’s perspective, every renewal is another certificate request—often a reissue on the same certificate order, especially when ARI drives the timing.

ARI vs. legacy fixed-window

Each certificate uses one automation path. GeoCerts recommends ARI for production.

The fixed-window model (“reissue ~30 days before expiry”) predates ARI. It does not follow DigiCert’s renewal policy as certificate lifetimes continue to shorten. When auto_ari_renew = true, ARI registers on the certificate and auto_renew_days is not used for that request.

New installations default both to off (auto_renew = false, auto_ari_renew = false). For production, enable auto_ari_renew = true in TOML and complete a successful enroll so the service tracks the certificate with an ARI job.

Renewal eligibility (CA side)

For DigiCert to accept a renewal or reissue, the underlying certificate order must be in a renewable state.

• Certificate orders become renewable when they enter a defined renewal window prior to expiration, which may vary over time as certificate lifetimes continue to shorten.
• If a certificate is outside this window, a forced renewal attempt may fail or be treated as a new enrollment.

When automatic renewal is enabled, the DigiCert ACME Client respects DigiCert’s eligibility rules and will not attempt renewal before a certificate becomes renewable—unless ARI instructs otherwise.

ACME Renewal Information (ARI)

ACME Renewal Information (ARI) is an ACME protocol feature that lets DigiCert tell your client when to reissue a certificate. GeoCerts recommends ARI for all production automation—it replaces the older fixed-day countdown model (auto_renew_days).

How ARI works in practice:

1. When TOML has auto_ari_renew = true and you enroll with --use-default-config, the client registers an ARI job for that certificate (non-zero acmeAriId in request list)
2. The background service polls DigiCert’s renewal-info endpoint on a schedule
3. When the CA returns Should renew now: true, the client creates an ARI replacement order—a reissue on the existing certificate order, or a new, billable renewal enrollment (DigiCert’s auto-detection rules decide which)
4. DCV runs again; the installer (if configured) deploys the new certificate

ARI supports shorter certificate lifetimes, large-scale automation, and coordinated renewal timing—without you maintaining a static “days before expiry” value.

Production: set auto_ari_renew = true in dc-acme.toml and enroll with --use-default-config (Configuration, Production CLI Examples). Confirm non-zero acmeAriId in request list. Sandbox / one-shot: disable ARI (CLI-only --auto-ari-renew=false, or TOML auto_ari_renew = false).

Why you don’t see renewal dates in dc-acme request list

When you run:

sudo dc-acme request list

You’ll see request IDs, status, creation timestamps, and the original request payload. ARI reissues appear as new request entries with "isAriRenewal": true.

Check acmeAriId in the request JSON:

• Non-zero — an ARI job is registered for this certificate
• 0 — no ARI job; legacy fixed-window only (if auto_renew = true in TOML—not recommended for production)

You will not see:

• A scheduled renewal date
• A renewal countdown
• A “next renewal attempt” field

This is expected. Renewal decisions are made dynamically by the service based on current time, certificate expiration, configuration, and (when enabled) ARI guidance.

Use CertCommand (Certificates > Orders) to view certificate expiration dates.

OV certificates

For OV certificates, automated renewal also depends on validation status:

• Organization validation must be current
• Domain validation must remain valid

When these conditions are met, renewals can occur automatically with typically instantaneous issuance. Expired organization or domain validation is a common cause of delayed OV renewals.

When a renewal attempt fails

If a renewal attempt fails:

• The existing certificate remains valid until expiration
• The client may retry based on its internal logic
• Errors are logged by the service (/var/digicert/acme-client/log/ on Linux)

Common causes include DNS or HTTP validation failures, expired OV validation, host permission issues, and account funding or billing problems. See Troubleshooting Common Issues.

Verify the client is tracking certificates

sudo dc-acme request list
sudo systemctl status DigicertAcmeClient    # Linux

Get-Service -Name "DigicertAcmeClient"    # Windows

A listed request with COMPLETED status confirms the client is aware of the certificate and will consider it for renewal when conditions are met.

Key takeaways

• Renewals are handled by the local DigicertAcmeClient service—not by cron or manual re-runs of enroll
• Production: use ARI — auto_ari_renew = true in TOML; confirm non-zero acmeAriId
• auto_renew_days is legacy — only applies when ARI is off; not recommended for new production setups
• With --use-default-config, TOML controls ARI registration—not CLI --auto-ari-renew
• CLI-only enrolls: omitting --auto-ari-renew registers an ARI job; pass --auto-ari-renew=false for sandbox one-shot enrolls
• Lack of visible renewal dates in CLI output is normal
• ARI replacement orders are typically a reissue on the same certificate order, but can be a new billable renewal when prepaid coverage has expired—see Auto-detection Rules

Next step

Renewal Timing and Configuration »

Related topics

• Renewal Timing and Configuration — Tune [service] settings and enroll flags
• Configuration (dc-acme.toml) — Full config reference including [service]
• Auto-detection Rules — When manual re-enrolls become new orders
• Frequently Asked Questions

← Back to Renewals