Validate Your Setup on Windows (IIS) 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 Windows Server with IIS—EAB authentication, issuance, and installation into IIS—using the DigiCert ACME Client (DAC). On Windows, you complete a one-time IIS bootstrap first, then run one enroll command that covers EAB, DCV, and install end to end.

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 client’s own output and logs—not the CertCommand orders list. This page shows you how.

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 — DCV with DNS credentials, and the IIS binding setup the installer needs.
• 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 on Windows and the DigicertAcmeClient service running.
• IIS installed, with a site (for example, Default Web Site) for the hostname you are securing.
• A domain you control, with either DNS access (for DNS-01) or a reachable HTTP listener on port 80 (for HTTP-01).

Command environment: Run every command on this page in an elevated PowerShell session (Run as Administrator). There is no sudo on Windows—elevation is handled when you open PowerShell as Administrator. Multi-line dc-acme examples use the PowerShell line-continuation character (backtick `) at the end of each continued line.

Where things are on Windows

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 installation — the issued certificate is installed and bound to your IIS site on port 443. On Windows this requires the one-time bootstrap in Step 1 before your first install.

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, with an HTTP-01 variant in Step 2. When you are ready for production on Windows, see IIS with HTTP-01 or Production CLI Examples.

Step 1: Prepare IIS for installation

This is the Windows-specific work—and the part that surprises people. The DigiCert ACME Client (DAC) ships a native iis installer handler that binds the issued certificate to your IIS site automatically. Complete this step before you run your first enroll command.

How the IIS installer works

The iis installer handler is an updater, not a creator. After issuance, it looks for an existing IIS HTTPS binding in the form *:443:<hostname> (all-IP, with SNI enabled) that already has a certificate attached (a self-signed placeholder is fine), reads that binding’s current certificate, and replaces it with the freshly issued one.

What it does not do:

• It does not create the HTTPS binding for you.
• It does not seed a certificate onto a binding that has none.
• It does not match a binding pinned to a specific IP (for example 10.0.0.5:443)—it matches the all-IP form *:443.

Because of this, a brand-new site needs a one-time bootstrap to establish the binding and a placeholder certificate. After that, every issuance and renewal simply swaps the certificate on that binding.

One-time IIS bootstrap

Run this once per hostname, before your first native install on a site that needs the binding. It creates an *:443:<hostname> SNI binding and attaches a self-signed placeholder certificate so the installer has something to replace. Your first enroll swaps the placeholder for the real, publicly trusted certificate.

$site    = "Default Web Site"
$dnsName = "sandbox.fastssl.com"
Import-Module WebAdministration

# 1) Create a self-signed placeholder certificate in LocalMachine\My
$ph = New-SelfSignedCertificate -DnsName $dnsName -CertStoreLocation Cert:\LocalMachine\My `
        -FriendlyName "ACME placeholder - $dnsName"

# 2) Create the SNI HTTPS binding (*:443:<hostname>, SslFlags=1) if it doesn't already exist
if (-not (Get-WebBinding -Name $site -Protocol https -Port 443 -HostHeader $dnsName -ErrorAction SilentlyContinue)) {
    New-WebBinding -Name $site -Protocol https -Port 443 -HostHeader $dnsName -SslFlags 1
}

# 3) Attach the placeholder certificate to the binding
$b = Get-WebBinding -Name $site -Protocol https -Port 443 -HostHeader $dnsName
$b.AddSslCertificate($ph.Thumbprint, "My")

# 4) Confirm the binding the installer looks for now exists
Get-WebBinding -Name $site -Protocol https | Format-Table protocol, bindingInformation, sslFlags -Auto

After step 4, confirm the binding matches what the iis installer looks for: https, bindingInformation of *:443:<your-hostname>, and sslFlags of 1 (SNI). Example output when $dnsName is sandbox.fastssl.com:

protocol bindingInformation           sslFlags
-------- ------------------           --------
https    *:443:sandbox.fastssl.com          1

Use the same hostname in $dnsName, --cn, and hostname= in the enroll command in Step 2.

Step 2: Run a sandbox request

With the bootstrap in place, run one enroll command that covers EAB, DCV, and IIS install. The example below uses 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. Route 53 is only the example shown here: the DigiCert ACME Client supports 190+ DNS providers (it uses the Lego DNS library under the hood), each with its own handler arguments. Replace the placeholder values with your sandbox credentials and domain.

# Sandbox DNS-01 request with IIS install (replace placeholder values)
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 "iis" `
  --installer-handler-args "hostname=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). Route 53 is global, so any valid region works.

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.

• The IIS installer uses hostname=<domain> in --installer-handler-args (the NGINX installer uses identifier=).
• To issue without installing, drop the two --installer-handler-* flags.

Prefer HTTP-01?

If you validate over HTTP-01 rather than DNS, swap the challenge flags and keep the same installer handler. On Windows, IIS already owns port 80, so do not use the standalone handler (it tries to start its own listener on port 80 and will conflict). Use the iis challenge handler instead—it integrates with IIS to serve the challenge token and takes no extra arguments:

# Sandbox HTTP-01 request with IIS install (replace placeholder values)
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 "iis" `
  --installer-handler-name "iis" `
  --installer-handler-args "hostname=sandbox.fastssl.com"

HTTP-01 requires that the domain’s A record points at this host and that port 80 is 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, so 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 rest of this walkthrough uses the DNS-01 example.

Step 3: 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.

The enroll command is just a client; the work runs in the DigicertAcmeClient service, so tail the service log:

# Tail the service log live
Get-Content -Path "C:\Program Files\DigiCert\AcmeClient\log\dc-acme.log" -Wait -Tail 50

If the log file is not present, fall back to the Windows Event Log:

Get-EventLog -LogName Application -Source "DigicertAcmeClient" -Newest 50

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

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

Step 4: 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: 9

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 service log shows the full successful flow—account, order, DNS-01 challenge, validation, finalize, certificate storage, and IIS install (trimmed for readability; paths are Windows defaults):

INFO  Account already exists, returning existing account
INFO  Creating order for 1 identifiers
INFO  Successfully created new ACME order with URI: .../acme/v2/order/MDUz...
INFO  Starting challenge validation with type: dns-01 with handler: default
INFO  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  Authorization completed with status: valid for identifier: sandbox.fastssl.com
INFO  Successfully finalized order
INFO  Writing certificate and private key to certificate directory: C:\Digicert\Certificates
INFO  Installing certificate and private key in: C:\Digicert\Certificates\<timestamp>\sandbox.fastssl.com
INFO  Processing certificate installation with handler: iis
   Found matching allIPPort binding ... https *:443:sandbox.fastssl.com  SslFlags 1
   Updating existing SNI SSL binding: sandbox.fastssl.com:443 ... replacing placeholder certificate
   certificate installed successfully to binding: sandbox.fastssl.com:443
INFO  ACME request status updated successfully - Status: COMPLETED
INFO  Processing enrollment request - COMPLETED SUCCESSFULLY

The COMPLETED SUCCESSFULLY line confirms issuance and installation finished. On renewals you simply re-run the same enroll command; the installer swaps in the new certificate. No bootstrap is needed again.

Confirm success without CertCommand

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

dc-acme request list

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

You can also verify the issued certificate on disk. By default the client stores certificates under C:\Digicert\Certificates\, in a timestamped subfolder named for the issuance time, then a folder named for the certificate’s Common Name:

C:\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

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

Step 5: Verify and troubleshoot

When the log shows COMPLETED SUCCESSFULLY, confirm the certificate is live over HTTPS—see Verify HTTPS is live — IIS for PowerShell and OpenSSL checks. A 3-day validity window confirms the certificate came from the sandbox.

If the request shows FAILED, or install did not complete, see Verify and Diagnose ACME Requests. For the most common IIS install failure (missing bootstrap binding), see Installation failures — IIS.

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—EAB, DCV, and the IIS install—you are ready for production. Remember: a sandbox URL cannot be converted to production.

Create a production ACME Directory URL »

For unattended renewals, configure dc-acme.toml and use --use-default-config on enroll—see Configuration (dc-acme.toml).

Related topics

• Validate Your Setup on Linux with a Sandbox URL — The Linux path
• IIS with HTTP-01 (production) — Same bootstrap-first flow for production
• Create an ACME Directory URL — Including the sandbox checkbox and terms
• Install the DigiCert ACME Client — Windows install and service checks
• Verify and Diagnose ACME Requests — Confirm success, verify HTTPS, and diagnose failures
• Troubleshooting Common Issues — Funding, OV, and permissions

← Back to Get Started