Validate Your Setup on Linux with a Sandbox URL

A Sandbox ACME Directory URL is the safest way to prove your ACME setup works before you issue production certificates. Sandbox requests are not billed, issue short-lived (3-day) test certificates, and never touch production.

This walkthrough takes you through all three stages of automation on Linux—EAB authentication, issuance, and installation to your web server—using the DigiCert ACME Client (DAC).

Acronyms used on this walkthrough

One important difference from production: orders placed through a sandbox URL do not appear in your GeoCerts CertCommand certificate-management control panel. That means you confirm success or diagnose failures using your ACME client’s own output and logs—not the CertCommand orders list. This page shows you how.

This walkthrough uses the DigiCert ACME Client (DAC). Other EAB-capable clients (Certbot, win-acme) produce similar phases and log signals; the option names differ. See Alternative ACME Clients.

Why validate in the sandbox

• No production risk or cost — test certificates only, fixed 3-day validity.
• Validate before production — short-lived test certs let you confirm each step (EAB, DCV, install) before issuing for real.
• Proves the hard parts — especially Domain Control Validation (DCV) with DNS credentials.
• No GUI confirmation — because sandbox orders are not shown in the CertCommand control panel, you must learn to read the client output. That skill carries straight over to production.

Prerequisites

Before you begin, make sure you have:

• A Sandbox ACME Directory URL with its EAB Key ID and EAB HMAC Key.
• The DigiCert ACME Client installed and the DigicertAcmeClient service running.
• A domain you control, with either DNS access (for DNS-01) or an HTTP listener (for HTTP-01).

Where things are on Linux

You'll reference these default paths in Steps 2 and 3 (log tail and on-disk certificate store):

The three choke points

Most ACME setup failures happen at one of three stages. This page walks through each one and shows how to recognize it in the log.

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 server or load balancer.

The two DCV methods

You choose one DCV challenge method per request:

• DNS-01 — proves control by publishing a TXT record at _acme-challenge.<domain> in your DNS. It works without a public web server and is required for wildcard certificates, but it needs credentials for your DNS provider.
• HTTP-01 — proves control by serving a token file at http://<domain>/.well-known/acme-challenge/... on port 80. It needs no DNS API access, but the domain must resolve to the validating host and port 80 must be publicly reachable—DigiCert validates under MPIC from multiple regions worldwide (at least four).

This walkthrough uses DNS-01 as the primary example (the more common sticking point), with an HTTP-01 variant in Step 1. When you are ready for production, see NGINX with DNS-01 or Production CLI Examples.

Step 1: Run a sandbox request

The example below requests a single-domain certificate using DNS-01 validation, since DNS credentials are the most common sticking point. This walkthrough uses AWS Route 53 as the DNS provider—the client publishes and removes the _acme-challenge TXT record automatically using your Route 53 credentials. It also installs the issued certificate into NGINX, so this one command covers all three choke points—EAB, DCV, and install—end to end (the NGINX installer is detailed in Step 4).

# Sandbox DNS-01 request with NGINX install (replace placeholder values)
sudo dc-acme request enroll \
  --directory-url "https://one.digicert.com/mpki/api/v1/acme/v2/directory" \
  --email "admin@example.com" \
  --eab-key "YOUR_SANDBOX_EAB_KEY_ID" \
  --eab-hmac "YOUR_SANDBOX_EAB_HMAC_KEY" \
  --auto-ari-renew=false \
  --cn "sandbox.fastssl.com" \
  --challenge-type "dns-01" \
  --challenge-handler-name "default" \
  --challenge-handler-args "DNS_PROVIDER_NAME=route53,AWS_ACCESS_KEY_ID=YOUR_AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY,AWS_REGION=us-east-1" \
  --installer-handler-name "nginx" \
  --installer-handler-args "identifier=sandbox.fastssl.com"

The Route 53 handler is configured through --challenge-handler-args, which accepts these comma-separated arguments:

• DNS_PROVIDER_NAME=route53 — selects the Route 53 challenge handler.
• AWS_ACCESS_KEY_ID — access key for an IAM principal allowed to modify the hosted zone.
• AWS_SECRET_ACCESS_KEY — the matching secret key.
• AWS_REGION — the AWS region (for example, us-east-1).

