# win-acme: an ACMEv2 client for Windows IIS, Exchange and RDS > win-acme is a C# ACMEv2 client that issues and renews certificates on Windows, installs them into IIS and other services, and schedules its own renewals. It is aimed at administrators who want unattended certificate handling on machines that are not Linux web servers. **win-acme/win-acme** — Automate SSL/TLS certificates on Windows with ease - Repository: https://github.com/win-acme/win-acme - Website: https://www.win-acme.com/ - Stars: 5,804 · Forks: 870 - Language: C# - License: Apache-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/win-acme-win-acme ## The Windows certificate problem win-acme addresses ACME clients grew up around Linux web servers. Certbot and its relatives assume a filesystem layout, a web server you can reload, and a cron daemon. Windows has none of those in the same shape. Certificates need to be bound to IIS sites, dropped into the IIS Central Store, or imported into Exchange and RDS listeners, and renewal has to happen through the Task Scheduler rather than cron. win-acme is a C# ACMEv2 client built for that environment. The README describes it as aiming to be "very simple to start with, but powerful enough to grow into almost every scenario", and the two-interface design reflects that: a guided console flow for a local IIS server, and a more advanced flow for Apache, Exchange and other targets. The audience is Windows administrators, not developers writing certificate automation from scratch. The topics list on the repository (iis, exchange, rds, winrm) points at the same audience. ## How win-acme issues, validates and installs a certificate The flow is the standard ACMEv2 sequence, wrapped in Windows-specific steps. You pick a certificate source (Let's Encrypt, ZeroSSL, DigiCert, Sectigo, Buypass, Keyon and others are named in the README), the tool creates an order, and you complete a challenge. win-acme ships what the README calls an advanced toolkit for DNS, HTTP and TLS validation, including SFTP/FTPS, acme-dns, Azure, Route53 and Cloudflare. DNS validation matters here because it is the only route to a wildcard certificate such as *.example.com, which the README lists alongside international names and the optional OCSP Must Staple extension. Once validation succeeds, the certificate is stored where you asked: the Windows certificate store, the IIS Central Store, .pem files, a .pfx file or KeyVault. Installation is a separate concern from issuance, and the README notes you can write your own PowerShell .ps1 scripts for installation and validation, or build plugins in C#. Renewal is handled by a scheduled task that the tool creates automatically. That task is the piece that makes the whole thing unattended, and it is also the piece you should inspect on a new machine before trusting it. ## Installing win-acme and running a first renewal The README gives two installation routes. The first is a zip download: unpack it to a location on disk and run wacs.exe. The second requires .NET Core, installs the tool globally, and then invokes the same executable. In both cases the entry point is wacs.exe, and the interactive menu drives the simple IIS scenario. ```bash dotnet tool install win-acme --global wacs.exe ``` After the second command you get the guided console interface. Choosing the simple option walks through site selection, hostname confirmation and validation, then writes the certificate and creates the scheduled task. For unattended operation the README states the tool supports completely unattended operation from the command line, which is what you want on a server where nobody is watching the console. The README also mentions automation through manipulation of .json files, which is the route to take when the same configuration has to be applied across several machines. On a first run, watch which store the certificate lands in and confirm the IIS binding actually changed; the tool reports what it did, but the binding is the part that decides whether browsers see the new certificate. ## Where win-acme is the wrong tool The clearest boundary is platform. This is a Windows client. If your certificates terminate on nginx or Apache on Linux, an ACME client native to that platform is a better fit, and nothing in the README suggests win-acme is intended for that case. A second boundary is architecture: if TLS terminates at a load balancer or CDN, the certificate belongs there, not on the individual Windows host, and installing win-acme per server would multiply certificate orders for no benefit. A third is validation reachability. DNS and HTTP challenges both depend on something being reachable from the ACME service's perspective, and the README's list of DNS providers is long but finite. If your DNS provider is not among the supported plugins, you are looking at writing a PowerShell script or a C# plugin, which is real work rather than configuration. Finally, renewal depends on the scheduled task the tool creates. The README does not document rollback, so if a renewal installs a certificate that breaks a binding, recovering means going back to the previous certificate manually. ## win-acme compared with simple-acme and certbot People searching for win-acme often arrive comparing it with simple-acme, and the two are related in a way that is easy to miss: the repository is maintained by ZeroSSL, and simple-acme is a fork of the same codebase. The practical difference is where each one is steered. win-acme is the upstream project with the ZeroSSL backing described in the README, while simple-acme exists as a separate distribution of the same lineage. If you are choosing between them, the question is which one's release cadence and plugin set you want to depend on, not which one supports ACMEv2, because both descend from the same client. Against certbot the difference is sharper. Certbot targets Unix-like systems and their web servers; win-acme targets IIS, Exchange and RDS, and its installation step is a Windows executable or a .NET global tool rather than a package manager entry. Choosing certbot on Windows means fighting the platform; choosing win-acme on Linux means the same in reverse. ## Maintenance, releases and licence The repository is not archived, and the last push was on 2026-06-09. The most recent release listed is v2.2.9.1701 (v2.2.9.1) from 2024-05-25, following v2.2.9.1680 on 2024-05-16 and v2.2.8.1635 on 2024-02-27. That gap between the last push and the last tagged release is worth noting if your upgrade policy depends on tagged versions rather than on the master branch: the commit history is more recent than the release history. The project is licensed under Apache-2.0, which permits commercial use and modification and requires that the licence and notices be preserved; the LICENSE file sits at the repository root. Because the tool issues certificates through third-party ACME services, the terms that matter most in practice are those of the certificate authority you point it at, not the Apache-2.0 grant covering the client. The README points readers to the manual before seeking support, and support requests are directed there rather than to a paid channel. ## Conclusion Adopt win-acme if you run IIS, Exchange or RDS on Windows and want renewal handled by a scheduled task rather than by hand. Do not adopt it if your certificates live on Linux web servers or behind a load balancer that already terminates TLS, because the tool's value is in binding certificates to Windows services. Before rolling it out, verify that your validation method works from the machine that will run the renewal task, since DNS and HTTP challenges depend on reachable endpoints, and check the manual for the plugin matching your DNS provider. ## FAQ ### Is win-acme deprecated? The repository is not archived, and the last push was on 2026-06-09, so there is no indication in the repository metadata that the project has been abandoned. The README describes it as officially maintained by ZeroSSL. ### What is win-acme? It is an ACMEv2 client for Windows written in C#. The README says it aims to be very simple to start with but powerful enough to grow into almost every scenario, covering IIS, Apache and Exchange. ### How do I install win-acme? The README gives two routes: download the .zip, unpack it to a location on your hard disk and run wacs.exe, or install .NET Core, run dotnet tool install win-acme --global and then wacs.exe. ### Is win-acme free and open source? The repository is licensed under Apache-2.0, with the LICENSE file at the repository root. The certificates themselves come from the ACME service you choose, and the README lists several providers. ### What are the differences between simple-acme and win-acme? Both descend from the same codebase, and win-acme's repository is maintained by ZeroSSL. The practical difference comes down to which distribution's release cadence and plugin set you depend on, since both support ACMEv2. ### What is an ACME certificate? ACME is the protocol win-acme uses to obtain certificates automatically from services such as Let's Encrypt, ZeroSSL, DigiCert, Sectigo, Buypass and Keyon. The certificate itself is issued by the chosen authority; ACME is the exchange that requests and validates it. ## Sources - [License: Apache-2.0](https://github.com/win-acme/win-acme/blob/master/LICENSE) - [Project website](https://www.win-acme.com/) - [README](https://github.com/win-acme/win-acme/blob/master/README.md) - [Releases](https://github.com/win-acme/win-acme/releases) - [win-acme/win-acme on GitHub](https://github.com/win-acme/win-acme) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/win-acme-win-acme