Skip to content


  • The preliminary validation check for DNS validation plugins now queries one of the domain's authoritative name servers (just like Let's Encrypt does) rather than a public OpenDNS server. This was contributed by @davidpeden3 in #1053 and #1061. The DnsServer setting still overrides this behavior, so that setting has to be emptied on existing installs to trigger this behavior. For new deployments it is default behavior.
  • It's now possible to have emails sent for successful renewals as well, using the EmailOnSuccess setting. They will be sent with low priority, whereas failures get a high priority flag.
  • There is a new setting called DeleteStaleCacheFiles which instructs the program to delete cached certificate files older than 120 days. Being that old they should be long-expired, meaning the renewals that once generated them have been cancelled or have at least been failing for a couple of months. Use with caution though, especially when you've pointed your CertificatePath to some custom location!

Bug fixes

  • #1048 - Some of the settings in settings_default.config were misnamed, reported by @qpple.
  • #1049 - When using the DnsScript plugin in interactive mode it was not possible to actually override the parameters for the delete script, reported by @Virinum
  • #1050 - Fix non-fatal exception in the FTP and WebDav plugins
  • #1051 - Fix failing DnsScript validation on specific token values (starting with -) that would confuse the Powershell command line interpreter, reported by @highstrike
  • #1052 - Fix crash when using PemFiles store plugin for certificates with a wildcard as CommonName, reported by @highstrike
  • #1056 - The failure notification email was not sent for every type of failure, reported by @kabilan-baskaran


If you want professional support for WACS or just want to buy me (@WouterTinus) a beer for maintaining this tool, please check out my Patreon page.

Assets 5
Mar 9, 2019
bump version