For other DNS providers and their required arguments, see DigiCert’s DNS-01 handler reference. That page is served as raw Markdown and may display as plain text outside the DigiCert docs portal; the same provider list, rendered, is in the Lego DNS providers documentation it is derived from.

Prefer HTTP-01? Use this instead

If you validate over HTTP-01 rather than DNS, swap the challenge flags. HTTP-01 needs no DNS provider credentials, but it does require that the domain’s A record points at this host and that port 80 is reachable by DigiCert’s validation agents. Because NGINX is already running on this host, this example serves the challenge through NGINX and installs into it as well:

# Sandbox HTTP-01 request with NGINX install (replace placeholder values)
sudo dc-acme request enroll \
  --directory-url "https://one.digicert.com/mpki/api/v1/acme/v2/directory" \
  --email "admin@example.com" \
  --eab-key "YOUR_SANDBOX_EAB_KEY_ID" \
  --eab-hmac "YOUR_SANDBOX_EAB_HMAC_KEY" \
  --auto-ari-renew=false \
  --cn "sandbox.fastssl.com" \
  --challenge-type "http-01" \
  --challenge-handler-name "nginx" \
  --installer-handler-name "nginx" \
  --installer-handler-args "identifier=sandbox.fastssl.com"

• --challenge-handler-name "nginx" serves the HTTP-01 token through your running NGINX, so it does not conflict with port 80. The handler finds the server block for your domain, reads its document root (the root directive), writes the token to <root>/.well-known/acme-challenge/<token>, and reloads NGINX—so the matching server block must have a root directive. If no web server is running on the host, use standalone instead, which starts a temporary listener on port 80 (so port 80 must be free); for other running servers use their handler (apache, tomcat, or ibmhttpd).
• The installer flags (--installer-handler-name "nginx" / --installer-handler-args "identifier=…") are the same as the DNS-01 example—installation is independent of the DCV method (see Step 4).
• Port 80 must also be publicly reachable. DigiCert validates domain control under MPIC from multiple network vantage points around the world—at least four global regions, not just North America. Port 80 has to be open to the public internet broadly; a firewall or geo-restriction that only allows traffic from one country or region will cause validation to fail. See SSL Domain Validation (DCV) Rules Have Changed .
• The success signal differs from DNS-01: instead of staging a TXT record, the log shows Challenge token placed at <root>/.well-known/acme-challenge/..., then Authorization completed with status: valid.

Step 2: Read the DigiCert ACME Client log

The request command prints progress to your console, but the client log is the authoritative record—especially for renewals and background activity.

Tail the log file

On Ubuntu, the DigiCert ACME Client writes log files under /var/digicert/acme-client/log/:

