Frequently Asked Questions

Answers to common questions about the DigiCert ACME Client and GeoCerts ACME automation—renewal timing and ARI, dc-acme request list, sandbox vs production, CLI vs dc-acme.toml, third-party clients (Certbot, Win-ACME), and IP certificate limits.

For enroll or install failures, start with Verify and Diagnose ACME Requests. For symptom-based fixes (DCV, billing, permissions), see Troubleshooting Common Issues.

Acronyms used on this page

Term Meaning
ACME Automated Certificate Management Environment — the protocol used to automate certificate issuance and renewal
ADU ACME Directory URL — the endpoint and credential profile you create in CertCommand under Automation > ACME Directory URLs
CLI Command-Line Interface — run `dc-acme request enroll` with explicit flags instead of loading settings from `dc-acme.toml`
TOML Tom's Obvious, Minimal Language — the config file format used by `dc-acme.toml`
EAB External Account Binding — Key ID and HMAC credentials that authenticate your ACME client to GeoCerts
ARI ACME Renewal Information — optional CA-directed schedule for when to renew a certificate
DAC DigiCert ACME Client — GeoCerts' recommended ACME client (`dc-acme`)
SAN Subject Alternative Name — additional hostnames on the same certificate (`--sans` flag)

Why doesn’t dc-acme request list show the next renewal date?

The DigiCert ACME Client tracks requests locally and shows request IDs, status, creation timestamps, and original request JSON. It does not display next renewal dates, renewal countdowns, or ACME Renewal Information (ARI) schedules. That is expected behavior.

Use CertCommand (Certificates > Orders) to view certificate expiration dates. With ARI enabled, DigiCert directs reissue timing through the background service—not via a countdown in request list.


Do I need to enable ARI for renewals to work?

Yes, for production. Use ACME Renewal Information (ARI) so DigiCert tells the client when to reissue—timing adapts as certificate lifetimes shorten.

Production: set auto_ari_renew = true in dc-acme.toml under [service] and enroll with --use-default-config, or on CLI-only enrolls omit --auto-ari-renew=false. After enroll, confirm a non-zero acmeAriId in sudo dc-acme request list.

Sandbox / one-shot tests: pass --auto-ari-renew=false (or set TOML auto_ari_renew = false) so the client does not register background reissues during testing.

See Understanding Automated Renewals and Renewal Timing and Configuration.


What happens if I omit --auto-ari-renew on enroll?

CLI-only enroll (no --use-default-config): omitting --auto-ari-renew registers an ARI job (non-zero acmeAriId). Pass --auto-ari-renew=false on sandbox walkthroughs to suppress automatic reissues. Do not trust dc-acme --defaults or --help for ARI defaults—check acmeAriId in request list.

Config-based enroll (--use-default-config): TOML auto_ari_renew in [service] controls whether an ARI job registers. CLI --auto-ari-renew does not override TOML when the config file is loaded.

See Configuration (dc-acme.toml).


When will my certificate renew?

With ARI enabled, DigiCert directs reissue timing through the background service. The client does not show a “next reissue” date in request list—that is expected. Reissues may happen earlier or later than a fixed day count as the CA updates its schedule.

Confirm acmeAriId is non-zero in sudo dc-acme request list and watch CertCommand under Certificates > Orders for the active certificate order.


Why aren’t my certificates renewing automatically?

Check these in order:

  1. ARI not registered — Set auto_ari_renew = true in dc-acme.toml [service] (with --use-default-config), or omit --auto-ari-renew=false on CLI-only enrolls. Confirm a non-zero acmeAriId in sudo dc-acme request list.
  2. Service not running — Confirm DigicertAcmeClient is active.
  3. Organization Validation expired — OV organization validation may need re-validation (contact us ).
  4. Funding — Account funding or billing issues that prevent certificate issuance.

See Troubleshooting Common Issues.


Can I use ACME for IP address certificates?

