# Any update on GETS -\> POSTs conversation **URL:** \ **Category:** Client dev\ **Created:** [September 25, 2018, 3:15pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139 "2018-09-25T15:15:54Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [September 25, 2018, 3:15pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/1 "2018-09-25T15:15:54Z")
Continuing the discussion from [ACME breaking change: Most GETs become POSTs](https://community.letsencrypt.org/t/acme-breaking-change-most-gets-become-posts/71025): > [@ACME breaking change: Most GETs become POSTs](https://community.letsencrypt.org/t/acme-breaking-change-most-gets-become-posts/71025/1): > > During a final round of review at IETF, ACME received some feedback that is likely to lead to a breaking change in how ACME handles GETs. Please read my summary for details: > > [https://mailarchive.ietf.org/arch/msg/acme/sotffSQ0OWV-qQJodLwWYWcEVKI](https://mailarchive.ietf.org/arch/msg/acme/sotffSQ0OWV-qQJodLwWYWcEVKI) > > What this means for ACME client developers: At some point, assuming this change is made to the ACME spec, Let’s Encrypt will make available a new ACME endpoint conforming to the new version, which will be incompatible with both ACMEv1 and ACMEv2. The amount of work involved in changing most clients should be relatively small. Clients will need to change GET requests into signed POST requests. > > Right now our recommendation for client developers is: If you are working on ACMEv2 implementation, it is probably better to wait for this upcoming spec change, unless you urgently need wildcard support. Please keep an eye on the ACME mailing list. > > The ACMEv2 endpoint will continue to be available. We’ll announce a sunset date after we make the ACMEv3 endpoint available (again, assuming that the IETF ACME WG proceeds with the change). Just curious if there is any news on this topic? ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [September 25, 2018, 3:32pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/2 "2018-09-25T15:32:50Z")
> [@rmbolger](#): > > Just curious if there is any news on this topic? We're going to be posting an API announcement in the next day or so. In the meantime here's a quick summary of my understanding of things (subject to change!): 1. The POST-as-GET change met consensus and was [merged into the draft specification yesterday](https://github.com/ietf-wg-acme/acme/commit/aca1171e35cc1ee7b51aa9e0fac75934ac54ea00). ~~There hasn't been a new numbered draft cut yet but I expect that will happen soon in order to enter another last-call.~~ - [draft-ietf-acme-acme-15](https://tools.ietf.org/html/draft-ietf-acme-acme-15) captures this change. 2. Pebble's support for mandatory POST-as-GET [was merged today](https://github.com/letsencrypt/pebble/commit/0f3ee7dc9c2840d52cba3bbd45b27e283c21eb7b) and you can begin implementing client support using Pebble with the `-strict` flag. 3. I filed an issue to [implement optional POST-as-GET for Boulder](https://github.com/letsencrypt/boulder/issues/3871). "Optional" meaning we'll handle POST-as-GET requests to resources but also continue to allow unauthenticated GET requests to the same resources for some time 4. We'll pick a date in the future based on the state of the ecosystem to disable unauthenticated GET requests to resources for the V2 API. This will bring Boulder in line with Pebble's `-strict` implementation. None of this will affect the legacy V1 API. Earlier discussion included the idea we might implement a "V3" API for this change but I believe current consensus internally is leaning towards a flag day with the V2 API. I expect we'll make a final decision about this in the next day or two ahead of a formal API announcement. I hope that summary helps! Overall I'm sorry about this late breaking change. It's challenging participating in standards work and I'm very sympathetic to the client developers that have to jump into action to address this in their clients. ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [September 25, 2018, 3:45pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/3 "2018-09-25T15:45:02Z")
> [@cpu](#): > > but I believe current consensus internally is leaning towards a flag day with the V2 API. I think this is going to lead to a lot of broken wildcard renewals because we have a lot of Certbot users who don't have regular client upgrades (which you can see in the server-side client statistics). I would still advocate for the v3 idea as originally suggested. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [September 25, 2018, 3:47pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/4 "2018-09-25T15:47:37Z")
> [@schoen](#): > > I think this is going to lead to a lot of broken wildcard renewals because we have a lot of Certbot users who don’t have regular client upgrades These users would experience the same breakage when the V2 API was removed in favour of V3. If we schedule the V2 API flag day with this difficulty in mind I don't think its significantly worse. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [October 9, 2018, 7:18pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/5 "2018-10-09T19:18:12Z")
> [@rmbolger](#): > > Just curious if there is any news on this topic? We've posted our [API announcement](https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380) outlining the plan for POST-as-GET support & deprecation of unauthenticated GETs for ACME v2. > [@cpu](#): > > We’ll pick a date in the future based on the state of the ecosystem to disable unauthenticated GET requests to resources for the V2 API. We're targeting **November 1st, 2019** for this. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [October 9, 2018, 8:18pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/6 "2018-10-09T20:18:35Z")
Thanks for the update, @cpu. So it sounds like the timeline for client devs adopting POST-as-GET (PaG) support should look something like this. - Today - Start working on a branch of your client that transitions to PaG using Pebble as the test server - Date X when Staging supports PaG - Verify branch works properly against staging. - (Optional) Release client that uses PaG only against staging. - Date Y when Production supports PaG - Release updated client that defaults to PaG - November 1, 2019 - Relax because users who are up to date shouldn’t have any issues with the disabling of unauthenticated GETs - Users who haven’t upgraded to the release from Date Y or later will break. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [October 10, 2018, 2:08pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/7 "2018-10-10T14:08:36Z")
This client implementation plan sounds sensible to me. I’d estimate that “Date X” is likely to be in the next week or two, with Date Y following a week afterwards. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [October 11, 2018, 3:38pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/8 "2018-10-11T15:38:11Z")
Also just to clarify, do I have this right? The only resources that will continue to be available without PaG after November 1, 2019 are: - Directory - Forever GET’able - newNonce - Preferably HEAD, but also GET’able - Certificates - Though this is a Let’s Encrypt specific implementation decision based on the “MAY allow” phrasing in [Section 6.3](https://tools.ietf.org/html/draft-ietf-acme-acme-15#section-6.3). Other ACME servers may choose not to allow it. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [October 11, 2018, 4:39pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/9 "2018-10-11T16:39:39Z")
> [@rmbolger](#): > > The only resources that will continue to be available without PaG after November 1, 2019 are: > > - Directory > - Forever GET’able > > - newNonce > - Preferably HEAD, but also GET’able Both correct ✅ > [@rmbolger](#): > > Certificates > > - Though this is a Let’s Encrypt specific implementation decision based on the “MAY allow” phrasing in [Section 6.3](https://tools.ietf.org/html/draft-ietf-acme-acme-15#section-6.3). Other ACME servers may choose not to allow it. I need to verify our plans here with @jsha and @roland. I believe our intention is to **only** suport POST-as-GET to certificates. The MAY allow you're referring to was [recently removed in the working copy of the draft](https://github.com/ietf-wg-acme/acme/commit/8080dc6842a1c6a9cac05a33282a30e254f14763). ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [October 16, 2018, 9:27pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/10 "2018-10-16T21:27:25Z")
> [@cpu](#): > > I need to verify our plans here with @jsha and @roland. I believe our intention is to **only** suport POST-as-GET to certificates. The MAY allow you’re referring to was [recently removed in the working copy of the draft](https://github.com/ietf-wg-acme/acme/commit/8080dc6842a1c6a9cac05a33282a30e254f14763). Yep, that's correct. We'll treat certificates the same way we treat other resources: GETtable for now, but POST-as-GET in the future, to match the latest spec ([draft-16](https://www.ietf.org/id/draft-ietf-acme-acme-16.txt)). ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [November 15, 2018, 9:27pm UTC](https://community.letsencrypt.org/t/any-update-on-gets-posts-conversation/73139/11 "2018-11-15T21:27:26Z")
Closed on November 15, 2018, 9:27pm UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.