@WouterTinus WouterTinus released this Feb 28, 2019


  • @sstaszkiewicz-copperleaf fixed some logic errors in the DNS validation script plugin (#1047) that caused it to misbehave when certain combinations of parameters were provided. I have added 5 additional unit tests to make sure this doesn't happen again.
Assets 5

@WouterTinus WouterTinus released this Feb 25, 2019


  • The script installer plugin can now run Powershell scripts directly by invoking powershell.exe. Previously this would need to be done by starting a .bat file and having the batch file start the .ps1. That was obviously needlessly complicated, especially when it was required to pass parameters.


  • #1044 --sslipaddress and --sslport were being ignored, reported by @appelgran
Assets 5

@WouterTinus WouterTinus released this Feb 23, 2019


Add default choices for different questions and options in interactive mode, making especially the advanced creation process a lot smoother (#1035 and other ideas)


#1037 - prevent null reference on bindings without endpoint, reported by @Babene03
#1034 - incorrectly set SNI flag on default binding, reported by @perryanton
#1035 - do not ask user to choose common name when only one option is available, reported by @fearworksmedia

Assets 5

@WouterTinus WouterTinus released this Feb 21, 2019

This is the first stable release of win-acme (WACS) 2.0, the long expected ACMEv2 version of one of the oldest and simplest Windows based tools to generate Let's Encrypt certificates.


WACS has always promised to be a simple tool, so backwards compatibility and ease of use has been a big focus for the past couple of years. The goal has always been to allow xcopy upgrades, enabling admins to roll out more useful and reliable versions without worrying about the details.

Current circumstances have forced our hand though. With ACMEv2, the ISGR has re-invented the protocol, enabling among other things new features such as the much sought wildcard certificates (see #464). This in turn inspired @ebekker to re-architect his excellent ACMESharp library.

With sufficient time and attention we could write code that would remain fully compatible with existing ACMEv1 renewals, while at the same time offering ACMEv2 to new and advanced users. The reason to not choose that approach is that we actually want to use the opportunity to do some housekeeping ourselves, instead of piling on a whole new level of abstraction with all the exceptions and possible failure modes that would entail.

So, going forward we will have the 1.9.x series on 'life support' for ACMEv1 users. That means that there will most likely not be any active development on it except for critical bug fixes. Besides that we will have 2.x in active support and development for ACMEv2 users. We're making it very easy to upgrade though, by offering an option in the main menu and the command line to import certificate settings from 1.9.x.

Major improvements

  • ACMEv2 protocol support including wildcard certificates.
  • Create fully modern certificates with the OCSP Must Staple extension and/or ECDSA private keys, made possible thanks to having full control over the certificate signing requests, which were previously handled by a third party library.
  • In 1.9.x we were constrained by backward compatibility to really clean up our act regarding the way renewals were defined, which prevented us from implementing even some basic features like setting a custom Friendly Name. 2.x has a re-invented renewal and plugin system which is more easily usable by man and machine alike. Each renewal is defined in a separate human-readable .json file on disk, that can be moved around between machines, backed up and edited. This opens a whole new way of interacting with the program, both by humans and other scripts/tooling.
  • Renewals have become smarter. Rather than only looking at the date, renewals automatically become due for renewal when changes in the target are detected. When you add or update a binding in IIS, it's no longer necessary to force a renewal.
  • For the first time some parts of the code have automatic tests written for them. Currently the tests are limited to the target acquisition part but we expect the number of tests will rise in the future, preventing recurring bugs. In the long run this will improve the quality of the tool.
  • There is increased security. By default we no longer write the .key.pem file to disk (for Apache and ngnix users this is still possible though with a new store plugin). We also protect the .pfx files in the cache folder with randomly chosen 256-bits passwords. The passwords themselves are in the aforementioned .json files encrypted with Microsoft's DPAPI. The same goes for FTP/WebDav credentials and of course the digital signature that functions as the 'password' for the ACME account. With these measures in place someone that gains access to the files in the ConfigPath and/or CertificatePath has a lot fewer options for abuse.
  • IDN support has been much improved, including for features like excluded domains, common names, etc.
  • You are now able to configure email notifications to be alerted about failing renewals long before Let's Encrypt starts warning you.

New plugins

The most sought after feature for ACMEv2 is the support for certificates with wildcard identifiers, e.g. * Such identifiers can only be validated using the DNS-01 method. That is a difficult one to automate, because there are thousands of different providers. Besides support for writing your own scripts (which was already a feature of 1.9.x, we have made the following improvements

  • Azure has been refactored as separate project and download. This serves as an example/template for others to contribute plugins to WACS.
  • Manual will obviously won't work for automatic renewals, but can be a stop gap measure.
  • acme-dns is a client for the acme-dns server project, the idea here is to CNAME the _acme-challenge record to a self-hosted or otherwise trusted acme-dns instance and let win-acme handle the legwork required to update the tokens.
  • Dreamhost was contributed by @derhally as another example of how to extend win-acme.
  • 'Script` was refactored to be much more flexible with regards to parameter format and the option to reuse the same script for both create and delete.

Breaking changes

  • No more ACMEv1 support. The 1.9.x series will be there if you need it though.
  • Requires .NET Framework 4.7.2 - up from 4.6.2.
  • Custom plugins that you may have written will have to be updated to support the new interfaces. I do not expect any major difficulties, read Custom plugins for more info.
  • Validation
    • Support for TLS-SNI validation has been removed. Let's Encrypt has not supported this validation mode for new accounts and domains for a while now, but if you had successfully validated using this method in the past, it would still allow you to renew that way on the old endpoint. It's no longer possible on the newer one. Imported renewals will automatically be converted to SelfHosting validation. Note that this requires port 80 instead of 443 to be accessible, so it might fail - but it's the best alternative we can offer at this point.
    • Support for IIS validation has been removed. While working fine, it was superfluous with the far simpler and less risky SelfHosting option. Imported renewals will automatically be converted.
  • The CertificatePath by default is now [ConfigPath]\Certificates instead of ConfigPath.
  • Installation
    • The script installer has been renamed from manual to script
  • We no longer output .csr-gen.json and .key-gen.json files for each certificate. I honestly couldn't come up with a use case for them, though if someone has one, please let us know!
  • The main executable has been renamed from letsencrypt.exe to wacs.exe. Let's Encrypt is an ISGR registered trademark and WACS supports different implementations of the ACME protocol (#763, #978)
  • Settings
    • The private key will not exportable from the Windows Certificate store by default (#369)
    • The .key.pem file will not be saved to disk by default, if you need it use --store pemfiles
    • The PFXPassword property has been removed. The passwords for the cache are randomly generated and password for the IIS CCS can be provided on the command line per certificate.
    • Default RSA key length increased from 2048 to 3072 bits, because why not?
  • Command line changes
    • --forcerenewal has been renamed to --force and cannot be used standalone anymore
    • --plugin has been renamed to --target to more accurately reflect what it does
    • --manualhost has been renamed to --host because it can also be used for the IISBinding plugin
    • --centralsslstore is no longer enough to trigger the IIS CCS plugin, it has to be activated properly by adding --store centralssl
  • Settings changes
    • Default date formatting makes a lot more sense now
    • Default ACME endpoints for regular use, test use and importing can be configured
    • Default paths can be configured for the CentralSsl plugin and the PemFiles plugin
Assets 5

@WouterTinus WouterTinus released this Feb 13, 2019

This was an AppVeyor test. v2.0.0-beta2 is still the most recent build.

Assets 2
You can’t perform that action at this time.