IIS with HTTP-01 (Windows)

Windows Server / IIS — This page walks through a production certificate request using the DigiCert ACME Client with command-line flags only. Do not pass --use-default-config on this page—the client will not read dc-acme.toml. For config-based enroll instead (shorter commands, copy settings across servers), see Configuration (dc-acme.toml).

Explicit CLI flags help you:

• See credential and handler usage clearly
• Confirm connectivity, permissions, and DCV on your production ACME Directory URL
• Prove issuance and IIS installation end to end
• Get a clear success signal in both the client and CertCommand before enabling automation

Acronyms used on this walkthrough

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.

Command environment: Run every command on this page in an elevated PowerShell session (Run as Administrator). Multi-line dc-acme examples use the PowerShell line-continuation character (backtick `) at the end of each continued line.

Prerequisites

Before you begin, make sure you have:

• A production ACME Directory URL with its EAB Key ID and EAB HMAC Key (not a sandbox URL).
• The DigiCert ACME Client installed on Windows and the DigicertAcmeClient service running.
• IIS installed, with a site (for example, Default Web Site) listening on port 80 for the hostname you are securing.
• The domain’s A record points at this host and port 80 is publicly reachable from multiple regions worldwide under MPIC requirements.

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. For HTTP-01, the most common failures are port 80 reachability, firewall rules, and using standalone when IIS already owns port 80.
3. Post-issuance installation — the issued certificate is installed and bound to your IIS site on port 443. On Windows this usually requires a one-time IIS bootstrap before the first install.

The two DCV methods

You choose one DCV challenge method per request:

• 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).
• 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.

This walkthrough uses HTTP-01. For DNS-01 on Linux with NGINX, see NGINX with DNS-01.

Step 1: Prepare IIS for installation

On Windows, the native 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 before your first production install. 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 production enroll swaps the placeholder for the real, publicly trusted certificate.

$site    = "Default Web Site"
$dnsName = "example.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 example.com:

protocol bindingInformation    sslFlags
-------- ------------------    --------
https    *:443:example.com          1

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

Step 2: Run a production request

The example below requests a single-domain certificate using HTTP-01 validation through your running IIS and installs the issued certificate into IIS—so this one command covers all three choke points (EAB, DCV, and install) after bootstrap.

# Production 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_EAB_KEY_ID" `
  --eab-hmac "YOUR_EAB_HMAC_KEY" `
  --auto-ari-renew=true `
  --cn "example.com" `
  --challenge-type "http-01" `
  --challenge-handler-name "iis" `
  --installer-handler-name "iis" `
  --installer-handler-args "hostname=example.com"

• --challenge-handler-name "iis" integrates with IIS to serve the HTTP-01 token—no extra handler arguments.
• Port 80 must be publicly reachable. DigiCert validates under MPIC from multiple network vantage points around the world—at least four global regions, not just North America. 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 IIS installer uses hostname=<domain> in --installer-handler-args (the NGINX installer uses identifier=).
• To issue without installing, drop the two --installer-handler-* flags.

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 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 three choke points:

1. ACME account registration / EAB binding
2. Order creation and authorization
3. Challenge (DCV) — HTTP-01 token served through IIS, 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: 3

Key signals of success:

• Handler validation successful — the challenge handler (here, IIS HTTP-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, HTTP-01 challenge, validation, finalize, certificate storage, and IIS install (trimmed for readability):

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: http-01 with handler: iis
INFO  Authorization completed with status: valid for identifier: example.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>\example.com
INFO  Processing certificate installation with handler: iis
   Found matching allIPPort binding ... https *:443:example.com  SslFlags 1
   Updating existing SNI SSL binding: example.com:443 ... replacing placeholder certificate
   certificate installed successfully to binding: example.com:443
INFO  ACME request status updated successfully - Status: COMPLETED
INFO  Processing enrollment request - COMPLETED SUCCESSFULLY

Confirm success in the client and CertCommand

Check the local request status:

dc-acme request list

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

For a production ACME Directory URL, the issued certificate should also appear in CertCommand under Certificates > Orders. That is your account-level confirmation that issuance succeeded and the order is tracked for billing and lifecycle management.

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

Production certificates use your product’s normal validity period—not the fixed 3-day lifetime of sandbox test certificates.

On renewals, re-run the same enroll command; the installer swaps in the new certificate. No bootstrap is needed again.

Verify and troubleshoot

When the log shows COMPLETED SUCCESSFULLY and the order appears in CertCommand, confirm the certificate is live over HTTPS—see Verify HTTPS is live — IIS. Production certificates use your product’s normal validity period, not the 3-day sandbox lifetime.

If something fails, the log is the authoritative signal. See Verify and Diagnose ACME Requests for EAB, HTTP-01 DCV, and IIS install failure signatures. The most common install failure is running the native IIS installer without the one-time bootstrap—there must be a *:443:<hostname> binding with a certificate for the installer to update.

Optional: config file

If you prefer shorter repeat enrolls or the same settings on multiple servers, see Configuration (dc-acme.toml). You do not need to re-run enroll on this certificate—--auto-ari-renew=true already registered automatic reissues and renewals.

Configuration (dc-acme.toml) »

Related topics

• Sandbox Walkthrough (Windows/IIS) — Practice the same flow safely before production
• NGINX with HTTP-01 — Linux production walkthrough
• Create an ACME Directory URL — Production and sandbox URLs
• 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 Production CLI Examples