No—not at this time. DigiCert ACME automation supports fully qualified domain names (FQDNs) and wildcards only. You cannot issue or renew a certificate whose Common Name or SAN is an IP address (for example --cn "203.0.113.10") through ACME on the current DigiCert endpoint.

If you pass an IP address as --cn, enrollment fails at order authorization—before domain control validation runs—with an ACME error similar to:

400 urn:ietf:params:acme:error:rejectedIdentifier: Cannot issue certificates for the identifier.

The console and service log report the same response. Changing challenge type or handler does not help—the CA rejects the identifier type.

What to do instead: Continue to issue and renew IP address certificates through CertCommand using your existing portal or API workflow. ACME remains the right path for hostname-based certificates you want to automate on your servers.

If you secure an IP-only endpoint with TLS, consider whether a hostname that resolves to that IP (with DNS-01 or HTTP-01 DCV) meets your requirements—that is a product and policy decision outside ACME IP support.


Can I use Certbot or Win-ACME instead of the DigiCert ACME Client?

Yes, in many environments. GeoCerts documents the DigiCert ACME Client as the primary path because it is designed for DigiCert ACME Directory URLs and EAB.

The DigiCert ACME directory supports ARI (renewalInfo). Certbot (4.1.0+) and Win-ACME can use it during scheduled renew runs; DAC registers ARI jobs visible as acmeAriId in request list.

If you already use third-party clients, see Alternative ACME Clients.


What happens to certificate validity as industry rules change?

Certificates are issued for up to the maximum validity allowed at the time of issuance. Validity periods are shortening industry-wide. Enable ARI (auto_ari_renew = true) so DigiCert directs reissue timing as lifetimes change.


What is a Sandbox ACME Directory URL?

A Sandbox ACME Directory URL routes your ACME requests to the GeoCerts ACME sandbox environment. It works like a production URL—you get an ACME Directory URL and EAB credentials—but certificates are not billed and are intended for testing only.

The directory URL string is the same as production; the sandbox EAB credentials are what make a request a sandbox request. There is no separate sandbox endpoint.

Use a sandbox URL to validate EAB authentication, DCV (especially automated DNS credentials), and post-issuance deployment on a web server. For load balancers, use it to confirm issuance works, then validate your own deploy hook or API upload—ACME clients typically do not install directly on load balancers.

Sandbox URLs:

  • Issue DV Flex test certificates only (no OV or organization pre-validation).
  • Use a fixed 3-day certificate validity.
  • Do not create orders visible in CertCommand under Certificates > Orders.
  • Cannot be converted to a production URL—you must create a new production ACME Directory URL when ready.
  • Must not be used for production traffic.

Create one by selecting Create sandbox ACME URL when you create an ACME Directory URL.


Can I convert a sandbox ACME Directory URL to production?

No. A sandbox ACME Directory URL cannot be converted to production. When testing is complete, create a new production ACME Directory URL (without the sandbox checkbox), copy the new directory URL and EAB credentials, and update your client configuration. Revoke the sandbox URL if you no longer need it.


Why doesn’t my sandbox certificate appear in CertCommand?

Orders placed through a Sandbox ACME Directory URL do not appear in CertCommand. That is expected. Sandbox issuance is for testing EAB, DCV, and client behavior without creating production orders.

Confirm success with dc-acme request list, client logs, and the certificate on your server—not the CertCommand orders list.


Should I use CLI flags only or --use-default-config?

Both are valid—you can use either alone or combine them:

  • CLI flags only — Every setting visible in the command; good for first production proof, sandbox walkthroughs, and support tickets (Production CLI Examples). Renewal flags on CLI apply directly when you do not use --use-default-config.
  • --use-default-config + dc-acme.toml — Shorter repeat enrolls, copy the same file across servers, keep secrets out of shell history (Configuration (dc-acme.toml)). CLI overrides TOML for most keys; renewal mode (auto_ari_renew) follows TOML when the config file is loaded.

EAB credentials are only displayed once when you create an ACME Directory URL. Storing them in dc-acme.toml reduces the risk of loss.


← Back to Troubleshooting & FAQs