New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACME client for Windows/IIS #116

Closed
ebekker opened this Issue Dec 3, 2014 · 11 comments

Comments

Projects
None yet
9 participants
@ebekker
Copy link

ebekker commented Dec 3, 2014

I propose developing an ACME client for Windows + IIS.

Here are some of my thoughts:

  • Create a PowerShell-based solution, this would be comparable to the Python-based one already in the works for Linux/Apache (letsencrypt.py):
    • This will also be allow more compatibility with more environments, such as Windows Core, and even remote execution
  • Leverage the existing Windows components for any dependencies, for example under the hood, letsencrypt.py uses OpenSSL for all the cert management stuff, whereas on Windows you could use the certreq CLI or the CertEnroll API.
  • By structuring the code/libs nicely, we can make parts reusable outside of the main script, for example API/library for the ACME protocol itself to be used in other implementations or projects.
  • Try to mimic the letsencrypt.py command-line usage as much as possible/practical so that there is consistency across platforms letsencrypt.py CLI usage
@ghost

This comment has been minimized.

Copy link

ghost commented Dec 4, 2014

I think this is a great idea and a good approach. I think there should be a PowerShell version of the client. I'd be willing to help where I can.

@ebekker

This comment has been minimized.

Copy link
Author

ebekker commented Dec 8, 2014

I'm working on the ACME component right now trying to mimic the letsencrypt.py structure for that piece. My intent is to produce a separate stand-alone API component as a .NET library that will provide the underlying communication piece for PS with the ACME server (i.e. the Node.js demo server or the final thing), but then can also be used separately to power some other variation.

Some of the challenges I'm trying to overcome include interpreting the "on-the-wire" representation of some of the encoded secrets and encryption data from how it's generated in Python.

@schoen

This comment has been minimized.

Copy link
Contributor

schoen commented Dec 8, 2014

@ebekker One thing to be aware of (which you may already have encountered) is that the base64 used in JWK and related JOSE standards is not standard base64 but is a slightly-modified base64 ("URL-safe base64"). This might give you headaches if you're using an ordinary base64 decoder library to process or generate these strings.

@ebekker

This comment has been minimized.

Copy link
Author

ebekker commented Dec 9, 2014

Thanks for the heads up. Ironically, that was one of the easiest pieces I've adapted so far -- the base64url encoding/decoding routines in le_util reference Appendix C in the JWK draft upon which they're based. The code in Appendix C turns out to be written in C# (the draft is written by Microsoft) so I simply borrowed the code exactly as written in the draft's example.

@mitchem151

This comment has been minimized.

Copy link

mitchem151 commented Dec 22, 2014

@ebekker Is your code on github? I started in on tackling this before searching to see if anyone else has, I'd love to work with you on this.

@ThomasWaldmann

This comment has been minimized.

Copy link
Contributor

ThomasWaldmann commented Jan 24, 2015

hmm, this is the repository and issue tracker of the python-based lets-encrypt client.

you are suggesting a non-python based one.

so I guess this issue can never be closed within THIS project except as out of scope / invalid, right?

@artknight

This comment has been minimized.

Copy link

artknight commented Mar 18, 2015

sorry, from reading the above it is not apparent to me that windows will be supported from the get-go!

@pde

This comment has been minimized.

Copy link
Member

pde commented May 13, 2015

This is in progress.

@ebekker

This comment has been minimized.

Copy link
Author

ebekker commented Aug 17, 2015

OK, after kicking off this issue and putting out some ideas, I intended to start an implementation, but that didn't happen...until now.

I've committed the start of this at https://github.com/ebekker/ACMESharp

Now, I know there's been some related development:

These look like good efforts, but I think there is a good bit of value in the approach I'm following, which is:

  • a pure CLR implementation of the ACME protocol (at least the client side) as a lib.
  • a POSH module using the ACME client lib that can be used to manage and configure IIS 7+.
@ebekker

This comment has been minimized.

Copy link
Author

ebekker commented Oct 8, 2015

I'm closing this issue as there's now a functioning client for Windows that can inter-operate with the LE Boulder CA and can configure IIS.

I've written up a description of the general use -- feedback on the interfaces and usability would be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment