simple-acme and the cross platform ACME client forked from win-acme

A win-acme fork that changed its platform assumptions

simple-acme describes itself as a simple cross platform ACME client, for use with Let's Encrypt, forked from win-acme, and the project description names the protocol area it serves: ACME for certificate automation, with topics covering certificates, pem, pfx, rfc8555, letsencrypt, apache, iis, linux and windows.

The fork origin explains most of the design. win-acme was built for Windows, and the way it acquired certificates was tied to how IIS, the Windows certificate store and the Windows renewal service work. simple-acme keeps that lineage, including the IIS flavour, and adds a cross platform build.

The topics list is a good inventory of what a certificate client touches in practice: pem and pfx are the two file formats an operator actually ends up with, and the fact that both appear as separate topics tells you the project deals with the conversion between them, which is the part of certificate work that is annoying outside Windows where a certificate store handles it for you.

The rfc8555 topic is worth noticing, because RFC 8555 is the current ACME specification and the one that replaced the earlier draft flows. Supporting it rather than the older account and authorization model is the difference between a client that talks to a current CA and one that does not.

So the project is a Windows-rooted tool that has been generalised rather than a ground-up cross platform client, and that history is visible in what it ships.

The README is a signpost, and the website is the documentation

The readme is short, and the reason is stated rather than implied.

The project asks you to check the website at simple-acme.com for an up-to-date overview, documentation and downloads, and to leave a star above. The support section makes the same point: if you have questions on how to use the program, first please check whether the issue is covered in the manual, and if you cannot find a solution that way, open a discussion in the Q&A section, and only open an issue if you are reasonably sure you have found a bug or your use case is not covered but would be a valuable new feature.

That is a deliberate division of labour. The repository holds the code, the manual lives on the site, and the issue tracker is reserved for defects. For an adopter, the consequence is that you cannot evaluate the tool from the repository alone. The manual at simple-acme.com/manual/getting-started is the first thing to read, and the readme says so before anything else.

The repository layout is consistent with a code-only home. There is a `src/` directory for the code, `build/` and `dist/` for the build and the produced artefacts, an `appveyor.yml` for continuous integration on the Windows build server, `.gitmodules` for submodules, and the usual governance files, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, `PULL_REQUEST_TEMPLATE.md` and `SECURITY.md`.

The presence of a `SECURITY.md` and a pull request template in a certificate client is a small but reasonable signal about how the project is run, and the appveyor configuration tells you the primary build path is Windows.

A .NET build and an IIS build, which is the fork's reason to exist

The project publishes two distinct builds, and the difference between them is the whole point of the fork.

There is a .NET flavour, which is the cross platform one, and an IIS flavour for Windows servers running Internet Information Services. The .NET build is the generic tool that talks to a CA over ACME and writes the resulting files to disk in whatever format the server needs. The IIS build is the one that knows about the Windows certificate store and the IIS certificate binding, so it can install the certificate into the running web server rather than leaving a .pfx file for you to import by hand.

That distinction explains the topic list, which names iis and apache separately, and it is the reason a Windows operator with IIS would reach for this rather than for a general purpose ACME tool built for a Linux container. The IIS build is the part that cannot be replaced by a containerised client.

The remaining question for a reader is what the ACME surface actually covers, and the readme does not say. The topics mention rfc8555, which identifies the protocol version, but the set of challenge types, the renewal behaviour, the account and key handling, and the plugin model are all in the manual rather than the repository.

For a security critical tool, that distribution of documentation is defensible, because documentation that lives with the code goes stale and documentation that is published separately can be updated for every release. It does mean the repository is not a place to evaluate the client, and a team that wants to know what happens on renewal has to go to the site.

Getting the client and running your first order

The readme gives no command to copy, and that is not an oversight. The installation path is the website: the project asks you to check simple-acme.com for an up-to-date overview, documentation and downloads, and the manual is at simple-acme.com/manual/getting-started.

So the sequence for a first run is: download the build for your platform from the site, read the getting started page in the manual, and run the client against the account for the CA you want to use. The repository does not describe the client invocation, the account registration step, or how the resulting files are written, so the manual is the only place those are described.