# Tail the most recent log activity
tail -f /var/digicert/acme-client/log/*.log

Or use the systemd journal

# View recent logs
sudo journalctl -u DigicertAcmeClient -n 50

As the request runs, you should see distinct phases that map to the three choke points:

1. ACME account registration / EAB binding
2. Order creation and authorization
3. Challenge (DCV) — DNS record published, then validated
4. Certificate finalization and download
5. Installation / handoff

Step 3: What a successful request looks like

On a successful run, the console is brief—it validates the handler, enrolls, and returns a Request ID:

Validating handlers with server...
Handler validation successful
Initiating certificate enrollment (this may take a few minutes)...
Certificate enrollment successful. Request ID: 3

Key signals of success:

• Handler validation successful — the challenge handler (here, Route 53 DNS-01) was accepted.
• Certificate enrollment successful with a Request ID — issuance completed.
• No ERROR lines in the log, and the request status is not FAILED.

The log shows the full successful flow—account, order, DNS-01 challenge, validation, finalize, and certificate storage (trimmed for readability):

INFO  client/account.go:144      Account already exists, returning existing account
INFO  client/order.go:101        Creating order for 1 identifiers
INFO  workflow/enroll.go:226     Successfully created new ACME order with URI: .../acme/v2/order/MDUz...
INFO  workflow/enroll.go:232     Starting challenge validation with type: dns-01 with handler: default
INFO  client/challenge.go:173    Generated DNS-01 challenge to be staged - Record: _acme-challenge.sandbox.fastssl.com, Value: <redacted>
   INFO: Running DNS authenticator
   INFO: Challenge propagated successfully for domain: sandbox.fastssl.com
INFO  client/authorization.go:114  Authorization completed with status: valid for identifier: sandbox.fastssl.com
INFO  workflow/enroll.go:289     Successfully finalized order
INFO  client/certificate.go:144  Fetching certificate for order URI: .../acme/v2/order/MDUz...
INFO  client/certificate.go:262  Writing certificate and private key to certificate directory: /etc/digicert/certificates
INFO  client/certificate.go:230  Installing certificate and private key in: /etc/digicert/certificates/<timestamp>/sandbox.fastssl.com
INFO  workflow/enroll.go:343     Processing certificate installation with handler: nginx
INFO  workflow/enroll.go:358     Certificate enrollment process completed successfully
INFO  ds/acmedao.go:1054         ACME request status updated successfully - Status: COMPLETED
INFO  Processing enrollment request - COMPLETED SUCCESSFULLY

The lines to look for:

• Authorization completed with status: valid — DCV passed (the TXT record was found and validated).
• Current order status: ready then Successfully finalized order — the order was finalized after validation.
• Writing certificate and private key to certificate directory: /etc/digicert/certificates — the cert was stored.
• Status: COMPLETED and Processing enrollment request - COMPLETED SUCCESSFULLY — the request finished.

Confirm success without CertCommand

Because the sandbox order will not appear in your GeoCerts CertCommand control panel, confirm the result using the client and the host:

sudo dc-acme request list

Each entry shows an ID, a Status, the Created timestamp, and the original request JSON:

ACME Requests:
==============
Found 1 request(s)
Request 1: ID: 3 | Status: COMPLETED | Created: 2026-06-25T11:25:04Z | Request: {"directoryUrl":"https://one.digicert.com/mpki/api/v1/acme/v2/directory","email":"admin@example.com","eabKey":"<REDACTED - EAB Key ID>","eabHmac":"<REDACTED - EAB HMAC>","action":"enroll","certificateRequest":{"keyType":"RSA","keySize":"2048","signatureAlgo":"SHA256WithRSA","cn":"sandbox.fastssl.com","san":null},"challengePreference":{"type":"dns-01","handlerName":"default"},"installerPreference":null,"acmeAriId":3}

Look for your request’s status to be COMPLETED (the same status the log reports). A FAILED status means the request did not issue—check the log for the cause.

You can also verify the issued certificate directly. By default the client stores certificates under /etc/digicert/certificates/, in a timestamped subfolder named for the issuance time, then a folder named for the certificate’s Common Name:

/etc/digicert/certificates/<YYYY_MM_DD_HH_MM_SS>/<common-name>/
├── fullchain.pem   # issued certificate plus the issuing chain
└── privkey.pem     # the certificate's private key

List the most recent issuance and inspect the certificate’s validity dates:

# Find the latest issued certificate directory
ls -dt /etc/digicert/certificates/*/ | head -n 1

# Inspect the issued certificate
sudo openssl x509 -in /etc/digicert/certificates/<timestamp>/sandbox.fastssl.com/fullchain.pem -noout -subject -dates

The output shows the subject and the validity window:

subject=CN = sandbox.fastssl.com
notBefore=Jun 25 00:00:00 2026 GMT
notAfter=Jun 27 23:59:59 2026 GMT

A 3-day validity window (here, Jun 25 to Jun 27) is a strong confirmation that the request was issued by the sandbox—sandbox certificates have a fixed 3-day lifetime.

Once the certificate is installed (Step 4) and your host is publicly reachable, you can also confirm it from outside the server with the GeoCerts SSL Checker.

Step 4: Install the certificate to NGINX

Issuance writes the certificate to disk; installation deploys it to your web server so it serves traffic over HTTPS. This is the third choke point. The Step 1 command already included an installer handler (--installer-handler-name nginx), so issuance and installation happened in that single request—this step explains what the NGINX installer did and how to verify it. (Without an installer handler the client only stores the cert on disk and you deploy it yourself. The DigiCert ACME Client also ships apache, filesystem, and other handlers.)

How the NGINX installer works

