Comments (27)
I don't know... using eliot and testtools.matchers and not using defer.inlineCallbacks is still a pain for me ... so I don't know when the PR can be merged.
In order to get things done, at least from now, I have removed some eliot logging and no automated tests were written... only the example script which can server as a manual happy path test.
I hope to get AcmeIssuingService in the next week
from txacme.
I have implemented the v2 protocol based on a local pebble server.
I have not yet updated the AcmeIssuingService to use the new implementation
In the 151-acme-v2 there is an example script that I used for manual testing
https://github.com/twisted/txacme/compare/151-acme-v2
The API is changed as v2 has a different process and objects.
Will continue to work on the ACME service part with support for SAN
from txacme.
Is txacme still active?
I have PR #140 open for some time without much feedback.
I am using txacme and will work at implementing v2 support
.
Let me know if someone can help with a review.
from txacme.
But before going to ACMEv2 I would like to have the API with support for SAN
Right now, I am using a forked txame version and I need SAN
from txacme.
@adiroiban SAN support is important, but ACME v2 seems more pressing due to the fact that txacme will stop working entirely if we donβt get to it in time :).
from txacme.
I understand. But before being able to work on ACME v2 and write tests for txacme I need to get familiar with the txacme testing tools.
This is why I start working on #140 and was planning to do #37 . After that I can look into ACME v2 support.
SAN support should be a quick fix...and I am already using it in production for my project.
from txacme.
@adiroiban I appreciate any work you can do on anything related to txacme, of course. I just hope somebody picks up ACMEv2 soon.
from txacme.
I understand that ACME v2 is critical. But before being able to work on ACME v2 and write tests for txacme v2 I need to get familiar with the txacme testing tools... testing-cabal/testtools needs extra effort to learn
This is why I start working on #140 and was planning to do #37 . After that I can look into ACME v2 support.
SAN support should be a quick fix...and I am already using it in production for my project.
from txacme.
I have start working on the ACME 2.
So far is a proof of concept ... as I still don't understand the eltot loging and all the callback chains.
Once I get a basic example up and running I will also update the tests
https://github.com/twisted/txacme/tree/151-acme-v2
There will be an API break for the low level ACME client... but I think that ACME service can continue to work as it is.
from txacme.
Amazing! π
Any idea of when this implementation will be usable in the mainline txacme
?
from txacme.
I have implemented the Service part of txacme .
as far as I can tell, there was no API change for the txacme.service.AcmeIssuingService
Please give it a try from the in work branch and let me know if anything is broke.
The low level txacme.client.Client API was changed
The current implementation also support SAN via CSV names.
from txacme.
I think that for the initial release of ACME v2 we should remove the endpoint support.
The endpoint support for ACME v2 can be added later.
The current ACME v2 branch is already huge.
from txacme.
What is still required to get this to a usable state?
The src/txacme/client.py
file from https://github.com/chevah/txacme/tree/chevah-acme-v2 appears to make this work, if it's cherry-picked into master
. (I don't know if the service stuff works, as I don't have need of that).
I'm going to see if I can put together a minimal example using it and a private_key in from certbot. I can also give the patched client.py a once-over and open a PR with just it, as that would restore at least basic functionality here.
from txacme.
@perkinslr I think "it takes 2 to tango"
Can you try the version from here?
Are you happy with the API?
pip install --index=https://bin.chevah.com:20443/pypi/simple/ txacme==1.0.0.chevah4
The thing that since there wasn't much public interest into txacme, I kept using my fork and private test - a dump is here https://gist.github.com/adiroiban/b895a62b4d28197dfdc8b803aa23ab0c
it needs some feedback in terms of API, to make sure the API can be use in multiple scenarios.
but if you are happy to try a pre-release I am happy to continue working on this.
from txacme.
Doesn't look like you've made any further changes to src/txacme/client.py
in that version, so yes, it works too.
So far, I've only used the example_client.py from your github fork, but I'll be implementing a real version presently. It looks like the API is roughly like I'd have done it, so no objection there, but I'll let you know once I've actually used it.
As for the lack of public interest, I think that's a matter of messaging. I actually got about 1/4 of the way through RFC8555 to start working on it because I failed to find this before stumbling upon it. Probably because I was looking for twisted-certbot rather than twisted-acme integration. Not sure how to get this to show in searches for "twisted certbot", probably mention it's "an alternative to certbot" somewhere in the readme, but that can be addressed once it's functional.
from txacme.
Hm, the imports in client.py
are wrong. It should be from . import __version__
(and the like), rather than from txacme import __version__
.
from txacme.
ok. let me put all the code and tests that I have in the current PR.
We can discuss based on the exact code...
the PR will be a monster, but as long as the tests are green and have some sort of coverage, I think that we should merge the PR.
Then we can create separate PR to do various other changes or bugfixes.
I have also canibalized the existing project as I have removed versioneeer as I remember that it was not playing nice with private pypi mirrors...and I had to build from source for AIX and Alpine Linux... but maybe versioneer works with those cases and is just that I don't know how to use it.
And eliot usage and hyphotesis usage ...and I didn't know how to use them TDD and they were just stading in my way.
from txacme.
You're still using eliot inside client.py
. Since it isn't available in my distro's repos, I'd kinda prefer not to use it, but am not terribly picky.
from txacme.
The dns01 challenge appears to possibly be broken, as I can't figure out from the provided parameters what value should be set in the txt record.
from txacme.
Yup. The call to start_responding
includes a pregenerated response
value, which is used for the http challenge, but does not include a pregenerated validation. You can get it from challenge.validation(client_key)
, but it is not perfectly obvious.
from txacme.
I have only implemented HTTP-01 for v2.
The libcloud will be removed as a start, and we can get DNS-01 in a separate PR.
from txacme.
Really? Because I have DNS01 working. The challenge type is different, and the way to get the verification string is slightly different, but otherwise it's quite simple. (The current API just requires the dev to keep a handle to the client secret key in order to generate the string inside the start_responding
method). Returning a Deferred
from start_responding
already works, so the significant delay in deploying DNS01 responses is not a major problem.
from txacme.
I have never tried DNS-01 with my v2 branch.
From you comment, I am not sure if the existing LibcloudDNSResponder
is working, or you were able to use the library to create your own DNS responser.
from txacme.
I created my own DNS responder, since I need to reach out to my DNS provider to change the TXT record via their API. Don't see any reference to LibcloundDNSResponder, since I'm not using anything from your branch except the client.py.
from txacme.
@perkinslr ok. The AcmeIssuingService is nice. You just set it up and it will take care of long term renewal.
If you have time, it would be nice to take a look at the AcmeIssuingService API and see what it's missing from making it usable for you test case.
see the code on the new #161 ... that is the code that I am trying to merge
from txacme.
Fundamentally, the problem with AcmeIssuingService
is it's designed to run as a twisted service (which are usually standalone, I know you can run multiple services within a process, I generally don't like to). Also, it cannot interoperate cleanly with certbot
, at least not without implementing an ICertificateStore
.
So far, I have implemented a simple periodic certificate check that goes through the list of certbot
certs and renews them when needed. It does this with a dead-simple reactor.callLater
loop at the top level of my webserver. When this signals a cert must be reloaded, it updates the cert used by the webserver. Slightly longer term, my mail server (and other similar servers) will request their certificates via dbus, and be notified via dbus message of certificate renewals.
The whole implementation, including challenge responders, weighs in at 200 loc. Were I to use AcmeIssuingService
to replace what it can, it would save me at most 25 lines.
From looking at AcmeIssuingService
, it's fine for what it is, but it's far more than I need.
from txacme.
I have merged the code.
I will have to look into updating the tests for AcmeIssuingService and do a release.
And also check the docs. The endpoint is no longer supported at SNI-01 is no longer supported
from txacme.
Related Issues (20)
- Construct URL correctly
- Libcloud DNS responder doesn't work with Route 53 HOT 13
- Use native conversion to/from PyOpenSSL and Cryptography
- Certbot-like ability to update domains in a certificate (--expand)
- txacme.test.test_service.AcmeIssuingServiceTests.test_errors fails
- Decide what to do about IDNA encoding HOT 1
- Flake8 failures
- Deprecate SNI endpoints and figure out a replacement HOT 21
- Document release process HOT 3
- Implement TLS-ALPN challenge method HOT 7
- Don't try to renew cert for the certificate chain and panic right away.
- In AcmeIssuingService panic or call a dedicated callback on registration errors HOT 1
- Have less strict content type checking HOT 2
- txacme.client.Client.register raised KeyError when an ACME v2 directory is used HOT 2
- The server endpoint doesn't work HOT 3
- Eliot > 1.7 doesn't work with Python 3.5.2, which is what is on Ubuntu Xenial HOT 2
- broken with attrs 19.2.0 HOT 6
- will break with a future version of attrs due to cmp=
- Traceback: exceptions.AttributeError: Deferred instance has no attribute 'register'
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from txacme.