What the repository does tell you is the shape of the distribution, and it is enough to make a first decision. The `dist/` directory at the root is where the produced artefacts land, `build/` holds the build definition, and the `appveyor.yml` file shows that the primary continuous integration runs on AppVeyor, which is a Windows build service. For a Linux operator that is a signal to look for a published package or container rather than to build from source, and the site is where the download list lives.

The `src/` directory is where the code itself sits, and `.gitmodules` tells you that some dependencies are pulled in as submodules rather than vendored directly, which matters if you are planning to build from a mirror of the repository without network access to the upstream sources.

One thing worth doing before the first run is to read the section of the manual on your web server. The IIS flavour and the .NET flavour write their results in different ways, and picking the wrong build is the kind of decision that is easy to make and awkward to unpick once certificates are in place.

Support is routed to discussions first, and sponsorship is pitched at operators

Two things in the readme describe how the project is run rather than what it does, and both are relevant if you are thinking about depending on it.

The first is the support routing, which is described in one sentence: questions go to the manual first, then to a discussion in the Q&A category, and only a likely bug or a genuinely new feature justifies an issue. The readme also says the project wants you to leave a star above, which is a small request that costs nothing and is a decent proxy for how a project expects to be found.

The second is the sponsorship request, and the framing is unusually specific. It asks whether your business is relying on this program to secure customer websites and perhaps even critical infrastructure, and if so suggests sponsoring the core developer to gain guaranteed future support. The routes offered are Patreon, GitHub Sponsors and a one-time Paypal donation.

The phrase guaranteed future support is the one to notice. It implies that support is otherwise best effort, and it identifies a single point of dependency. A client that renews certificates for production sites is infrastructure, and the project is candid that the guarantee of a response comes from a sponsorship rather than from a contract.

That is a normal arrangement for a project maintained by one person, and the alternative is not obviously better. But a team putting this in front of a certificate renewal, which is the kind of thing that fails quietly, should know that the person who understands the code best is the person being asked to sponsor.

The project is also clear-eyed about where to look for help, and the workflow it describes, manual, then discussion, then issue, is the same workflow a well behaved issue tracker should have.

Where an ACME client is the wrong tool

There are three cases where this project is not the answer, and the third is the one that catches people out.

The first is a private certificate authority or an internal PKI. ACME is a protocol for public CAs, and the whole model, with DNS or HTTP challenges against a public endpoint, assumes a resolvable public name. A tool built for that will not do what you want for a private hierarchy, and no amount of configuration in this client will change that.

The second is a team that wants certificate issuance as a library call. This is an application, with a command line interface, a Windows flavour with an IIS-specific build, and a manual. If you want to embed issuance in a deployment pipeline, or trigger a renewal from your own service, you are looking at an integration problem that this repository does not present itself as solving.

The third is an environment without outbound internet access to the CA, or one where the challenge cannot be published. The alternative approach in that case is a certificate lifecycle that does not use ACME at all, whether that is an internal CA, an agentless approach where the validation happens elsewhere, or simply a scheduled script that renews before expiry using a key you already manage. The difference is that you give up the CA's automated proof of domain control, so the operational cost of proving control moves into your own infrastructure.

For a straightforward public certificate on a single server, all of this is overthinking, and this client will do the job. The question is worth asking before you put a renewal on a schedule, because the failure mode of a client that cannot renew is a certificate that quietly expires.

Editorial conclusion

simple-acme fits a team that needs certificates from Let's Encrypt or another ACME CA on a mixed estate, particularly one with IIS in the picture, and that is comfortable treating the website as part of the product. It is the wrong choice for a workload where you want a library you call from your own code, and it is the wrong choice for an air gapped environment with a private CA, since the project is built around public CA workflows and internet validation. Before you rely on it, verify two things: which of the packaged variants suits your platform and web server, since the project ships separate .NET and IIS builds, and how the client handles a certificate that is already issued, because the readme does not describe renewal or unattended operation at all. The code is Apache-2.0, the current release is v2.4.1 from 2026-10-06, and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. simple-acme/simple-acme on GitHub