The NGINX installer auto-discovers your configuration. It runs your nginx binary to find every config file, locates the server block whose server_name matches the domain you pass in identifier, then:

• Updates an existing HTTPS (listen 443 ssl) block in place—rewriting its ssl_certificate and ssl_certificate_key to the newly issued files—or creates an HTTPS block from your port-80 block if no 443 block exists.
• Reloads NGINX gracefully (nginx -s reload).

Unlike the Windows/IIS installer, there is no one-time bootstrap: you do not need to pre-create a binding or seed a placeholder certificate.

sudo nginx -T 2>/dev/null | grep -nE 'server_name|listen'

The installer flags

The two installer flags from the Step 1 command are what triggered installation. The NGINX installer uses identifier=<domain> (where the Windows/IIS installer uses hostname=):

  --installer-handler-name "nginx" \
  --installer-handler-args "identifier=sandbox.fastssl.com"

In the log, the installer reports the server block it discovered, the ssl_certificate / ssl_certificate_key lines it rewrote, the config file it saved, and the reload (trimmed for readability):

INFO  Processing certificate installation with handler: nginx
INFO  Installing certificate and private key in: /etc/digicert/certificates/2026_06_28_20_49_04/sandbox.fastssl.com
INFO  Invoking install handler: nginx
   Discovered Nginx server block *:80 for sandbox.fastssl.com
   Cross-file analysis complete: 2 blocks total, 1 HTTP, 1 HTTPS
   Found existing port 443 block for domain sandbox.fastssl.com, will update it instead of creating new
   Updated ssl_certificate to: /etc/digicert/certificates/2026_06_28_20_49_04/sandbox.fastssl.com/fullchain.pem
   Updated ssl_certificate_key to: /etc/digicert/certificates/2026_06_28_20_49_04/sandbox.fastssl.com/privkey.pem
   Saved updated config: /etc/nginx/sites-enabled/acme-test
   Restarting Nginx server... Reload successful, master PID unchanged
   Nginx installation completed successfully and restarted.
INFO  ACME request status updated successfully - ID: 9, Status: COMPLETED
INFO  Processing enrollment request - COMPLETED SUCCESSFULLY

COMPLETED SUCCESSFULLY confirms issuance and installation finished.

Verify it is serving the new certificate

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

# Confirm the certificate served over HTTPS (run from any host that resolves the domain)
echo | openssl s_client -connect sandbox.fastssl.com:443 -servername sandbox.fastssl.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

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

The served certificate’s subject should be your domain and the validity window should be the 3-day sandbox lifetime—the same certificate you confirmed on disk in Step 3.

Prefer a browser-based check? Because sandbox certificates are publicly trusted, you can also confirm the live endpoint with the GeoCerts SSL Checker—enter your domain to see the served certificate, its issuer, and expiry. This only works once the certificate is installed and the host is reachable on port 443 from the public internet.

For load balancers and similar targets, the client typically does not install directly: issuance succeeds, but deployment is your own step (a deploy hook or an API upload to the load balancer).

Step 5: If something failed

If the request shows FAILED in dc-acme request list or the log stops before COMPLETED SUCCESSFULLY, use Verify and Diagnose ACME Requests to confirm what succeeded and pinpoint the failure at EAB, DCV, or installation. For NGINX install issues, see Installation failures — NGINX.

Clean up after testing

Sandbox test requests remain listed in the ACME client’s local database (both COMPLETED and FAILED). They do not affect production and are not billed, but they accumulate as you test, and each stored request includes your EAB and challenge-handler credentials in plaintext. Keep that in mind on shared or temporary machines.

Next step

Once your sandbox request completes cleanly—especially DCV—you are ready for production. Remember: a sandbox URL cannot be converted to production.

Create a production ACME Directory URL »

Related topics

• Create an ACME Directory URL — Including the sandbox checkbox and terms
• NGINX with DNS-01 — Production Linux/NGINX request with CLI flags
• Verify and Diagnose ACME Requests — Confirm success, verify HTTPS, and diagnose EAB, DCV, and install failures
• Troubleshooting Common Issues — Funding, OV, and permissions
• Frequently Asked Questions — Sandbox behavior and why orders don’t appear in CertCommand

← Back to Get Started