ACME v2 support

[joshtriplett]

There's an ACME v2 test endpoint available now: https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605

Please consider adding ACME v2 support to acme-tiny.

Thank you!

[ScuttleSE]

Would be much appreciated!

[felixfontein]

It looks like @oittaa is working on a v2-enabled version of acme-tiny (see the recent commits in https://github.com/oittaa/acme-tiny). His fork diverged in December 2015, though, so no idea how hard it will be to merge this back in.

Also, I think one of the big problems of supporting v2 is that either acme-tiny will only support v2 in the future, or (in case it should support both v1 and v2) it will be longer than 200 lines.

[va1entin]

I think it would make sense to keep separate ACME v1 and v2 versions of acme-tiny on separate branches. Until v2 becomes the official default, v1 could stay on the master, while v2 could stay in a dev branch. That way the limit of 200 lines could possibly be kept.
Once v2 is the official default it could move to master and v1 could move to a "ACME v1" legacy branch.

[diafygi]

I've started work on v2 in a branch. Had to refactor a bit, but kept the size under 200 lines and will be backwards compatible. I won't merge it in until Let's Encrypt officially launches it. There's also a bug that's blocking tests from passing (letsencrypt/boulder#3367).

Branch: https://github.com/diafygi/acme-tiny/tree/ACMEv2
Compare: master...ACMEv2

[felixfontein]

@diafygi regarding your Boulder issue: I think that's because Common Name shouldn't be used anymore. It has never been the preferred way of specifying domain names, and for example Chrome actively ignores it (see https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo, https://productforums.google.com/forum/#!topic/chrome/-19ZxwjaCjw, https://security.stackexchange.com/questions/55414/is-the-common-name-mandatory-for-digital-certificates). So I guess they made Boulder less tolerant for something that shouldn't be used anyway.

[felixfontein]

You might also want to test acme-tiny against Pebble, a standalone ACME v2 testing server. Actually, your branch will most likely fail when talking to it since it actively ignores some valid nonces, while your _send_signed_request does not retry on the urn:ietf:params:acme:error:badNonce error; see the explanation for Pebble here.

Also, when you want to try Pebble: the directory endpoint is https://localhost:14000/dir in the default config, i.e. it doesn't end with /directory. So /directory (resp. /dir in this case) should probably be part of the DEFAULT_CA string.

[diafygi]

Hmmm, I'll have to look into reworking testing with Pebble, since it would significantly change the dependencies for running tests. I'm also kind of weary on testing against different code from production.

For the nonce retries, it would only add 2 lines to check for that error, so that shouldn't be an issue.

[Cadair]

Will adding wildcard cert support (looks like it will have to use dns challenges) be out of scope for acme-tiny?

Thanks!

[Trim]

@Cadair In my point of view, adding dns challenge support will be out of scope for the acme-tiny project as it requires to go over the limit of 200 lines of code and it renders the code more complex. You can find forks which have implemented acme v1 dns challenges in issue #161

For my project acme-dns-tiny (dns-challenge with use of TSIG keys), I've just begun to implement the v2 API to do the wildcard reqeuests.

[steffenweber]

In README.md, "Step 6" can be simplified because ACMEv2 returns not only the leaf certificate but a certificate chain (including the intermediate certificate).

[temporaryaccount]

I propose to increase the lines limit to 256. It will give us more freedom to implement new things and, unlike 200, it's a round figure for us programmers :-)

[andreasscherbaum]

Another option (not exclusive to bumping the line limit) would be to exclude comments - and finally include more than 4, 5 comments in the code. This will make the code more readable, and allow better review.

[diafygi]

@felixfontein

c4b7970 - added a --directory-url option and deprecated the --ca option

68c565e - added bad nonce retries

I managed to get pebble working on my local (which is how I manually tested the nonce retries), but haven't added it to the tests yet. I keep running into issues where staging is lagging behind pebble (e.g. letsencrypt/boulder#3514 hasn't been deployed yet to staging but has been committed to letsencrypt/pebble@65f0647). I'll likely wait until after acme v2 launches before revisiting pebble testing (hopefully by then the acme protocol changes have stabilized a bit more and we don't have so much lag between staging and pebble).

[diafygi]

@temporaryaccount I don't plan on increasing the line limit above 200.

[diafygi]

@Cadair I don't plan on adding DNS challenge support (thus no wildcard support)

[felixfontein]

@diafygi Cool! I also had that problem with staging and Pebble; according to @cpu (ansible/ansible#37165 (comment)) this will change on Tuesday, i.e. I guess then a new staging version will be deployed.

[felixfontein]

The ACME v2 endpoint is live! https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579

@diafygi: the ACME v2 staging endpoint is now updated, but the currently deployed endpoint is not -- it will be updated on Thursday, though (ansible/ansible#37165 (comment)).

[lovemyliwu]

guys, wildcard support you can use https://github.com/Neilpang/acme.sh

[felixfontein]

@diafygi: the change has been deployed to the production endpoint: the keyauthorization can be left away. That should reduce the line count a little bit :-)

[diafygi]

@felixfontein removed the unneeded challenge payload in ea9823d

[diafygi]

@felixfontein merged ACMEv2 into master, so we not support ACME v2 by default :)

@jonashaag finally merged in your pypi branch and copied over your release tags (plus added my own 4.0.0 tag for this ACME v2 release)