How to Issue an IIS Certificate with CertLocker ACME and win-acme

ACME is usually associated with public certificate authorities such as Let's Encrypt, but the operational value is broader than that. If your certificate management platform exposes an ACME-compatible endpoint, existing web server tooling can pull certificates directly from that platform using a standard protocol.

CertLocker now supports that model. The ACME directory endpoint is available at https://trust.certlocker.io/rest/acme/directory, and the same capability can run from an in-house CertLocker installation when the ACME endpoint needs to stay inside your own environment.

This walkthrough shows the IIS path using win-acme. In the validation run, win-acme connected to CertLocker, created an ACME order, downloaded the issued certificate, installed it into the Windows certificate store, updated the IIS HTTPS binding, and created the scheduled renewal task.

What this setup gives you

Standard client integration: win-acme talks to CertLocker through ACME, so IIS does not need a custom CertLocker-specific agent.
Token-scoped issuance: Certificate issuance is controlled by a CertLocker token with token type set to CERTIFICATE and the ACME protocol enabled.
Windows-native installation: win-acme installs the issued certificate into the Windows certificate store and updates the selected IIS HTTPS binding.
Automatic renewal: win-acme creates the scheduled renewal task as part of the normal IIS certificate flow.
Auditability: CertLocker records the ACME lifecycle, including registration, new order, certificate download, and token changes.

Prerequisites

Before starting, make sure the Windows server already has IIS installed, the target website exists in IIS, DNS points the hostname at the server, and win-acme is installed on the machine that manages the IIS binding.

You also need a CertLocker certificate token that is allowed to issue through ACME. The important settings are:

Token type: CERTIFICATE
Protocol: ACME
Scope: limited to the certificate or hostname pattern the IIS server should be allowed to request
Endpoint: https://trust.certlocker.io/rest/acme/directory, or your internal CertLocker ACME directory URL

CertLocker create token modal with certificate token and ACME enabled — A CertLocker certificate token with ACME enabled controls which certificate requests win-acme can make.

Step 1: Point win-acme at the CertLocker ACME directory

Run win-acme from an elevated PowerShell or Command Prompt on the IIS server. To use CertLocker instead of the default public ACME provider, pass the CertLocker ACME directory as the base URI:

wacs.exe --baseuri https://trust.certlocker.io/rest/acme/directory

If you are using an in-house CertLocker installation, replace the URL with that installation's ACME directory endpoint. From this point on, the win-acme flow is the normal IIS flow: choose the IIS source, select the site or binding, complete validation, and let win-acme install the certificate.

win-acme connecting to trust.certlocker.io ACME directory — win-acme connects to the CertLocker ACME directory and starts the ACME account/order flow.

Step 2: Select the IIS site and complete issuance

In interactive mode, win-acme detects IIS sites and lets you choose the target host. For the validation run, the target binding was iis.certlocker.io:443. win-acme created the ACME order, retrieved the issued certificate from CertLocker, stored it in Windows, and created the renewal task.

The key operational point is that IIS never needs a manually downloaded certificate file. The ACME client handles the issuance request and the Windows/IIS installation path as one workflow.

win-acme completed certificate install and renewal task creation — The completed win-acme run shows certificate installation and renewal task creation.

Step 3: Verify the IIS HTTPS binding

After issuance completes, open IIS Manager and inspect the HTTPS binding for the site. The binding should reference the new certificate installed by win-acme. This confirms that the certificate is not just issued, but actually attached to the live IIS endpoint.

IIS HTTPS binding showing installed CertLocker certificate — The IIS HTTPS binding was updated for the target hostname using the newly issued certificate.

For production, verify the live endpoint with a CertLocker probe. A probe checks the host and port from outside the IIS server, so renewal success is confirmed against the certificate actually being served, not just the certificate stored locally in Windows.

CertLocker create probe modal for iis.certlocker.io on port 443 — A CertLocker probe monitors the IIS endpoint on port 443 and links the check back to the managed certificate.

CertLocker probe list showing active IIS probe for iis.certlocker.io — The active probe gives the team an external signal that the IIS HTTPS endpoint is reachable and under monitoring.

Step 4: Confirm the CertLocker audit trail

The CertLocker side should show the ACME lifecycle events. In the validation run, the audit log recorded token changes, ACME registration, new order creation, and certificate download activity.

CertLocker audit log with ACME register, order, and download success events — CertLocker audit logging records the ACME register, order, and certificate download events.

This is the control-plane advantage of putting ACME behind CertLocker. IIS gets the standard client workflow, while the platform team keeps centralized visibility over which token requested which certificate and when.

Operational notes

Use scoped tokens: Create separate tokens for separate services, environments, or teams. Avoid broad tokens that can issue unrelated hostnames.
Keep renewal automatic: Do not treat the first issuance as the finish line. Confirm that the scheduled win-acme renewal task exists and is monitored.
Prefer internal endpoints when required: If policy prevents IIS servers from talking to trust.certlocker.io, run the same ACME capability from the in-house CertLocker installation.
Monitor the served certificate: Use CertLocker probes to alert on renewal failure, endpoint failure, or an unexpected served certificate, not only on certificates nearing expiry.

Summary

CertLocker ACME support means Windows IIS can use the same automated certificate workflow that infrastructure teams already expect from ACME clients. win-acme connects to the CertLocker directory, requests the certificate under token control, installs it into Windows, updates the IIS HTTPS binding, and creates the renewal task.

The result is a cleaner model: CertLocker remains the central certificate control plane, while IIS keeps using a native Windows-friendly ACME client for installation and renewal.