Let's Encrypt support - Githubissues

mithrandi commented 8 years ago

This is in support of twisted/mantissa#40 but the Mantissa component of this is really minimal. Essentially, all Mantissa should be responsible for is providing an object that can:

Provide a list of hostnames to respond for.
Store a new certificate for a given hostname.
Provide a certificate for one of those hostnames on demand.

Interacting with Let's Encrypt requires 1 and 2, serving TLS via txsni requires 3, and the obvious relatedness of these tasks suggests they should be implemented by the same object. 3 is already provided by the mapping argument that SNIMap takes, so this raises a few questions:

Should 1-3 all be part of the same interface, or should 1-2 be a separate interface?
If they're a separate interface, should the interface be defined by txsni at all, or by a separate project?
Should these be zope.interface.Interfaces, or just documentation?
Even if the interface is defined in txsni, should the actual Let's Encrypt implementation be in txsni, or a separate project?

There's no particular reason the Let's Encrypt stuff needs to be in txsni itself, that just seems like a convenient place to put it: I guess it really depends on where @glyph wants it. If this does end up in txsni, then I'll break the work up into several branches for the independent bits, so this issue itself is more of a "master tracking issue".

glyph commented 8 years ago

This is absolutely something I'm interested in; thanks for writing it up.

mithrandi commented 8 years ago

I thought about it some more, and the MutableMapping interface (as Python calls it) is sufficient here; __iter__ to iterate certificates in the "store", and __setitem__ to insert / replace a certificate.

(EDIT: fix method name)

glyph commented 8 years ago

__setitem__ you mean?

mithrandi commented 8 years ago

Uh, yeah, that :)

mithrandi commented 8 years ago

Oops, there's not actually a Twisted implementation of the Let's Encrypt API yet (for some reason I thought letsencrypt-aws used Twisted, but it doesn't); I guess I'm going to have to implement txacme first.

mithrandi commented 8 years ago

txacme is a thing now, see that repo for further progress on that front. I'll come back here once that's done, to figure out how exactly the integration with txsni should work.

mithrandi commented 8 years ago

I'm now planning to add my own endpoint parsers in txacme, to make things simple. (I'll still be using SNIMap under the hood, though). Most of the other stuff I talked about in the description here is happening in txacme, instead; @glyph should we close this issue, or keep it open?

glyph commented 8 years ago

I'm inclined to say we should close it, although I'm not doing so immediately because it hinges on this one question: how would this be resolved, under your current understanding, @mithrandi ?

mithrandi commented 8 years ago

Almost all of the functionality I discussed originally is now provided in txacme. As far as integration goes, I had originally imagined that the txsni: endpoint parser might provide some ACME functionality, but the design I ended up with has a new le: parser which will just be provided by txacme itself. In fact, since txacme is depending on txsni, adding functionality to txsni that depended on txacme would result in a circular dependency.

We could keep this open until an actual txacme release happens, though? (I'm not quite there, but pretty close)

glyph commented 8 years ago

Feel free to close when txacme is released, then.

mithrandi commented 8 years ago

https://pypi.python.org/pypi/txacme :tada: :tada: :tada:

glyph / txsni

Let's Encrypt support #3