I finished implementing a PowerShell Core ACME v2 Client.
It’s compatible with PS-Core and Desktop 5.1 (if you have NET 472 installed) and tries to adhere to PowerShell semantics as much as possible.
It’s open source and developed on GitHub.
4 Likes
@lestaff, who currently updates the list of client implementations on the Let’s Encrypt home page?
I remember that it used to be done on the forum, but now the comprehensive updated list is on the Let’s Encrypt site.
We accept PRs! https://github.com/letsencrypt/website
1 Like
Any comparison with Posh-ACME (goal-wise) ?
2 Likes
cc @rmbolger - You and @glatzert might be able to share some experience having both written PowerShell ACME clients 
Posh-ACME supports more modules for handling the challenges and things like that and also fully automatically handles the local state - we do handle local state, but it’s not automatically passed around.
Also we do not rely on BouncyCastle, but use NET472 functions for PFX-handling.
I think while Posh-ACME is more an full Client implementation, ACME-PS does more or less “protocol handling” only. The Goal was to enable the user to easily get everything together to be able to fullfill a challenge and then give him everything, which is neccessary to obtain the certificate - leaving out the actual implementation of createing a file for http-01 or binding the new certificate to iis.
ACME-PS was created as successor to AcmeSharp.
1 Like
On a mildly embarrasing matter: I failed to sign the module correctly and - for now - removed the AuthentiCode …
I was actually an ACMESharp user until ACMEv2 became usable. At the time, I had use-case for wildcard certs and it seemed like it would be a while before ACMESharp added support. I was also inspired by the usability and DNS support of acme.sh. So I decided to try my hand at implementing ACMEv2 in PowerShell myself.
The goal was to implement in pure PowerShell without any binary library dependencies. But that turned out to be too difficult given the limitations in .NET 4.7.1 which was the latest at the time. 4.7.2 looks like it has most of the missing pieces, but there turned out to be a decent number of users that couldn’t even use 4.7.1 due to environment or platform limitations like some portions of Azure that only support up to 4.6.2. I ended up releasing a custom build that works with .NET 4.6.1 that basically removes ECC key support. Ultimately, I’ll likely keep BouncyCastle around until more of the world has had time to upgrade to 4.7.2.
My focus with Posh-ACME has primarily been about ease of use. The users shouldn’t have to care about how the ACME protocol works. They just want a cert and they want to automate that as part of their existing infrastructure with the least hassle possible. DNS plugins were the priority for me because they were necessary for wildcard certs and overall I just like dealing with DNS more than web servers. I’m up to 21 supported providers at the moment with a surprising (to me) number coming via pull requests. It constantly amazes me how little people understand about DNS and how much easier it is to deal with for challenges than web servers, reverse proxies, load balancers, url routing, etc. Though it probably has a lot to do with the fact that the people who need certs for their web app aren’t necessarily the same people who manage their organization’s DNS.
In any case, congrats on the release! The more clients, the better.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.