win-acme on IIS: Let's Encrypt SSL Setup & Renewal (2026)

In short

To install a free Let's Encrypt SSL certificate on IIS with win-acme, first make sure the website works over HTTP, the hostname resolves to your Windows Server, and TCP 80 is reachable for HTTP-01 validation. Then run wacs.exe, select the IIS site, let the client create the HTTPS binding, and verify the renewal task.

There is one important 2026 update: win-acme's last release line is 2.2.9.1, while simple-acme is now the actively maintained successor from the same maintainer and is designed as a backwards-compatible, drop-in replacement. Existing win-acme installations can still follow this guide. For a brand-new deployment, also evaluate simple-acme before you standardize on win-acme.

Quick verdict

The certificate request itself is usually the easy part. Most failures come from DNS, IIS bindings, HTTP validation, or renewal configuration.

What is win-acme?

win-acme is an ACMEv2 client for Windows. It can request SSL/TLS certificates from certificate authorities such as Let's Encrypt, store them in Windows, update IIS HTTPS bindings, and create a scheduled task to renew certificates automatically.

That IIS integration is why win-acme became popular for Windows Server administrators: you can go from an HTTP IIS binding to a Let's Encrypt certificate and automatic renewal without manually exporting and rebinding a new certificate every few months.

Is win-acme still current in 2026?

The final win-acme release line is 2.2.9.1. The project has since been succeeded by simple-acme, which the maintainer describes as the technical and spiritual successor to win-acme and a backwards-compatible drop-in replacement.

For this reason:

• If win-acme is already installed and renewing certificates correctly, you do not need to replace it just to complete this guide.
• If you are building a new IIS server in 2026, compare win-acme with simple-acme before you standardize your automation.
• If you migrate, test all renewals after the change instead of assuming that an old scheduled task still points to the right executable and configuration.

This guide keeps win-acme as the primary workflow because many administrators still search for and operate existing win-acme installations.

What we tested on Raff

We tested the IIS and win-acme workflow on a Raff Windows VPS running Windows Server with IIS installed.

In the lab, we verified:

• IIS installed and running
• IIS bindings visible from PowerShell
• Windows Firewall rules for HTTP and HTTPS
• win-acme starting successfully
• connection to the ACME service
• the expected certificate creation and IIS binding workflow
• the renewal and scheduled-task workflow

Some certificate creation screenshots in this guide are illustrative examples. In production, use your real hostname and verify DNS before requesting a certificate.

What you'll need

• A Windows Server 2022 or Windows Server 2025 VPS
• Local administrator access over RDP
• IIS installed with at least one working site
• A public domain or subdomain, such as app.example.com
• DNS access for that domain
• TCP 80 reachable for the HTTP-01 workflow used in this guide
• TCP 443 reachable for the final HTTPS service
• win-acme already installed, or an ACME client selected for a new deployment
• About 30-45 minutes for the first setup and validation

This guide assumes your IIS site works over plain HTTP before certificate issuance.

If you still need the Windows server itself, you can deploy a Raff Windows VPS first, point your hostname to its public IP, and then continue with the IIS and SSL steps below.

Step 1 - Confirm IIS is installed and running

Open PowerShell as Administrator:

Get-WindowsFeature -Name Web-Server
Get-Service W3SVC

Expected result:

Web-Server  Installed
W3SVC       Running

If IIS is not installed:

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Then verify again:

Get-Service W3SVC

If you are hosting ASP.NET Core, install the appropriate .NET Hosting Bundle before you finish the application deployment.

Do not start certificate troubleshooting while IIS itself is not serving the site correctly.

Step 2 - Check the IIS hostname binding

The default IIS workflow works best when the website has the real hostname you want to secure.

Check the current bindings:

Import-Module WebAdministration
Get-WebBinding | Select-Object protocol, bindingInformation

A blank HTTP binding looks like this:

http     *:80:

A hostname-specific binding looks like this:

http     *:80:app.example.com

If the site has no hostname binding, add one:

New-WebBinding -Name "Default Web Site" -Protocol http -Port 80 -HostHeader "app.example.com"

