I understand ACME v2 is coming in January 2018. Is this intended to be a Staging or Production API endpoint? If Production, when is Staging likely to be available? TIA.
We’re working towards an early December deploy of a staging endpoint, assuming all goes well. The plan for January is production availability.
Awesome! Thanks for the rapid reply. We will be looking for that announcement eagerly.
Is it not really fast, to have only one month for testing and the large list of supporting client?
Would it not better to offer already an second url for the new version on staging?
I guess they are still working on ACME v2 API support in Boulder, which is why new API endpoint is not available for testing yet: https://github.com/letsencrypt/boulder/projects/1.
Note that ACME v1 API won’t be disabled immediately - as we read in ACME v2 API Endpoint Coming January 2018:
We will be adding a new ACME v2 API endpoint alongside our existing ACME v1 protocol API endpoint. We are not setting an end-of-life date for our ACME v1 API at this time.
so existing clients would continue to function.
Also, developers of ACME clients can already use Pebble, which is a “small ACME-08 test server”. As Let’s Encrypt strives to be standards-based, there is nothing which prevents developers from implementing latest ACME specification in their clients.
@jsha Please post here as soon as you make the ACME V2 API staging endpoint available.
Is there any update to this request? I’ve been playing around with Pebble, but it’s lacking some significant ACME v2 features (e.g., pre-authorization).
To have a “real” staging server to play around with would be great. Thanks!
First, we’re planning to introduce an ACME v2 protocol API endpoint and support for wildcard certificates along with it. Wildcard certificates will be free and available globally just like our other certificates. We are planning to have a public test API endpoint up by January 4, and we’ve set a date for the full launch: Tuesday, February 27.
Let’s Encrypt doesn’t plan to implement pre-authorization for the V2 API so this specific feature will not be present in the staging/production release.
Ouch … why no pre-authz?? Existing LE client implementations will need to retool completely, and from our end there will be a lot more failures.
Existing client implementations will have to retool for the V2 API regardless. There have been too many breaking changes above and beyond the new-authz endpoint.
Order based issuance in which required authorizations are returned to the client instead of the client asking ahead of time enables policy flexibility on the server side. We use this property for wildcard issuance.
The V1 API with the new-authz endpoint will continue to exist for some time. There’s no planned deprecation at this point.
Sorry, by “retool” I referred to the significant workflow change.
It seems like it’ll be a lot messier to have to generate a new CSR and order in response to authz failure, but I guess we’ll see. As you imply, we could just keep on using the v1 endpoint then use v2 only for wildcard.
Is there a list of v2 features that LE plans not to implement?
There was a lot of debate about this when the order based issuance flow was proposed on-list. Some of us pushed for keeping things closer to the original new-authz based issuance flow but consensus went another direction. My own (personal) opinion leans towards the idea that what remains of the optional new-authz endpoint is a bad fit with the rest of the spec and should probably have been removed outright leaving only order issuance ala Let’s Encrypt’s planned implementation.
Nothing formally documented. Back in October I shared some of the high level features we weren’t planning to implement on the WG list. The notable hitlist is:
- External account binding (probably not surprising/controversial)
- the new-authz endpoint
- OOB challenges (since removed from the specification)
Yeah my java implementation works with pebble and boulder
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.