Verify and Diagnose ACME Requests

Use this page after you run an ACME enroll command—whether from a sandbox walkthrough, a production CLI example, or your own automation. It covers confirming success, verifying the certificate is live, and diagnosing failures at each stage.

If you are still setting up automation, complete Get Started first—many failures trace back to EAB credentials or DCV configuration.

For quick symptom-based fixes (funding, OV validation, permissions, unexpected new orders), see Troubleshooting Common Issues.

Acronyms used on this page

Quick checks

Before diving into log excerpts, verify:

1. Service running — DigicertAcmeClient is active on Linux or Windows (see Permission and service errors on the Common Issues page).
2. Credentials — directory_url, eab_key, and eab_hmac in dc-acme.toml match your ACME Directory URL (or explicit CLI flags for one-shot enrolls).
3. Domain validation — DNS or HTTP DCV can complete from the internet; wildcard certificates require DNS-01.

The three choke points

Most ACME setup failures happen at one of three stages:

1. EAB authentication — your client proves it is bound to your GeoCerts account.
2. Domain Control Validation (DCV) — you prove control of each domain. This is the most common failure point, especially with DNS credentials.
3. Post-issuance deployment — the issued certificate is installed or handed off to your web server or load balancer.

The sections below follow that order for diagnosis. For verification, start with Confirm success, then Verify HTTPS is live.

Read the log

On the console, many failures look generic—especially EAB errors that print <nil>. The service log is the authoritative signal. Keep a second terminal open and tail the log while you run enroll:

Linux:

# Tail the DigiCert ACME Client service log (Linux)
sudo tail -f /var/digicert/acme-client/log/dc-acme.log

Windows (elevated PowerShell):

# Tail the DigiCert ACME Client service log (Windows)
Get-Content "C:\Program Files\DigiCert\AcmeClient\log\dc-acme.log" -Wait -Tail 50

Look for ERROR lines and the workflow phase just before them (account registration, challenge validation, certificate installation). The walkthroughs in Get Started show sample log excerpts for each successful phase.

Confirm success

Client request list

# List local ACME request history
sudo dc-acme request list

On Windows, run the same command from an elevated PowerShell session (no sudo).

Each entry shows an ID, Status, Created timestamp, and the original request JSON. Look for COMPLETED for a successful request. FAILED means the request did not finish—check the log for the cause at one of the three choke points.

Certificate on disk

By default the client stores certificates under a timestamped directory, then a folder named for the Common Name:

Each folder contains fullchain.pem (issued certificate plus chain) and privkey.pem (private key).

Linux — find and inspect the latest issuance:

# Find latest certificate directory and inspect dates (replace placeholders)
ls -dt /etc/digicert/certificates/*/ | head -n 1
sudo openssl x509 -in /etc/digicert/certificates/<timestamp>/<common-name>/fullchain.pem -noout -subject -dates

Windows — list matching certificates in the machine store:

# List matching certificates in the Windows machine store (replace common-name)
Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like "*<common-name>*" |
  Format-List Subject, Thumbprint, NotAfter

Sandbox vs production in CertCommand

A 3-day validity window in openssl x509 -dates output is strong confirmation that a certificate came from the sandbox.

Verify HTTPS is live

Installation may succeed in the log while the site still serves an old certificate—or nothing on port 443. Confirm what clients actually receive over HTTPS.

NGINX (Linux)

Confirm NGINX references the issued certificate files:

# Confirm NGINX references the issued certificate files
sudo nginx -T 2>/dev/null | grep -nE 'server_name|ssl_certificate'

From any machine that resolves the domain, confirm the served certificate:

# Confirm the certificate served on port 443 (replace common-name)
echo | openssl s_client -connect <common-name>:443 -servername <common-name> 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Example sandbox output:

subject=CN = sandbox.fastssl.com
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1
notBefore=Jun 28 00:00:00 2026 GMT
notAfter=Jun 30 23:59:59 2026 GMT

Prefer a browser-based check? Use the GeoCerts SSL Checker—enter your domain once port 443 is reachable from the public internet.

IIS (Windows)

On the server, confirm the HTTPS binding and certificate:

# Confirm IIS HTTPS bindings and certificate in the machine store (replace common-name)
Import-Module WebAdministration
Get-WebBinding -Protocol https | Format-Table protocol, bindingInformation, sslFlags -Auto
Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like "*<common-name>*" |
  Format-List Subject, Thumbprint, NotAfter

From any machine with network access, the GeoCerts SSL Checker is the easiest external check.

If OpenSSL is on your PATH (for example, via Git for Windows):

echo $null | openssl s_client -connect <common-name>:443 -servername <common-name> 2>$null `
  | openssl x509 -noout -subject -issuer -dates

EAB authentication failures

On the console, an EAB failure can look like a generic, unhelpful error:

Validating handlers with server...
Handler validation successful
Initiating certificate enrollment (this may take a few minutes)...
ERROR	Command failed: certificate enrollment failed: workflow execution failed: <nil>

The <nil> tells you nothing. The log reveals the real cause—the request reached account registration and the server rejected the EAB credentials:

INFO  Checking if account already exists
ERROR Failed to get ACME account registration: acme: account does not exist
INFO  Creating new ACME account
ERROR Workflow task execution failed: Code: 1011, Message: Failed to register ACME account.,
      Error: 400 urn:ietf:params:acme:error:kidStatus: Invalid KID.
ACME request status updated successfully - Status: FAILED

The key line is 400 urn:ietf:params:acme:error: ... Invalid KID. The server did not accept your EAB Key ID (the value passed to --eab-key).

Likely causes:

• Wrong or mistyped EAB Key ID or HMAC Key, or stray whitespace introduced when pasting into the command.
• The Key ID and HMAC are swapped—--eab-key must be the EAB Key ID and --eab-hmac the EAB HMAC Key.
• Credentials from a different, deleted, or revoked ACME Directory URL.
• Using production EAB credentials when you meant sandbox (or vice versa). The --directory-url value is the same for both; only the EAB credentials select sandbox versus production.

Fix: Re-copy the EAB Key ID and HMAC from your ACME Directory URL in CertCommand (Automation > ACME Directory URLs). Credentials are shown only once—create a new URL if lost. Confirm there is no leading or trailing whitespace and that each value is in the correct flag.

Rejected identifier (rejectedIdentifier)

If --cn or a name in --sans is not a supported identifier, enrollment can fail at order authorization—before DCV—with:

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

Common cause — IP address as CN: DigiCert ACME does not support IP address certificates. Passing --cn "203.0.113.10" (or listing an IP in --sans) triggers this error. The console and service log show the same message; switching challenge handler or type will not fix it.

Fix: Use an FQDN for --cn and --sans, or issue IP certificates through CertCommand outside ACME. See Can I use ACME for IP address certificates?.

Domain Control Validation failures

DNS-01

What you might see (here, the DNS handler arguments were missing, so the client never got as far as publishing a record):

INFO  Starting challenge validation with type: dns-01 with handler: default
INFO  Processing challenge type: dns-01
   INFO: Running DNS authenticator
   INFO: Retrieved challenge data, initializing solver...
ERROR: Error initializing challenge solver: either DNS_PROVIDER_NAME or DNS_SCRIPT_FILE must be specified

Likely causes:

• --challenge-handler-args is missing or incomplete—DNS_PROVIDER_NAME (and the provider’s auth arguments, e.g. AWS keys for Route 53) were not supplied. The client supports 190+ DNS providers via the Lego DNS library; each provider has its own argument names.
• The _acme-challenge TXT record was not created, or has the wrong value or host.
• DNS provider credentials lack permission to write the record.
• The validator checked before the record propagated.

Fix: Pass the full handler arguments (DNS_PROVIDER_NAME plus provider auth). Look up the correct names for your DNS host in the Lego DNS providers documentation (or DigiCert’s DNS-01 handler reference). Confirm credentials, verify the _acme-challenge TXT record exists and matches, and allow for propagation. Wildcards require DNS-01.

HTTP-01

What you might see (here, the standalone handler could not bind port 80 because another service already had it):

INFO  Starting challenge validation with type: http-01 with handler: standalone
INFO  Processing challenge type: http-01
   Running standalone authenticator
   Setting up HTTP-01 challenges for 1 domains
   Serving 1 challenges on HTTP server: 0.0.0.0:80
   Error starting HTTP server for challenges: could not start HTTP server for challenges: listen tcp 0.0.0.0:80: bind: address already in use

Likely causes:

• Another service (IIS, Apache, or NGINX) is already bound to port 80, so the standalone handler cannot start its temporary listener.
• You meant to use DNS-01 but omitted --challenge-type "dns-01", so the client fell back to the http-01 / standalone default.
• Port 80 blocked at the firewall, or a load balancer not routing /.well-known/acme-challenge/ to the validation host.
• Wrong web root or file permissions.

Fix:

• If you intended DNS-01, set --challenge-type "dns-01" and --challenge-handler-name "default".
• For HTTP-01 with a running web server, use the matching handler—nginx, apache, or iis—instead of standalone.
• Ensure DigiCert validation agents can reach port 80 and the challenge path from the public internet under MPIC requirements. See SSL Domain Validation (DCV) Rules Have Changed .

See also Troubleshooting Common Issues — Domain validation failures.

Installation failures

Installation is the step after issuance. Issuance can succeed while installation fails—the request may show FAILED even though the certificate is already on disk.

NGINX

Common causes:

• Installer/handler misconfiguration—wrong identifier, path, or a failed NGINX reload.

• No server block whose server_name matches the certificate’s Common Name, or that block is not enabled. The installer has nothing to update—confirm the block first:

  # Confirm a server block exists for the certificate CN
  sudo nginx -T 2>/dev/null | grep -nE 'server_name|listen'
  

• No installer handler provided—the client only stores the cert on disk (No installer preference provided - certificate installation skipped).
• Load balancers and similar targets—the client may not install directly; issuance succeeds, but deployment is your own step (deploy hook or API upload).

The NGINX installer uses identifier=<domain> in --installer-handler-args (the IIS installer uses hostname=).

IIS

The most common install failure is running the native IIS installer without the one-time bootstrap that creates an all-IP SNI binding. There must be a *:443:<hostname> binding (with a certificate) for the installer to update. Complete bootstrap before your first enroll command—see Sandbox Walkthrough (Windows/IIS).

The service log shows:

Invoking install handler: iis
Binding check status- ipPortBindingExist:false, allIPPortBindingExist:false, isBindingPresent:false
error installing certificate to sandbox.fastssl.com:443, no valid binding found
ACME request status updated successfully - Status: FAILED

Fix: complete the one-time bootstrap, then re-run enroll. Confirm the binding is the all-IP form (*:443:<hostname>, SNI enabled) and carries a certificate—the installer matches *:443, not a binding pinned to a specific IP.

On Windows, the issued certificate may already be at C:\Digicert\Certificates\<timestamp>\<common-name>\ even when the request shows FAILED.

Related topics

• Get Started — Confirm setup steps are complete
• Sandbox Walkthrough (Linux) — End-to-end Linux flow
• Sandbox Walkthrough (Windows/IIS) — IIS bootstrap and install
• Production CLI Examples — Production enroll recipes
• Troubleshooting Common Issues — Funding, OV, permissions, and quick fixes
• Frequently Asked Questions — Sandbox behavior and renewals

← Back to Troubleshooting & FAQs