Replace the site name and hostname with your own values.

Verify it:

Get-WebBinding -Name "Default Web Site" | Select-Object protocol, bindingInformation

If win-acme reports that no websites with host bindings are configured, this is one of the first things to check.

Advanced/manual ACME workflows can use other source methods, but the simple IIS path is easiest when IIS already contains the hostname you plan to secure.

Step 3 - Point DNS to the Windows VPS

Create or verify the DNS record for the hostname.

Verify from the server:

Resolve-DnsName app.example.com

You can also verify from another machine:

nslookup app.example.com

The returned public IP should be the server that will answer the ACME validation request.

Do not continue if DNS still points to an old server, load balancer, proxy, or another machine that is not prepared to serve the validation challenge.

Step 4 - Make HTTP-01 validation reachable

This guide uses HTTP-01, which requires the ACME server to retrieve a challenge over TCP port 80.

Enable the standard IIS firewall rules if needed:

Enable-NetFirewallRule -DisplayName "World Wide Web Services (HTTP Traffic-In)"
Enable-NetFirewallRule -DisplayName "World Wide Web Services (HTTPS Traffic-In)"

Confirm them:

Get-NetFirewallRule -DisplayName "World Wide Web Services (*Traffic-In)" |
    Select-Object DisplayName, Enabled, Direction, Action

Test port 80 from another machine:

Test-NetConnection app.example.com -Port 80

Expected result:

TcpTestSucceeded : True

If it returns False, check:

• Windows Firewall
• any provider-side or network firewall
• DNS
• IIS site state
• reverse proxies or CDN settings in front of the server

Do you always need port 80?

No. HTTP-01 uses port 80. A DNS-01 workflow validates domain ownership through DNS TXT records instead and is required for wildcard certificates. This article focuses on HTTP-01 because it is the simplest path for a normal IIS hostname.

Step 5 - Download win-acme from an official source

The search query "win-acme download" has meaningful demand, so this step deserves a clear answer: use the official project website or its official GitHub releases page. Do not download certificate-management executables from third-party mirrors unless you have a specific reason and can verify the package.

For the classic win-acme build, the documented x64 package is the normal choice for modern Windows Server systems.

The win-acme documentation recommends extracting the application to a non-temporary folder, for example:

C:\Program Files\win-acme

The reason is operational, not cosmetic: the scheduled renewal task needs the executable to remain at the same path.

If you prefer a shorter custom path, this is also workable:

C:\Tools\win-acme

Whichever path you choose, keep it permanent.

Run the client as Administrator:

Set-Location "C:\Tools\win-acme"
.\wacs.exe

Our original test used win-acme 2.2.9.1701, which belongs to the 2.2.9.1 release line.

New deployment in 2026?

simple-acme is the actively maintained successor and is described by its maintainer as a backwards-compatible drop-in replacement for win-acme. If you are not tied to an existing win-acme installation, review simple-acme before choosing the client for a new long-lived server.

Step 6 - Create the Let's Encrypt certificate

From the win-acme folder:

.\wacs.exe

For the normal local-IIS workflow, choose:

N: Create certificate (default settings)

The default flow is intended for a regular, non-wildcard certificate on the local IIS instance.

Then:

1. Select the IIS site or binding for the hostname.
2. Confirm the hostname is correct.
3. Use the ACME certificate authority configured by the client, such as Let's Encrypt.
4. Accept the subscriber agreement when prompted.
5. Enter an operations email address you monitor.
6. Allow the client to install the certificate and update IIS.
7. Allow it to create the renewal task.

A successful flow looks similar to:

Authorization result: valid
Requesting certificate
Success
Installing certificate in the certificate store
Adding https binding *:443:app.example.com
Adding task for automatic renewal
Certificate created successfully

Your hostname, site ID, timestamps, thumbprint, and renewal date will be different.

Step 7 - Verify the HTTPS binding in IIS

After issuance, verify that the certificate is actually connected to the IIS site.

PowerShell:

Get-WebBinding -Name "Default Web Site" |
    Select-Object protocol, bindingInformation, certificateHash

You should see an HTTPS binding for the hostname:

http     *:80:app.example.com
https    *:443:app.example.com

You can also check in IIS Manager:

IIS Manager -> Sites -> Your site -> Bindings

If you host multiple HTTPS sites on one IP address, also verify the hostname/SNI configuration rather than assuming that port 443 alone is enough.

Step 8 - Test HTTPS from outside the server

Test locally from the server if useful:

Invoke-WebRequest "https://app.example.com" -UseBasicParsing

A healthy HTTP response should normally return a successful status code.

Then test from a separate client or phone:

https://app.example.com

Check:

• the certificate is valid
• the hostname matches
• the browser is not receiving an old certificate from another proxy/server
• the page loads over HTTPS without redirect loops

If IIS is still presenting an unexpected certificate, review the bindings first. Restart IIS only when you actually need to refresh the site state:

iisreset

Step 9 - Verify automatic renewal

Automatic renewal is one of the main reasons to use an ACME client. A certificate that works today but never renews is not a finished setup.

win-acme creates a scheduled task after the first successful certificate configuration. Its renewal process checks certificates regularly and renews only when needed.

List configured renewals:

.\wacs.exe --list

Check the Windows scheduled task:

Get-ScheduledTask | Where-Object TaskName -like "*win-acme*" |
    Select-Object TaskName, State, TaskPath

If the task is missing, win-acme exposes a command-line option to create or update it:

.\wacs.exe --setuptaskscheduler

Test renewal properly

Running only --renew processes certificates that are due. That means a healthy certificate may do nothing, which is expected.

For an explicit renewal test, use:

.\wacs.exe --renew --force --verbose

Use a forced renewal carefully because it performs real renewal work. While troubleshooting issuance logic, use the client's test/staging mode rather than repeatedly requesting production certificates.

Review the client logs and Windows Event Viewer if a scheduled renewal fails.

Step 10 - Understand test mode and rate limits

The --test switch enables test behavior and switches the client to an ACME test endpoint by default. It is useful while debugging certificate creation or automation without repeatedly consuming production issuance attempts.

For example, start the client in test mode and follow the certificate creation workflow:

.\wacs.exe --test

Use production only after DNS, IIS bindings, validation, and firewall behavior are correct.

Let's Encrypt also applies rate limits. Do not solve a configuration problem by repeatedly retrying production issuance without first finding the underlying validation error.

Optional - Unattended win-acme setup for IIS

After the interactive workflow works correctly, you can automate certificate creation.

Example:

Set-Location "C:\Tools\win-acme"

.\wacs.exe `
    --source iis `
    --siteid 1 `
    --host app.example.com `
    --validation selfhosting `
    --store certificatestore `
    --installation iis `
    --accepttos `
    --emailaddress admin@example.com

Do not copy this command unchanged into production. Confirm the site ID, hostname, validation method, store, and installation behavior for your server first.

What about wildcard certificates?

A wildcard such as:

*.example.com

cannot be validated with HTTP-01 at Let's Encrypt. Wildcard certificates require DNS-01 validation.

That means you need either:

• an ACME DNS plugin for your DNS provider, or
• another safe automation method that can create the required TXT record

If you only need app.example.com, the normal IIS + HTTP-01 workflow is simpler. Do not add wildcard complexity unless you actually need it.

Common win-acme and IIS errors

"No websites with host bindings have been configured in IIS"

Check:

Get-WebBinding | Select-Object protocol, bindingInformation

If the HTTP binding has no hostname, add the intended host header and retry the default IIS flow.

Authorization failed or challenge returned 404

Check DNS:

Resolve-DnsName app.example.com

Then confirm the HTTP challenge can reach the same server. URL Rewrite, authentication rules, IP restrictions, proxies, or application routing can interfere with the /.well-known/acme-challenge/ path.

Timeout during connect

Test port 80 from outside the server:

Test-NetConnection app.example.com -Port 80

If it fails, check Windows Firewall and any upstream firewall or network rule.

Browser still shows the old certificate

Check which system is actually terminating TLS. The certificate might be coming from:

• another IIS binding
• a reverse proxy
• a CDN
• a load balancer
• an old server that still receives traffic

