Hello everyone,
till now I was just one of these lurkers in this community. Just searching some infos when my ACMESharp setup failed now and then.
But today isn’t one of these days.
I proudly present my ACME client for windows!
It is a single PowerShell script and comes without any dependencies like OpenSSL, Bouncy Castle or other DLLs.
It doesn’t bring huge bloat of config setup for you - You’re just one line of code away from your certs!
It uses only common Windows/.NET/Com-Interfaces and implements everything else by it self (like some ASN.1 encoder for PEM-file exports).
So it’s basically a replacement for the awesome dehydrated client on Windows.
Currently only Windows10 v1703 and Windows Server 2012R2 (doesn’t support export of EC pem files) are tested.
Also I want to mention that this is very early work. Please feel free and have look at it if you want.
I’m planning to do some more testing in the next days and will provide some scripts for easy integration of ExchangeServer and Netscaler.
Oh, one last thing: it seems that the certificates are replaced automatically on renewal in the windows cert store - so you wont have to update your IIS ssl bindings every time!
@rg305 Thanks for the hint with the key sizes! I fixed it and improved handling of these parameters a lot.
Also I found out, that there is no possibility to create odd sized rsa keys (like 4000bit). So in the end just the 2 options 2048 and 4096.
For your 2nd question: just so I call it twat
@ahaw021 I’m looking forward to your test results!
I’m just waiting here till someone finds out what In-Place-Renewal means
@ sahsanu A little bit early I guess, but well thank you for the honor! Much appreciated!
This doesn’t seem entirely correct. It may be limitations imposed by power shell or other components…
But I’ve been able to issue LE certs with bit sizes between 2048 and 4096.
Here is one such example: Auto renewing via cron job only issuing 2048 key size
Given very few people will ever even think about getting a cert in between them - this is really a non-issue.
But I just like all facts to be accurate and correct.
@rg305 Well, technically I can’t create such a rsa key.
Thats based on all the nice exceptions in the old CertEnroll::CX509PrivateKey API, maybe even in crypt32.dll.
Of course it is possible to get such certificates signed by LE. But I simply can’t create these god damn keys in the first place.
Let’s Encrypt will also accept 3072-bit RSA moduli. You can create a key with a 3072-bit modulus using some other tool like OpenSSL, and then I suspect there would be a way to use Windows APIs to import it or some other tool to convert it to a file format that the Windows APIs would be willing to open.
However, if your tool is directly creating the key and not providing an option to import an already-existing key, then respecting the limitations of your API makes perfect sense!
@schoen, @rg305 thanks for pointing me in the right way.
I did a bit more digging in Microsofts source code and yes there are many possible key sizes.
RsaCng keys can be 512 - 16384 bits large and the size must be a multiple of 64!
After that it’s only limited by Let’sEncrypt to be between 2048 and 4096 bits.
I’m working at the moment on the dns-01 implementation…
I can’t get a verification result (other than ‘pending’) for something like ‘example.tld’. I’m not even receiving an invalid!
My domains have *.example.tld wildcard TXT/SPF records.
Is this a known problem?
For test.example.tld it works without problems.
It seems like this poor guy stumbled across a similar problem. In his case it was something about case sensitivity.
I can rule that out. Tested random uppercase changes with nslookup and unboundtest.com
All show the correct acme record / hash.
Any idea?
And before any on asks for my implementation: here you go
I believe you misunderstood the question. My understanding is that he’s concerned the wildcard TXT records will interfere with the return of the acme-challenge TXT record. I do not believe this should cause any interference, but I’m not in a position to make any authoritative statements on the matter.
Awesome! What a cool way to de-lurk. I’m glad to see a new option available for Windows users.
Could I ask you to change it so it just says “Windows ACME Tool?” That matches the actual name (“WAT”) more closely, and avoids the jokey reference to “twat,” which is considered quite rude in some places. Obviously you are free to call your client whatever you like, but we do our very best to help the Let’s Encrypt community stay welcoming to all, and I’m hoping you’re willing to help out with a small tweak.
Again, thanks so much for creating this It’s a valuable addition to the Let’s Encrypt tool set.
I couldn’t agree more, that acronym must go…
I’m glad I’m not the only one that found it inappropriate.
Maybe you could code name it something hard like these instead:
Simplest Windows ACME Tool (SWAT)
Superior…
Superfly…
or something clever like:
Windows ACME Client Tool (WACT - pronounced “Wacked”)
Windows Tool For ACME Clients (WTFAC - pronounced “What The FACT”)
To be honest I hate huge parts of that code and it really wasn’t written in 3 days. Therefore the lovely name - but you’re right, let’s change it.
Thanks for the suggestions @rg305 I will think about them
Just some first thoughts:
It really isn’t that ‘simple’ (even has some manual ASN.1 encoder functionality)
WACET Windows ACmE Tool - is this pronounceable around the world?
PAC - Powershell Acme Client (just to confuse some admins)
ImPACT - Improved Powershell Acme Client / ACme Tool
Maybe some ideas for a recursive name like everyone at php projects uses or some hint to its Script/PowerShell nature?
@ahaw021 yes there was a slight misunderstanding @jared.m I would say I solved the issue (temporary?)
I just delayed the challenge response till I verified successfully with googles public dns servers that the correct value is in place. This time it worked… I don’t know why it didn’t before.
Tested without staging environment.
I’m glad to see a new option available for Windows users.