Closed mithrandi closed 3 years ago
This is absolutely something I'm interested in; thanks for writing it up.
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)
__setitem__
you mean?
Uh, yeah, that :)
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.
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.
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?
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 ?
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)
Feel free to close when txacme is released, then.
https://pypi.python.org/pypi/txacme :tada: :tada: :tada:
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:
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 thatSNIMap
takes, so this raises a few questions:zope.interface.Interface
s, or just documentation?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".