Do not assume iisreset will fix a certificate that is being served somewhere else.

Renewal task exists but renewal fails

Run:

.\wacs.exe --renew --force --verbose

Then inspect the win-acme logs and Event Viewer. Also confirm that the executable still exists at the exact path referenced by the scheduled task.

The ACME client was installed in Downloads

Move it to a permanent application directory and then recreate or repair the scheduled task. Renewal automation should never depend on a temporary user download folder.

Troubleshooting commands

Check IIS bindings:

Get-WebBinding | Select-Object protocol, bindingInformation

Check DNS:

Resolve-DnsName app.example.com

Check port 80 from another Windows machine:

Test-NetConnection app.example.com -Port 80

Check what is listening locally on port 80:

Get-NetTCPConnection -LocalPort 80 -State Listen

Check URL reservations:

netsh http show urlacl

Check the WebHosting certificate store:

Get-ChildItem Cert:\LocalMachine\WebHosting |
    Sort-Object NotAfter -Descending |
    Select-Object Subject, NotAfter, Thumbprint

Check Personal if your certificate is stored there instead:

Get-ChildItem Cert:\LocalMachine\My |
    Sort-Object NotAfter -Descending |
    Select-Object Subject, NotAfter, Thumbprint

Check the scheduled task:

Get-ScheduledTask | Where-Object TaskName -like "*win-acme*" |
    Select-Object TaskName, State, TaskPath

What Raff recommends

For IIS SSL on a Windows VPS:

1. Make the IIS site work over HTTP first.
2. Add the exact hostname you want to secure.
3. Point DNS to the correct public IP.
4. Confirm TCP 80 is externally reachable for HTTP-01.
5. Keep the ACME client in a permanent folder.
6. Use the interactive IIS flow for the first certificate.
7. Verify the HTTPS binding after issuance.
8. Test HTTPS from outside the server.
9. Verify the scheduled renewal task.
10. Run a forced renewal test with verbose output before you consider the setup finished.
11. For a brand-new 2026 deployment, evaluate simple-acme as the maintained successor to win-acme.

The core lesson is simple: certificate issuance is not the first step. DNS, IIS bindings, validation reachability, and renewal are all part of a production-ready HTTPS setup.

Tested on

Originally tested on Raff Windows VPS, Windows Server 2025 Datacenter Evaluation, IIS 10, win-acme 2.2.9.1701, HTTP-01 validation workflow, 2026-05-26. Re-verified against current win-acme, simple-acme, Let's Encrypt, and IIS documentation on 2026-09-01. Tester: Serdar Tekin.

What's next

• Connect to a Windows VPS via RDP - connect to your server first
• Host ASP.NET Core on IIS - deploy the app before adding SSL
• IIS Application Pool Tuning for Production - tune app pools after deployment
• Configure Windows Firewall on a Windows VPS - manage inbound HTTP, HTTPS, RDP, and SQL rules
• Raff Windows VPS - deploy Windows Server for IIS, ASP.NET Core, SQL Server, and business applications

Sources

• win-acme official site: https://www.win-acme.com/
• win-acme GitHub repository and releases: https://github.com/win-acme/win-acme
• win-acme getting started: https://www.win-acme.com/manual/getting-started
• win-acme automatic renewal: https://www.win-acme.com/manual/automatic-renewal
• win-acme command-line reference: https://www.win-acme.com/reference/cli
• win-acme IIS installation plugin: https://www.win-acme.com/reference/plugins/installation/iis
• simple-acme official site: https://simple-acme.com/
• simple-acme GitHub repository and releases: https://github.com/simple-acme/simple-acme
• simple-acme validation reference: https://simple-acme.com/reference/plugins/validation/
• Let's Encrypt ACME client implementations: https://letsencrypt.org/docs/client-options/
• Let's Encrypt rate limits: https://letsencrypt.org/docs/rate-limits/
• Microsoft Learn - IIS bindings: https://learn.microsoft.com/en-us/iis/configuration/system.applicationHost/sites/site/bindings/binding

Date last verified: 2026-09-01